HTTP/3 is the third version of the HyperText Transfer Protocol(HTTP) developed by IETF and is considered to be the successor of HTTP/2. Unlike its predecessor, it is built on top of a different protocol, QUIC. Why did HTTP/3 have to exist when HTTP/2 was only standardized in 2015? To understand and probe this question properly, you need to understand how HTTP as an internet protocol evolved.
A brief history of HTTP (HTTP/1.1, HTTP/2, HTTP/3)
The official version of HTTP was finalized and deployed in 1996. In the following year, 1997, HTTP/1.1 was released to address the practical implementation issues that the first version had and update part of the general standards of operation.
As the technology evolved, the speed and response time of large-scale websites and applications became more important, and the limitations of HTTP/1.1 became more evident. In practice, HTTP/1.1 requests for one resource at a time over a TCP connection. Subsequently, the to-and-fro request of multiple files sequentially would pose a problem of delay. When there’s an issue with a file request, the rest of the pending requests would have to wait for the issue to be resolved before their transmission can start. Put differently, an issue with a file request puts incoming requests on hold until it is resolved. This phenomenon is called Head-of-Line blocking(HoL).
HTTP/1.1 has a workaround for minimizing the effect of HoL. Browsers can open multiple TCP connections and request resources in parallel, but it is resource-intensive. Opening a TCP connection requires a TLS handshake to ensure that the client and server exist, and setting up encryption mechanisms to provide security during data transmission. This bottleneck and other related ones led to the development of HTTP/2.
HTTP/2 was released 18 years later in 2015 after getting standardized by RFC 7540 as the next major version of HTTP. This was a milestone for the internet as a whole because this new version of HTTP hoped to solve a lot of problems around the speed of applications on the internet. HTTP/2 emerged with a solution to data transmission speed via multiplexing. Conceptually, multiplexing is used to combine multiple communication signals(analog or digital) into one signal for processing and return results as different signals. HTTP/2 uses this technique to request multiple resources in one TCP connection(saving resource cost) and download the responses in parallel. This approach limits the HoL effect but it doesn’t eliminate it. Why?
The drawback on HoL in HTTP/2 came from TCP, not HTTP/2. As with HTTP/1.1, an issue with a resource request(usually packet loss) causes an imminent delay in the request for other resources. This is because TCP handles packet loss by retransmitting the data before processing incoming requests.
Technically, an improvement in TCP would ensure HTTP/2 remains a viable solution to the most important speed problems in data transmission including HoL blocking. Instead, the internet got HTTP/3!
HTTP/3, unlike its predecessors, has QUIC(discussed later) as its transport layer instead of TCP. QUIC is built on top of the User Datagram Protocol(UDP). As you would see later in this article, HTTP/3 is just HTTP/2-over-QUIC, the transport layer makes all the difference.
What is QUIC?
QUIC(pronounced ‘quick’) was initially an acronym for Quick UDP Internet Connections but was later named as a protocol itself. QUIC was designed to improve the performance of web applications currently using TCP for data transmission. It was designed to serve the internet like TCP but with lower latency(the time taken for data transmission), thanks to UDP.
Major features of QUIC.
Reduced overhead during connection setup
As said earlier, client/server connections done via TCP require practical TLS handshakes from the remote servers, and these handshakes are subject to the physical distances of the servers from each other. QUIC does not eliminate the need for this handshake as some resources claim, instead, it employs a more complex form of handshake ensuring that data transferred are secure. It is noteworthy that UDP as the underlying protocol of QUIC doesn’t perform any form of handshake before transmission.
Multiplexing without Head-of-Line blocking
QUIC sends multiple requests to a server as a single request for processing, and if there’s a case of packet loss, it continues the download of the server response without waiting for the retransmission of lost data. The retransmission of lost packets is handled by opened connection streams at QUIC-level in future transmissions. This is also a common misconception; because QUIC uses UDP doesn’t mean it doesn’t make up for lost data. It only handles them differently from TCP, enabling a more performant data transmission mechanism with HoL blocking out of the way.
Although QUIC is presented as a solution to HoL blocking, the extra connection streams in use can also be resource-intensive when there are bulky packet losses and eventually HoL blocking can still get back in the picture. But, that is in extreme cases. A beneficiary of QUIC on a very slow internet connection will still enjoy its benefit. Otherwise, there wouldn’t be much difference in HTTP/2 and HTTP/3 for an average internet user with a good internet connection.
Uses of UDP vs TCP.
|UDP is a connectionless network protocol i.e it doesn’t require any preflight request to establish a connection for data transmission.||TCP is a connection-oriented network protocol and requires an established connection to transmit data.|
|Data transmission is not ordered.||Data transmission is ordered i.e sequential.|
|There is no guaranteed data delivery.||Data delivery is guaranteed and reliable.|
|Faster than TCP.||Slower than UDP.|
With the foundation of QUIC laid, what direct impact does it have on web performance via HTTP/3?
What’s the impact of HTTP/3 on web performance?
Connecting the dots, HTTP/3 is HTTP/2 on top of QUIC running on top of UDP – a connectionless protocol that doesn’t require a connection setup for data transmission. This implementation of HTTP provides a number of advantages to the web, but as you would see these advantages can only be enjoyed in certain cases.
0-RTT or zero Round-Trip-Time and faster connection set-up.
RTT is the time taken for a complete to-and-fro trip from a client(e.g a web browser) to a server. In HTTP/2, the TCP-TLS handshake has to take place in different requests before data transmission can commence. This takes exactly 3-RTT in TLS 1.2 and 2-RTT in TLS 1.3 (the most recent). Contrary to common notions that HTTP/3 is two to three times faster than HTTP/2, that’s only half-true with its validity limited to TLS 1.2. HTTP/3 performs the QUIC-TLS handshake in one flight saving at most one more round-trip with respect to HTTP/2. Technically, zero Round-Trip-Time is more of 1-RTT than zero (to nullify the misconception), but the connection set-up is faster.
Head-of-Line blocking removal.
This performance feature is intended to make QUIC faster on networks with a high amount of packet loss. However, it depends on a lot of factors. Usually, the best case scenario for this benefit from HTTP/3 is for resources that are render-blocking. In this case, multiple active streams will make up for the packet loss by retransmitting the lost packets as new ones to the client rather than waiting for them.
Because HTTP/3 is on QUIC, there is no possible way to send unencrypted data or (more technically), cleartext HTTP. This limits the options for eavesdroppers to listen on and provides tighter network security in the process.
As you might have noticed, most of the performance benefits coming from HTTP/3 are indigenously from QUIC. This also means the widespread acceptance of HTTP/3 will spring from the server support that will be implemented for QUIC in the nearest future.
Web browser support for HTTP/3
According to caniuse.com, 75.33% of browsers on the internet currently support HTTP/3. These browsers include Google Chrome, Mozilla Firefox, and Microsoft Edge. Chances are you’ve used HTTP/3 if you’ve visited google.com recently. If you want to test if your browser is using http3, visit https://cloudflare-quic.com.
Web server support for HTTP/3
Web servers, load balancers, firewalls, and all other firmware available on the internet uses internet protocols like TCP and UDP to communicate with each other. While it’s fairly easy to configure HTTP/3 on a modern browser, that’s not the case with these middleboxes.
Because these middleboxes exist between the client and the server, changing the network protocol on the server requires a change in the network protocol on their end also. However, if a web server is already using HTTP/2, there wouldn’t be any out-of-the-box changes needed because HTTP/3 is really just HTTP/2-over-QUIC.
Interestingly, some web servers already support HTTP/3 (although most are experimental). They include:
- NGINX(quic.nginx.com).This has experimental support as they’re working towards an official release in the near future.
- Nodejs. It uses the ngtcp2 library internally. They plan to upgrade to a QUIC-TLS fork to get a dash of HTTP/3 into the ecosystem.
- IIS. As a native server for most Microsoft applications, it’s most likely using the MsQuic library.
- Caddy. Caddy uses the quicgo library with full support.
- Litespeed. Litespeed uses LSQUIC with full support.
Of all these servers only Litespeed and Cloudflare’s NGINX patch were developed by people heavily involved in the QUIC-HTTP/3 standardization. Undoubtedly, these implementations will see more progress in the nearest future than the rest.
As said earlier, even though there are some servers that support HTTP/3, that’s only the first step. Configuring HTTP/3 for the rest of your network(load balancers, firewalls, etc) is much more difficult.
Library support for HTTP/3.
If you’re a developer or site owner looking to experiment with HTTP/3 in code, the following libraries provide libraries for this purpose.
- Go – quicgo
- Python – http3 and aioquic
- Rust – quiche, nego, and quinn
- C – nghttp3 and isquic
Switching to HTTP/3 for WordPress sites.
Enabling HTTP/3 on a WP site is largely dependent on your hosting provider. Sadly, popular hosting providers like Hostgator and BlueHost do not currently support HTTP/3. NameHero, on the other hand, boasts of production-ready support for HTTP/3 by using QUIC cloud CDN services that tie right into Litespeed.
It is important that you consider all other services that are running on your WordPress site before choosing to migrate to HTTP/3. This is because configuring all the devices on your network is a lot harder in practice. Of course, you can choose to experiment with a test site.
10Web does not currently support HTTP/3, but it will be implemented sometime later. To know when this support is added, stay up-to-date on our blog.
Fallback for browsers not supporting HTTP/3.
As you might have guessed, it’s either a browser supports HTTP/3 or it doesn’t since most websites and web applications do not support HTTP/3. HTTP/2 and HTTP/1.1 are still largely in use with no significant speed caveats for an average user.
Whether you’re a site owner or a web developer, you can benefit maximally from HTTP/3 by putting the experience of your average user into consideration and examining how the performance features discussed above would influence their experience. Thereafter, you should take careful note of the resource cost and the value your choice would bring.