A closer look at HTTP/3

The transport layer protocols

Before we start exploring HTTP/3 I think it is important to touch upon the fundamental construct on top of which HTTP/3 is built.

Transport protocols are a set of guidelines that manage the transmission of data over a network. They ensure error detection, data integrity, and the ordered delivery of packets. The two most common transport layer protocols in use today are User Datagram Protocol (UDP) and Transmission Control Protocol (TCP).

HTTP (Hyper Text Transfer Protocol) is an application layer protocol built on top of TCP. It is the foundation of data communication on the World Wide Web. HTTPS which is what is used more widely. One salient feature of HTTP is its statelessness, meaning each request from the client to the server is treated as independent. This promotes scalability, as servers do not need to manage sessions. However it also has tradeoffs where you need to have some state maintained like managing user sessions. That bit becomes tricky for example with HTTP.
HTTPS (Hyper Text Transfer Protocol Secure) is the more predominantly used form. It incorporates encryption to protect data transmitted between the user’s browser and the web server.

HTTP/3 is a major revision of the HTTP protocol, which builds upon and improves previous versions, notably HTTP/2. The key difference lies in its transport layer protocol - HTTP/3 utilises QUIC rather than TCP.

Exploring HTTP/3

Developed by Google, QUIC (Quick UDP Internet Connections) is designed to provide a more efficient, faster alternative to TCP, the traditional transport protocol used by HTTP. QUIC operates over UDP, allowing for reduced connection latency and improved throughput. HTTP/3 was officially published as a proposed standard by the Internet Engineering Task Force (IETF) in 2021.

HTTP/3 significantly reduces connection latency with a zero-round-trip time (0-RTT) connection setup capability, meaning repeated connections can occur nearly instantaneously without renegotiating setup protocols. HTTP/3 also comes with built-in encryption integrating the TLS1.3 protocol thus leading to enhanced data security and privacy.

0-RTT connection - under the hood

Initial Handshake: When a client first connects to a server using QUIC (the transport layer protocol underlying HTTP/3), they perform an initial handshake that includes both the connection establishment and security negotiation. This involves a client sending a packet to the server containing its connection ID and some cryptographic parameters. Cryptographic parameters are outside the scope of this discussion. The server then responds with its own packet containing its connection ID and cryptographic parameters. This establishes a secure tunnel using TLS 1.3.

Once the initial handshake is complete, the client saves certain connection parameters (like session tickets) provided by the server. If the client reconnects to the same server, it uses this stored information. This is how it is able to resume sessions.

This is critical because the parameters contain the keys that have already been negotiated, allowing the client to "resume" the previous session.

Some of the other important aspects of how this is achieved and the considerations are as below:

1. Immediate Data Transmission:

   • During a subsequent connection attempt, the client can send data immediately (e.g., HTTP request headers or payload) within the same packet that requests to establish a connection. This is possible because the client knows that the server has previously recognised its connection parameters.

   • The server, upon receiving this packet, can process the data right away, as it is already familiar with the cryptographic keys and connection settings from the previous session.

2. Security Assurance:

   • To maintain security, 0-RTT data can be subjected to additional limitations. For instance, the server must validate the client’s ability to send data without a complete handshake. If security threats are detected, the server can reject the 0-RTT data and require a full handshake instead.

3. Fallback Mechanism:

   • If the server does not support 0-RTT or if there is any reason to reject the initial request, the client can still fall back to a complete handshake that requires one round trip. This failsafe ensures that connections remain secure.

HTTP/3 (over QUIC) versus HTTPS (over TCP)

HTTP/3 significantly reduces latency and improves performance, particularly for repeat connections and real-time applications. Also HTTP/3’s design allows for better handling of packet loss and connection migration without interruptions, whereas HTTPS over TCP can struggle with latency due to its reliance on TCP’s behaviour.
HTTP/3 also incorporates encryption more seamlessly, while HTTPS over TCP requires a separate layer for TLS, making HTTP/3 inherently more efficient.
Also while both protocols offer multiplexing HTTPS suffers from head of the line blocking. HTTP/3 resolves the head-of-line blocking issue, because it handles streams independently thus allowing for multiple dynamic requests simultaneously.
Below is a comparison chart that I thought will be easier to consume.

