The HTTP protocol is the foundation of the web. Many web servers still use HTTP/1.1 today. This version is more than 20 years old. After all this time, the way we use the web has changed considerably. In order to meet the new requirements, a new version of HTTP had to be developed.
Since 2015, HTTP/2 has brought many benefits to users of online apps and web browsers:
Also next in line, HTTP/3 is already supported by several web browsers and will offer even more benefits in the future.
HTTP (Hypertext Transfer Protocol) forms the basis of the web. This protocol ensures communication between a web client (a web browser or an app) and a web server.
This communication is made possible by HTTP requests and HTTP responses.
HTTP/2 was developed as a replacement for the old HTTP/1.1 protocol in order to avoid overloading web servers and to make the connection to the web client even more efficient.
HTTP/1.1 is a serial protocol that can only send one request at a time per connection. If a web client sends many requests simultaneously, many connections to the web server have to be established, which can cause a heavy load.
HTTP/2 allows multiple requests to be sent per connection. Moreover, the data transfer is more compact and more efficient than with HTTP/1.1. This way, HTTP/2 avoids any Head-of-line blocking without having to establish additional connections on the server side. This helps reduce the risk of server overload and minimise load times.
HTTP/2 is a binary protocol, which means that it requires fewer bytes than the HTTP/1.1 text protocol. Moreover, new techniques such as header compression, multiplexing, frame prioritisation and Server Push provide many additional benefits:
As the administrator of your website or web application, you can choose to run your server using the HTTP/2 protocol. This will provide you with the best possible stability and user experience. Even though you have no control over the HTTP version that the web browser or client is using.
HTTP/2 is a binary protocol, and therefore requires fewer bytes.
While the HTTP request and response formats have remained the same, the way they are stored and sent has changed.
The headers of a request or response, and the actual content are stored in separate frames. These messages, which are a collection of frames, are sent over one or more streams.
The headers of HTTP requests and responses contain certain metadata. In HTTP/1.1, headers were stored in plain text, which resulted in a lot of overhead, especially when cookies and security tokens were sent along with them.
HTTP/2 compresses the headers using the HPACK compression algorithm, which helps reduce the size of the header by an average of 30%. The advantage is particularly great for HTTP requests, as these often do not contain a request body. Some studies even report a 53% reduction in incoming traffic.
An HTTP/2 connection provides multiple streams via which messages can be sent.
This means that a single TCP connection can be used to send multiple HTTP requests and responses simultaneously.
A web server that supports HTTP/2 therefore has to accept far fewer connections and remains much more stable.
Another advantage is that the Head-of-line blocking issue is also solved at the level of HTTP.
With HTTP/1.1, the various components of a website are received serially. The order in which the various resources are received completely depends on the browser.
Developers can indicate whether additional content should be sent along with an HTML file. This is done via a "Link" response header, which can look like this:
Link </style.css>;rel=preload, </framework.js>; rel=preload
Although TLS (Transport Layer Security) encryption is not a specific part of the HTTP/2 protocol, browsers do require all HTTP/2 connections to be established using TLS.
When drafting the protocol specification of HTTP/2, the creators of several web browsers used their leverage to require HTTPS URLs to be sent using TLS version 1.2 or later. Old SSL encryption protocols via HTTP/2 are no longer supported.
HTTP/3 is the successor to HTTP/2, and uses the same principles such as:
For transport and encryption, HTTP/3 uses the QUIC protocol. QUIC (Quick UDP Internet Connections) was developed by Google to overcome the limitations of HTTP/2.
It is a low-latency transport protocol designed to make HTTP faster. It is based on the UDP protocol. It does not use a three-way handshake or congestion control, and it will not attempt to redeliver a failed packet. This makes UDP very simple and fast.
HTTP/3 uses the same recipe for success as HTTP/2, but adds a few enhancements.
HTTP/3 is still in an experimental phase. Today, both browsers and servers have different implementations. The protocol is still "in draft" at the IETF (Internet Engineering Task Force).
Recent versions of Chrome, Firefox, Safari and Edge provide support for HTTP/3, but this option is disabled by default.
For the time being, popular web servers do not yet offer full support for HTTP/3.
In the future, HTTP/3 will be the HTTP protocol of choice anyway. But we are not there yet. Since HTTP/1.1 is still very common, HTTP/2 will be a transition version to HTTP/3 for more and more organisations.