Learning objective. Describe QUIC's design as a single coalesced transport-plus- security protocol over UDP, and name the specific ways it departs from the TCP-plus-TLS model. Later chapters can then treat those departures (streams, unified handshake, encrypted transport, connection IDs) as shared background.
One protocol where there used to be three #
In the classic stack, three layers evolved separately: TCP provided a reliable ordered byte stream, TLS added security on top of it, and HTTP/2 multiplexed requests above that. QUIC collapses the first two into one protocol that runs over UDP, and HTTP/3 becomes a thin mapping above it (see §1.3). Running over UDP means QUIC lives in user space, shipped as part of the application or a library rather than the OS kernel. That is why it can evolve on a release cadence instead of waiting for operating systems and middleboxes to update.
The design rests on a handful of decisions that recur throughout the book:
- Streams are transport primitives. Independent, ordered, flow-controlled byte streams are provided by the transport itself, not layered on top ([RFC 9000 §2]).
- The handshake is unified. QUIC carries the TLS 1.3 handshake in CRYPTO frames and derives its packet-protection keys from it, so transport and security establish together in one round trip, or zero on resumption ([RFC 9001 §4]).
- The transport is encrypted. Almost everything past the first header byte (including the packet number) is protected, so on-path devices cannot read or depend on transport internals ([RFC 9001 §5.4]). This is what keeps QUIC from ossifying.
- Connections are named, not addressed. A connection is identified by a Connection ID rather than the UDP four-tuple, which is what makes migration possible ([RFC 9000 §5.1]).
Packet numbers are not sequence numbers #
The most instructive difference from TCP is how QUIC tracks delivery. TCP has one number line (the byte sequence number) that does double duty: it orders bytes and identifies what to acknowledge and retransmit. That overloading creates retransmission ambiguity: when an ACK arrives for a sequence number that was sent twice (original and retransmission), the sender cannot tell which transmission it acknowledges, muddying its RTT estimate.
QUIC separates the two jobs. Stream offsets describe where bytes belong in a stream; packet numbers describe which packet carried them. Packet numbers are strictly monotonic and never reused — if a packet is lost, the frames it carried are re-sent in a brand-new packet with a fresh, higher packet number ([RFC 9000 §13.2.1]). An acknowledgment therefore names exactly one transmission, so RTT samples are unambiguous and loss detection is cleaner. Packet numbers also live in three independent number spaces: Initial, Handshake, and Application Data ([RFC 9000 §12.3]), so handshake and application acknowledgments never interfere. Chapter 3 builds loss recovery directly on these properties.
Acknowledgments differ too. Instead of TCP's single cumulative ACK (plus optional SACK), QUIC's ACK frame carries explicit ranges of received packet numbers and an ACK Delay measured by the receiver, letting the sender compensate for delayed acknowledgments when estimating RTT ([RFC 9000 §19.3]). The exact encoding is covered in §3.1.
What stays familiar, what changes #
QUIC keeps the parts of TCP that work: a reliable ordered abstraction (per stream), congestion control, and flow control. It changes the parts that hurt on modern paths:
| Concern | TCP + TLS | QUIC |
|---|---|---|
| Setup cost | TCP then TLS, serialized | one combined handshake; 0-RTT on resume |
| Multiplexing | above the transport (HTTP/2) | in the transport (streams) |
| Transport metadata | in the clear | encrypted, incl. packet number |
| Connection identity | 4-tuple | Connection ID |
| Delivery tracking | one sequence-number line | stream offsets + monotonic packet numbers |
| Deploy / evolve | kernel + middleboxes | user space, per app |
"Runs over UDP" describes the wire, not the intent. QUIC is a full reliable transport; UDP is simply the substrate that lets it be deployed in user space and traverse existing NATs. Applications still get reliability, ordering (per stream), congestion control, and flow control: the guarantees TCP offers, reorganized to fit modern traffic.
editorial Encrypting and authenticating every packet moves cost from the network into the endpoints' CPUs. High-throughput QUIC servers lean on kernel offloads — UDP generic segmentation offload (GSO), receive-side batching (GRO), and increasingly hardware crypto — to close the gap with TCP, which enjoys decades of NIC offload. Expect QUIC to be more CPU-sensitive per byte than TCP unless these paths are enabled; measure before assuming parity. See §11.2 for what to measure.
Takeaways #
QUIC is best understood not as "TCP over UDP with TLS bolted on," but as a redesign that puts multiplexing and security inside an encrypted transport, names connections independently of their address, and cleanly separates delivery tracking from ordering. The next section, §1.3, shows how HTTP/3 spends these capabilities, and Chapter 2 opens up the handshake that Figure 1.2-1 compressed into three arrows.