Usecases

Given the significant improvements it isnt hard to imagine some of the tangible usecases that emerge out of this.
Here are a few examples that I could think of broadly but there would be many more

1. Video Streaming:

   • Services like YouTube and Netflix can benefit from HTTP/3 by reducing latency and improving video load times, particularly in scenarios with poor network conditions.

2. Online Gaming:

   • Fast-paced online games rely on low latency for performance. HTTP/3 can enhance gameplay experiences, particularly for multiplayer games where real-time interaction is crucial.

3. Content Delivery Networks (CDNs):

   • CDNs like Akamai and Fastly are exploring HTTP/3 to speed up the delivery of static resources across various geographical locations, optimizing load times for websites globally.

4. E-Commerce:

   • E-commerce platforms can enhance user experience through quicker page loads during peak traffic times, improving overall conversion rates.

5. Mobile Applications:

   • Mobile apps that interact with web services can reduce load times and improve responsiveness, particularly in areas with fluctuating network conditions. This is an area that I am looking to explore a lot more

Some notable adaptors

Cloudflare: Cloudflare has been looking to implement HTTP/3 and has taken significant strides. They offer detailed documentation and resources on HTTP/3, its benefits, and how it works.
Resource: Cloudflare's HTTP/3 documentation
Google Chrome: Google has actively supported HTTP/3 in Chrome. The release notes on Chrome’s developer homepage include information about HTTP/3 and its use cases in modern web applications.
Resource: Chrome for Developers
Mozilla Firefox: Firefox has also implemented HTTP/3 and provides insights on its use and benefits in real-world applications.
Resource: Firefox and HTTP/3
Node.js: Node.js has experimental support for HTTP/3 through the quic package, allowing developers to experiment with QUIC and HTTP/3 in their applications.
Resource: Node.js HTTP/3 support
Keenetic: A router manufacturer implementing HTTP/3 in their networking devices, aiming for enhanced performance and lower latency.

But what are the challenges?

If most things are so much more better, what is the catch?
Let's first address the 0-RTT tradeoffs
Since 0-RTT allows clients to send data before the connection is fully secured, there is a risk of replay attacks. To mitigate this, servers implement mechanisms to detect and reject duplicate messages.
Also not all types of requests are suitable for 0-RTT. The first request after a connection can involve operations that require fresh security states, meaning some interactions still necessitate full handshakes for every new connection.

Still early days

Given it is still in the roll out stages it has a few other teething issues. Like infrastructure compatibility with existing servers. Meaning, HTTP/3 requires updates to existing servers, network infrastructure, and client software. Network appliances and middleboxes may need complex upgrades to support UDP efficiently.
Also debugging and monitoring will be harder in the absence of enough tools because QUIC encrypts more of the transport layer. Traditional network monitoring and troubleshooting tools will need a lot more adaption to effectively diagnose issues within the HTTP/3 traffic.
And then there are the adoption challenges. Getting widespread adoption from providers and consumers can take significant time due to the entrenched and well-optimized nature of HTTP/2, requiring education and demonstration of the benefits and incentives for switching. Since HTTP/3 relies on UDP, it may face issues with network environments that restrict or deprioritise UDP traffic compared to TCP, potentially affecting performance.

While HTTP/3 represents a significant leap forward in web technology, offering considerable benefits in terms of speed, efficiency, and security. Its adoption, however, comes with challenges that need to be addressed through comprehensive updates and education. As the web continues to demand faster and more reliable connections, HTTP/3 is poised to play a vital role in the future of digital communication of which I have zero doubts.

In fact one of my pet projects is based on HTTP/3 on which I will provide a detailed blog sometime soon.