This article presents the main advantages but also the challenges that come with the HTTP/3 protocol which seems to be the future of a better web performance.
In our previous article “Using HTTP/2 protocol can boost your web performance”, we address main performance limitations of older HTTP/1.x protocols and how HTTP/2 addresses them to improve web performance. While we still see migrations from HTTP/1.1 to HTTP/2 delivered services, the market already sees the future HTTP/3 protocol coming.
So will the HTTP/3 protocol improve web performance?
HTTP/2: what’s the limit?
HTTP/2 introduced the concept of multiplexing multiple HTTP transactions in a single TCP connection. This aimed at solving the problem of Head Of Line (HOL) blocking, one of the major performance problems encountered by modern digital services.
Multiplexing certainly helps in case of high performance networks. Unfortunately, it becomes inefficient for networks that suffer from packet loss. Even worse, using HTTP/2 in such low performance networks can in fact degrade overall performance compared to using its HTTP/1.1 counterpart. This is because while the HTTP/2 layer can segregate different HTTP transactions on dedicated streams, TCP has no knowledge of this abstraction. All it sees is a stream of bytes, so that packet loss equally impacts all HTTP transactions!
As a conclusion, using HTTP/2 protocol does not completely solve the HOL blocking problem…
This is where HTTP/3 comes into play to help improve web performance! Instead of using TCP as the transport layer for the session, it uses QUIC, a new Internet transport protocol.
So in order to understand what HTTP/3 is all about, let’s first discuss the main QUIC protocol characteristics.
What is QUIC?
QUIC stands for “Quick UDP Internet Connection”. It is a new encrypted-by-default Internet transport protocol, that introduces a number of improvements designed to accelerate HTTP traffic as well as make it more secure.
So as its name suggests, QUIC does not rely on the TCP transport protocol used in traditional HTTP/1.x and HTTP/2 communications.
Built on top of UDP, QUIC adds a series of capabilities to it in order to make it reliable. It also attempts to solve the major issues experienced when using the TCP protocol, which are:
- connection-establishment latency
- multi-stream handling in the presence of packet loss
Currently, this specification is an IETF Internet Draft.
TCP-driven latency solved
When a TCP session is established, it generally triggers the TCP congestion control algorithm. It assesses how much traffic can be sent before congestion occurs through the slow start process.
By relying on UDP and supporting first-class streams, QUIC solves this connection slow-start latency.
HOL blocking problem solved
QUIC goes a bit deeper and provides first class support for multiplexing such that different HTTP streams can in turn be mapped to different QUIC transport streams. But, while they still share the same QUIC connection so no additional handshakes are required and congestion state is shared, QUIC streams are delivered independently. So in most cases packet loss affecting one stream doesn’t affect others.
It makes QUIC much more resilient to packet loss conditions and so much more efficient for poor or lossy internet connections.
Built-in security (and additional boost in performance)
One of QUIC’s more radical deviations from the now venerable TCP, is the stated design goal of providing a secure-by-default transport protocol. QUIC accomplishes this by providing security features, like authentication and encryption, that are typically handled by a higher layer protocol (like TLS), from the transport protocol itself.
By design, QUIC relies on the version 1.3 of the TLS specification.
The initial QUIC handshake combines the typical three-way handshake that you get with TCP, with the TLS 1.3 handshake. This provides authentication of the end-points as well as negotiation of cryptographic parameters. Not only does this ensure that the connection is always authenticated and encrypted, but it also makes the initial connection establishment faster as a result. The typical QUIC handshake only takes a single round-trip between client and server to complete, compared to the two round-trips required for the TCP and TLS 1.3 handshakes combined.
What is HTTP/3?
The QUIC protocol may potentially support any application on top of it. This said, the first implementation is HTTP, so that HTTP running over QUIC is called HTTP/3.
In summary, we can differentiate between the different HTTP specifications as follows:
- HTTP/1 – ASCII over TCP
- HTTP/2 – binary multiplexed over TCP
- HTTP/3 – binary over multiplexed QUIC
In addition to that, if we take into consideration the built-in TLS specification, the HTTPS stacks can be schematized as follows:
How does a client connect in HTTP/3?
Usually, when a client connects to a server that supports HTTP/3, it first connects in traditional HTTPS on TCP port 443.
The server then answers with a specific “Alt-Svc” (alternative service) response header. It provides the location where the same requested resource is available through HTTP/3. This alternative service is defined by a protocol/host/port combination.
The client’s browser typically caches this information so that it avoids having to establish the initial TCP connection the next time it needs the same resource.
As alternative, when requesting the IP address corresponding to the server FQDN (Fully Qualified Domain Name), the client could get the HTTPS RR (Resource Record) from the DNS response. In this case, it is being informed that the server supports HTTP/3 before connecting to it.
HTTP/3: the future de facto standard ?
HTTP/3 promises to make Internet connections faster, more reliable, and more secure.
As previously mentioned in this article, HTTP/3 is still being defined by IETF. There is no official release date set yet. Meanwhile, adoption of HTTP/3 is growing, with almost 400,000 services using it across the globe. Google is still the top organization to deploy HTTP/3, but several others take a non-insignificant share.
Nearly 19% of the worldwide websites support HTTP/3 today.
From a browser standpoint, HTTP/3 is now supported by default on the latest releases of the major browsers players.
The HTTP/3 adoption is growing, but there are still major challenges to address before seeing a massive move on the market.
Let’s quickly summarize some of them.
Ossification
The backbone that forms the Internet is full of boxes: routers, gateways, firewalls, load balancers, and so on. These typically run software to handle network traffic, which is seldom upgraded.
This phenomenon is often referred to as “ossification”. It means that a lot of these equipments are not able to understand QUIC yet.
One example is NAT routers. Seeing that most NAT routers in the wild do not understand QUIC, they typically fallback to the default and less precise handling of UDP flows, which usually involves using arbitrary, and at times very short, timeouts, which could affect long-running connections.
Security concerns
Security vendors are not big fans of UDP. UDP is often used for cyber attacks like DDoS.
In addition to this, seeing that QUIC is encrypted by design, security vendors are unable to analyze the data payload to detect any potential abnormal behavior and potential security threats.
As a result, some networks will consciously block QUIC!
Performance & other concerns
Endpoints devices are usually optimized for handling TCP traffic, but not for UDP.
As an example, while most of the devices support the TCP offloading feature at their network interface cards level, supporting this performance optimization technique for UDP traffic is not mainstream.
Compared to its counterpart TCP, UDP also suffers from a lack of APIs support. This is also the case for TLS libraries over QUIC, as QUIC only makes use of TLS messages, not the TLS records. TLS is a big topic and will be addressed in future blog articles.
Wrap-up
HTTP/3 is a really promising protocol.
It offers performance improvements, especially in case of non-optimal network conditions.
Thanks to its secure-by-design approach, it will also play an important role in securing the Internet.
This said, there is no real benchmark yet available that really measures the performance boost that HTTP/3 may bring.
Furthermore, the HTTP/3 adoption process is definitely slower compared to HTTP/2 due to the lack of native support for QUIC and related security considerations around the usage of the UDP layer.
