QUIC will soon be as important as TCP

Jump to main content

Search

REG AD

Networks

QUIC will soon be as important as TCP – but it's vastly different

Deciphering the third transport protocol's four RFCs is a task to rival the proverbial blind man trying to understand an elephant

Bruce Davie

Bruce<br>Davie

Published<br>thu 16 Apr 2026 // 08:30 UTC

While Larry was producing most of the content for the "Request/Reponse" chapter for the next edition of our book, I took the lead on writing a section on QUIC, since I have closely followed its development.

Our expectation is that the role of QUIC will be about as important as that of TCP in the coming years, which means it warrants more substantial coverage than we provided in the last edition. So I dug a bit deeper into the bits and bytes of QUIC than I have previously, with a goal of bringing the coverage up to par with our TCP coverage. In addition to reading through the RFCs, I found lots of good information in the original QUIC design spec as well as some conference publications on the design and evaluation of SPDY (predecessor of HTTP/2) and QUIC.

One rather trivial thing that makes it harder for me to get to grips with QUIC is the fact that its RFCs (four of them, spanning hundreds of pages) lack pictures of the packet headers. The rationale for this, I believe, is that QUIC makes extensive use of fields that are variable in length and frequently not aligned on 32-bit boundaries, which makes packet header pictures a bit complicated and less tidy. I decided to have a go at drawing my own – here's one example, which I provide here in the hope that I'll hear from others who find it either useful or confusing.

REG AD

The structure of packet headers in QUIC

For comparison, RFC 9000 represents this header as follows:

REG AD

Long Header Packet {

Header Form (1) = 1,

Fixed Bit (1) = 1,

Long Packet Type (2), Type-Specific Bits (4),

Version (32),

Destination Connection ID Length (8),

Destination Connection ID (0..160),

Source Connection ID Length (8),

Source Connection ID (0..160), Type-Specific Payload (..),

Maybe I am just old-fashioned in liking to see packet headers when I am learning about a protocol. And I admit that the text version contains more information; e.g. it explains the Flags in detail. Feel free to let us know your preferences. (I guess we know what the "Wall of Text" reviewer thinks already!)

The use of variable-length fields pervades the protocol, in an effort to balance efficiency and future-proofness.

Both TCP and IP have a history of defining 32-bit fields that turned out not to be long enough; QUIC generally avoids that issue by allowing for fields to be very large, such as the 160-bit connection IDs in the packet header above.

At the same time, efficiency has been a concern throughout the design process for QUIC and HTTP/2, since the time to transfer small objects in HTTP is significantly impacted by the amount of header overhead. Hence the use of variable-length encodings that keep the fields small when the extra length isn't needed.

It's probably also fair to say that processing unaligned fields in software is much less of a concern now than it was on the computing hardware of the 1970s, so saving bytes on the wire now takes precedence over 32-bit alignment.

Those long connection IDs replace the way in which TCP connections are identified (source and destination IP addresses and TCP port numbers) with a single identifier that is unique from the perspective of the receiving host. That provides a handy starting point for enabling QUIC connections to survive a change of IP address, e.g., when a host switches from one network to another.

Because QUIC differs from TCP in many ways large and small and spans four RFCs, trying to describe its most important features feels a bit like the parable of the blind man and the elephant. One aspect that grabs my attention is the way the layering with TLS was redesigned in QUIC (previously discussed here ). Here is the picture we use to show this:

REG AD

HTTP over TLS was a traditional layered approach: TCP gives you a reliable byte-stream; TLS provides a secure channel on top of TCP; and HTTP sends application data over that secure channel.

How layering with TLS was redesigned in QUIC

QUIC, by contrast, absorbs the record layer of TLS, with the TLS handshake setting up the secure channel and HTTP then getting to run over QUIC's secure channel directly. This more integrated approach has allowed for several round-trip times of connection establishment to be reduced to a single RTT, with the potential for application data to be sent in the first RTT. As I discussed a few months ago, 0-RTT data is a good example of a complex tradeoff between performance and security. Even without 0-RTT data, the redesigned layers of QUIC and TLS reduce the number of RTTs needed to get a secure channel established, thus providing a real performance benefit to the application.

Finally, A Protocol...