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: