What is HTTP/3? The next-generation web protocol

It’s no surprise that evolving the vast protocol infrastructure that underlies the internet is an epic proposition. The next major version of HTTP is built on the QUIC protocol and promises better performance and more security. Here’s what web application developers need to know.

The promise and perils of HTTP/3

HTTP/3 aspires to make the internet safer, faster, and simpler for everyone. If these goals sound familiar, it’s because they’re the same ones that HTTP/2 started with. That’s an interesting tale, but the bottom line is that HTTP/3 takes another pass at addressing long-standing shortcomings in both TCP and HTTP. What’s surprising is that the new protocol bypasses HTTP/2 entirely and adopts the QUIC protocol as its base.

The quick take on HTTP/3 is: Build TCP 2.0 on top of UDP and call it QUIC. Then, rebuild HTTP/2 on QUIC and call it HTTP/3. If that sounds strange, it’s because it is. For one thing, most deployed hardware and software were designed to speak to the existing protocols. It’s not feasible to wholesale reconfigure network appliances to adopt a new version of TCP, which in theory would be the right place to start. This approach would address many of the issues with HTTP/2 but leave mountains of failing appliances in its wake. Instead, we get HTTP/3.

HTTP/3 at a high level

There are two specs at work in HTTP/3: the specification itself and the QUIC protocol. Together, they form a thicket of technical and practical complexity. Taking a high-level view will help us make sense of the technology and what it hopes to achieve.

To start, we can break HTTP/3’s features into three big buckets:

Built-in encryption
Multiple byte streams (multiplexing)
Connection resilience

Let’s look at each of these in turn.

Built-in encryption

Although built-in encryption is a security feature, it also turns out to be a performance enhancement. This is because the way encryption is negotiated in HTTP/3 reduces the number of roundtrips required.

Encryption on the web has a long history, which includes the deprecation of SSL in favor of TLS. In general, the move has been to better implementations and more default encryption. HTTPS is the default for most web traffic now, and in HTTP/3 we’ll see the elimination of the plaintext (“ option entirely.

More about encryption
For a good starting point on understanding encryption, try my introduction to the Diffie-Hellman key exchange protocol.

HTTPS will still be used as a mechanism for establishing secure connections, but traffic will be encrypted at the HTTP/3 level. Another way to say it is that TLS will be integrated into the network protocol instead of working alongside it.

So, encryption will be moved into the transport layer and out of the app layer. This means more security by default—even the headers in HTTP/3 are encrypted—but there is a corresponding cost in CPU load. Overall, the idea is that communication will be faster due to improvements in how encryption is negotiated, and it will be simpler because it will be built-in at a lower level, avoiding the problems that arise from a diversity of implementations.

In addition to encryption, QUIC is intended to deliver integrated DDoS protection and “forward” security, wherein it is more difficult for an attacker to compromise past communications even if participants later leak secrets.

Multiple byte streams, or fine-grained multiplexing

If you are familiar with how HTTP/2 works, you’ll be thinking that it already does multiplexing. Multiplexing was, in fact, one of the main features of HTTP/2. HTTP/3 just does it in a new and better way. In particular, HTTP/3 looks to fix the head-of-line blocking problem (HOL).

Ideally, we would fix this blocking issue directly in TCP. When we run HTTP over TCP, we can (and do) send several different files together simultaneously. This is our present incarnation of multiplexing. When you open a website, the server wants to send as many files at once as possible. This is good for speed and efficiency. HTTP/2 allows it, but TCP doesn’t understand multiplexed files. To TCP, they’re all one big chunk. Worse, if any of them fails, it has to restart all the files within that stream.

HTTP/3’s new protocol is QUIC, which is kind of like TCP 2.0. It builds that notion of granular files into the streams so they can be restarted in a more fine-grained way. Even better, it does so without tearing apart all the existing TCP infrastructure.

Connection resilience

What we mean by connection resilience is that when a device moves across networks, there is a mechanism for retaining the same connection between client and server.

In TCP, that continuity isn’t possible because the protocol only understands the IP address and port number. If either of those changes—as when you walk from one network to another while holding a mobile device—an entirely new connection must be established. This reconnection leads to a predictable performance degradation.

The QUIC protocol introduces connection IDs or CIDs. For security, these are actually CID sets negotiated by the server and client. So HTTP/3 connections use an IP address, port, and a CID, allowing them to persist a connection even when the network changes and a new IP or port is established. This gives the protocol a kind of conversational persistence.

HTTP/3 implementation

I’ve mentioned that HTTP/3 is built on top of the QUIC protocol, which is essentially a new version of TCP. QUIC is a protocol with a history and ongoing evolution, but what you need to know for the purposes of HTTP/3 is that it builds several features onto the ancient User Datagram Protocol, or UDP.

UDP

UDP is a bare-bones protocol implemented by almost all network devices and software. It is used for DNS lookups. Its ubiquity and simplicity make it a solid foundation for the newest version of HTTP.

Unlike TCP, UDP is connectionless and has no network optimization logic. The QUIC protocol builds on top of UDP and adds these necessary elements. In essence, we are implementing a better network layer that learns from decades of experience in actual internet use.

QUIC

While UDP is connectionless, QUIC is not. QUIC uses acknowledgments (ACKs) to establish and maintain a connection. QUIC also supports packet redelivery. These features are just like TCP, except with improvements designed to deliver the three goals we’ve already discussed: built-in encryption, reduced network roundtrips, and persistent connections.

QUIC is the core of HTTP/3 and it reimplements the basic elements of TCP (like acknowledgments and redelivery) in a more performant and secure way based on real-world experience. UDP was used as the basis of QUIC because it’s a well-established protocol that provides a minimal baseline for implementation.

QUIC is also designed to be extensible, which lets us avoid the situation we are presently in with TCP. The QUIC protocol uses frames, which encapsulate particular datagram uses and can be added in the future without breaking existing use cases.

The current and future state of HTTP/3

All the features, protocols, and the HTTP/3 specification itself are in ongoing development, even though QUIC is already being used in browsers and other projects.

HTTP/1, HTTP/2, and HTTP/3 will continue to coexist for the foreseeable future. Sources indicate that HTTP/1 still accounts for almost 30% of web traffic. HTTP/3 will proceed on a similar adoption by request model. For now, HTTP/3 exists as a more advanced network layer that will expand into widespread use as more participants support it. It remains to be seen just how well HTTP/3 will deliver on its promises when deployed at scale.

For most working programmers, this change is an interesting fact about the world in which we live and work, but it won’t directly impact the code we write. We won’t be building QUIC clients directly, for example. Of course, this change is more important for network admins and system operators, and anyone else who needs to analyze and understand network traffic. (In fact, QUIC’s encrypted nature has been a sticking point among some network operators because it makes it harder to identify patterns and determine when users are abusing the network.)

Conclusion
HTTP/3 is a significant feature of the web landscape going forward. Every programmer doing web development will want to understand how it works at a high level, at least. See the following resources to learn more about HTTP/3 and its components:

RFC 9114: Details and history of the HTTP/3 proposal.
RFC 9000: Details and history of the QUIC proposal. Also see the QUIC RFC summary here.
Smashing Magazine has a good, in-depth series on HTTP/3, including performance improvements.