HTTP/2 and HTTP/3

Avoid slow loading for your users

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:

  • Increased stability
  • Faster load times
  • Advanced connection security

Also next in line, HTTP/3 is already supported by several web browsers and will offer even more benefits in the future.

Cloud back-up

What is HTTP?

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.

  1. A web client sends an HTTP request to the web server.
  2. A web server receives the request.
  3. The web server sends an HTTP response to the web client.
  4. The web client receives the response.

What is HTTP/2?

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.

The limitations of HTTP/1.1

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.

Web browsers usually limit the number of parallel connections to six per server. This can result in Head-of-line blocking, meaning that requests have to wait for other requests to complete before they can be sent. This phenomenon is increasingly common in modern websites that make extensive use of images, web fonts, as well as CSS and JavaScript files.

How HTTP/2 avoids overloading

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.

The benefits of HTTP/2

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:

  • More compact and efficient data flows between client and server
  • Reduced server load
  • Effective use of network resources
  • Reduced network delay

Learn more about the benefits of HTTP/2

HTTP/2 for your website or application

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.

How does HTTP/2 work?

  • Binary protocol: fewer bytes

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.

Thanks to frame prioritisation, the browser determines which components it wants to receive first. Blocking resources such as CSS and JavaScript files located in the section are usually given the highest priority.

The order in which CSS files, JavaScript files, images and web fonts are loaded, however, differs from one browser to another, which can result in differences in user experience.

HTTP/2 also supports frame prioritisation at the level of the server. The browser sends multiple requests to the server in rapid succession, just as with HTTP/1.1. However, the server can choose to return the files in a different order. In addition, the files do not have to be sent in their entirety; they can also be fragmented.

When you visit a website, your browser first downloads an HTML file. It then checks what other files are required to display that HTML file properly. These files include images, web fonts and CSS or JavaScript files. These files are then requested by the web client via new HTTP requests.

Thanks to Server Push feature of the HTTP/2 protocol, the web server can also send other data with the HTML, such as all JavaScript and CSS files. This allows the browser to display the page directly, without having to send a new request to the server. This method allows web pages to load more quickly.

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

In this example, "/style.css" and "/framework.js" are already sent along with the HTML file, knowing that the browser will need them later.

Support for the Server Push feature of the HTTP/2 protocol depends on the web server and the way it is configured.

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.

What is HTTP/3?

HTTP/3 is the successor to HTTP/2, and uses the same principles such as:

  • Binary protocol
  • Header compression
  • Multiplexing based on streams and frames
  • Server Push
  • TLS encryption

The key difference is that HTTP/3 is not based on TCP (Transmission Control Protocol), but on UDP (User Datagram Protocol). UDP does not use a three-way handshake and is simpler than TCP.

In order to make HTTP/3 as reliable as HTTP/2, the above principles have been built into the protocol.

QUIC: the foundation of HTTP/3

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.

Why HTTP/3?

Although HTTP/2 fixes the Head-of-line blocking issue at the level of HTTP, there may be underlying Head-of-line blocking issues at the level of TCP.

Network congestion can result in packet loss. This may affect several HTTP/2 streams, while the packet loss only concerns one request. As a result, the whole TCP connection comes to a standstill, resulting in a Head-of-line blocking at the level of TCP.

Once a certain amount of packet loss is reached, the situation becomes so critical that HTTP/2 becomes even slower than HTTP/1.1.

The benefits of HTTP/3

HTTP/3 uses the same recipe for success as HTTP/2, but adds a few enhancements.

  • Faster connection: HTTP/3 uses the simple UDP protocol, which makes it much faster to establish an HTTP/3 connection.
  • A solution to deal with packet loss: The implementation of transport logic allows HTTP/3 to deal with possible packet loss. The correct packet can thus be requested again and delivered to the appropriate stream, without blocking all the other streams.
  • No overload: HTTP/3 supports request multiplexing, without Head-of-line blocking at the level of the HTTP or TCP protocol.
  • No delay due to a TLS connection: HTTP/3 uses TLS 1.3 and supports zero roundtrip time connection resumption. Unlike HTTP/2 and HTTP/1.1, HTTP/3 therefore does not require an additional handshake to establish the TLS connection. The client can send data as soon as the connection is established. It is therefore not necessary to wait for the TLS confirmation from the server.

HTTP/2 or HTTP/3?

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.

Do you want to avoid overload and slow responses on your server?

Let our experts guide you

Contact our server experts now

Let our experts guide you

Awards

Smart Business Awards Hosting & Domain Names 2017
ISPGids
Twinkle Awards Hosting & Domain Names 2016
Webhosters.nl