HTTP/1 vs. HTTP/2 vs. HTTP/3 – Explained
If you’ve visited any websites before then you will have undoubtedly seen the “HTTP” or “HTTPS” prefixes at the start of a web address. For the average internet user, these will simple be ignored and you won’t find any reason to pay attention to them. After all, it’s a domain name that you type into the address bar to find the website.
There is however a lot more to this simple prefix than meets the eye. These short prefixes make up a large part of every single website on the internet. Every time you visit a web page, or type something into the search bar, you’re using HTTP or HTTPS to access them.
As the internet has evolved, new technologies have come and gone, and with that different versions of HTTP have been implemented. For the large part, these changes happen behind the scenes and go largely unnoticed. They do however bring in some important bug fixes, and optimisations to website performance.
In this blog post we’re going to look at what HTTP is, how the protocol works, and how the various versions of HTTP differ.
What is HTTP?
HTTP stands for Hypertext Transfer Protocol, which is an application protocol used for communicating over the world wide web since it’s introduction in 1989. HTTP is a method used by computers and servers on the internet to request and send information. Essentially, HTTP is what allows servers and computers to communicate with each other.
Developed by Tim Berners-Lee shortly after the introduction of the internet, HTTP was initially developed in a very simple environment. The first documented version of HTTP consisted of just a single line of code, containing the GET method (which we will get into later) and the path of the requested document. The response produced a single hypertext document to the requested path – many multitudes simpler than it is now!
How does HTTP work?
HTTP utilises a few simple methods to send and receive information between computers. The two most common methods are
- GET
- POST
When a client machine communicates with a server, it sends one of these commands to instruct the server what to do next. In response to this, the server will typically return a resource to the client machine such as a HTML web page.
GET example
Let’s put this into an example HTTP transaction that might take place.
GET /index.html HTTP/1.1 Host: www.example.co.uk
In this example here, the client’s machine uses the GET method to request a HTML document called ‘index.html’, with the HTTP/1.1 protocol, from the host server at the address of ‘www.example.co.uk’.
In response, the web server returns the ‘index.html’ document to the client machine along with any related stylesheets, images, or other resources.
These resources aren’t all returned within the one transaction however – the requests and responses will go back and forth until all relevant data has been transmitted and the client can display the web page on their browser.
POST example
Another example below is how a typical HTTP transaction with a POST command would be executed:
POST /test HTTP/1.1 Host: ukhost4u.com field1=value1&field2=value2
In this example, the client’s machine used the POST method to send data to the specified server.
Here the data being sent is ‘field1=value1&field2=value2’. The first line defines the method being used, the file to send the data to, and the HTTP version. The ‘host’ line defines where the client’s machine should connect to, prior to sending the specified data.
What is HTTP/2?
HTTP/2, the first major revision of the HTTP protocol, was developed with the aim to reduce web page load latency by implementing a variety of optimisation techniques. Published by the IETF (Internet Engineering Task Force) in May of 2015, HTTP/2 is designed to be a standard method of communication compatible with all available web browsers.
Rather than being a full replacement for HTTP/1.1, HTTP/2 is intended to add to the existing functionality offered by the original revision of HTTP – as such, it supports all of the core concepts such as HTTP status codes, methods, and header fields.
How does HTTP/2 work?
While both HTTP/1.1 and HTTP/2 share semantics in order to facilitate communications between both protocols, the methods that they use to deliver data can differ greatly.
The key differences between HTTP/2 and HTTP/1.x are as follows:
- HTTP/2 encodes request and response messages into binary, instead of transmitting the normal plain-text messages you would see with HTTP/1.1.
- HTTP/2 is fully multiplexed and concurrent, meaning it can make many more requests to and from the website compared to the limited requests in HTTP/1.x
- Stream prioritization of website assets is utilized
- Header compression is used to reduce overhead processing
So now let’s take a look at what HTTP/3 is, and how it works.
What is HTTP/3?
HTTP/3 is the new version of HTTP, released in August 2020, based on the QUIC network protocol. Originally introduced as a method of improving HTTP/2 by transporting encrypted data over UDP, this new version of HTTP aims to bring several key improvements to the table.
Instead of entirely replacing HTTP/2, HTTP/3 is intended to benefit speeds when enabled in particular scenarios – and HTTP/2 can always be used to fall back on if HTTP/3 is unavailable.
Although HTTP/3 is a brand new protocol and is yet to be widely implemented in many scenarios, it is already in use by some providers such as Google and Facebook – you may just not be aware that you’re using it!
How does HTTP/3 work?
Being a very new protocol, it’s likely that HTTP/3 will undergo some changes over the next few years, however it’s foundations will remain firmly based on the QUIC protocol.
QUIC (Quick UDP Internet Connection) is a new network transport layer protocol that aims to significantly reduce latency and improve efficiency compared to TCP. Essentially, connections are established faster – especially when network conditions aren’t optimal.
The biggest benefits of HTTP/3 are yet to be fully realized, but we can get an idea of some scenarios that would benefit by the improvements introduced in HTTP/3. Video streaming may see a significant boost in speed due to QUIC reducing the TCP slow start problem, especially in UHD and above. Also when moving between mobile networks and WiFi networks, HTTP/3 may also provide a speed improvement for the same reason.
The Key Differences Between HTTP/1 and HTTP/2
With there being so many minor technical changes behind the scenes with version 2 of the HTTP protocol, in this section we will go into more detail on just the key differences from a technical standpoint.
Textual vs Binary Protocols
With HTTP/1.x versions, HTTP requests are communicated with basic text-based commands, without any form of conversion happening at either side. The commands are simple, and completely readable to any system administrator.
With HTTP/2 however, these commands are binary instead of text-based. Binary code, in short, is made up of 1s and 0s that are read and executed by the computer processor. Binary must then be converted back to a readable form.
Concurrency and Multiplexing
Nowadays with websites becoming more complex and resource-intensive, web browsers are often required to make a significant amount of HTTP requests in order to load a web page. Many websites can require over 100 connections – and when you’re being limited on the amount of connections you can have, this can cause a website to load more slowly.
Originally, HTTP/1.0 only allowed for one single request to be made at a time. HTTP/1.1 improved this by increasing the limit to around 6 or 8 simultaneous requests, depending on the web browser. If a user wanted to make multiple parallel requests for assets, the user would have to use the Domain Sharding technique to do so. This is where the user would use a subdomain, or multiple subdomains, to allow for a higher limit of connections, for faster download speed.
Another issue with HTTP/1.x is known as ‘head-of-line blocking’. This is where a new request is blocked from being made until the results of the first request are received. This can further limit your download speed on a website.
The new binary framing layer with HTTP/2 removes these limitations completely. Full request and response multiplexing allows the client and server to break down the HTTP messages into independent frames, transmit them, and then reassemble them on the other side – using only a single TCP connection. This means that no requests or responses are blocked, and fewer connections are utilised, meaning even faster speeds.
Stream Prioritization
When downloading a website, the order in which assets (HTML, CSS, images, Javascript) are downloaded is important and can affect what you see in the browser. If the assets are loaded in the wrong order your website may look incomplete or even lose functionality in some areas.
HTTP/1.1 eliminates this issue, as the head-of-line blocking makes it straightforward to load assets in the right order. HTTP/2 doesn’t have head-of-line blocking, therefore responses to the browser request might be received in any order.
HTTP/2 solves this issue by allowing the browser to indicate to the server what priorities should be given for downloading the specific files or objects. This means that web browsers will automatically download the most important assets first, therefore removing any potential for assets to be loaded in the wrong order.
Header Compression
Traditionally with HTTP/1.1, with every new asset requested from a web server, a new TCP connection had to be provided. This means that on heavier web pages with over 100 requests, which might take some time to finish and result in longer load times.
HTTP/2 utilizes compression, meaning it can send all of the HTTP headers within a single TCP connection. The new header-specific compression scheme called HPACK helps minimise load times with only a single connection needing to be used.
This technique works by compressing the individual value of each header, before it is transferred from the client to the server. This information is then referenced against a list of previously transferred header values, in order to then reconstruct the full header information. HPACK provides a significant performance benefit over HTTP/1.1
How does HTTP/3 differ from HTTP/1 and HTTP/2?
As you may have already deduced, HTTP/3 has several significant differences from the traditional methods used in HTTP/1 and 2. Let’s take a look at a few of these key differences.
Network Protocols – UDP vs TCP
Perhaps the most obvious difference between HTTP/3 and the older versions is that HTTP/3 is fully based on QUIC, which utilises UDP.
UDP is a transport protocol used for fast communication, through which data can be transmitted with errors. This is primarily used for video transmission, where receiving the live image is vital and having corrupted video frames is not a major issue.
With the new QUIC protocol, web servers are now able to send parallel requests/responses. This means that if one request or response experiences packet loss, then the others aren’t stopped as a result. Additionally this translates to faster request/response times in general!
Compared to solely using TCP, as HTTP/1 and HTTP/2 do, this is the most significant change to be introduced for many years.
Header Compression – QPACK vs HPACK
HTTP/3 uses QPACK, a compression format for representing HTTP headers used in HTTP over QUIC.
While QPACK is functionally similar to HPACK, which HTTP/2 uses, QPACK intends to bring a few improvements.
The biggest problem this solves is the head-of-line-blocking, but it also helps to provide a further performance boost compared to HTTP versions 1 and 2.
In Conclusion
So now that we’ve covered the different versions of HTTP, how each version works, and the differences between them, we hope you have a clearer picture of how the technology has evolved over the years.
All of our web hosting plans use LiteSpeed, which supports HTTP/3 out of the box. Future proof your website and utilise a high-speed, resilient network today with UKHost4u.
