This chapter matters because it shows a change of foundation under web traffic: the transport moves from TCP to UDP, the TLS 1.3 handshake is built into it, and streams stop blocking each other when a packet is lost.
In practice, it helps you deploy HTTP/3 alongside HTTP/2 deliberately through Alt-Svc and fallback, account for UDP blocking and observability, and tell where the gain from removing HoL blocking is real and where server-side cost cancels it out.
In interviews and architecture discussions, it gives you a structured language to explain handshake cost, connection migration by connection ID, and stream behavior under loss through actual QUIC mechanisms rather than vague claims about a fast new protocol.
Practical value of this chapter
Latency budget
QUIC's 1-RTT versus TCP+TLS's 2-RTT, plus 0-RTT on resumption — concrete levers for the first request over long paths.
Streams without HoL blocking
A lost packet stalls only its own stream, not the whole connection — a real win when multiplexing many resources.
Connection migration
A connection ID instead of the 4-tuple keeps the session alive across Wi-Fi↔LTE — important for mobile clients.
Deliberate rollout
Alt-Svc and HTTP/2 fallback, UDP blocking, and server cost — what to account for so the gain is not cancelled out.
RFC
RFC 9000 (QUIC)
The QUIC specification: a UDP-based transport with streams, low-latency connection setup, and path migration.
QUIC and HTTP/3 are not just another protocol version — they swap the foundation under all web traffic. The transport moves from TCP to UDP, the TLS 1.3 handshake is built into it, and streams stop blocking each other when a packet is lost. First-request latency, behavior on mobile networks, and the fate of a connection across a network change all depend on this shift.
This chapter builds on three neighboring protocol chapters and shows exactly what QUIC and HTTP/3 change on top of them. TCP protocol gives a reliable byte stream, TLS protocol adds the handshake and encryption on top of it, and HTTP protocol covers the application semantics and the HTTP/1.1 → HTTP/2 evolution.
The classic stack assembles exactly those three layers separately: first the TCP handshake, then the TLS handshake, and only then HTTP/2 multiplexes streams inside one connection. QUIC and HTTP/3 change precisely that: a transport over UDP with integrated TLS 1.3, streams without head-of-line blocking, and connection migration across a network change.
For system design this matters because QUIC sits on the path of a growing share of external traffic. Understanding its round-trips, how streams behave under loss, and the mechanics of migration helps you explain latency growth, deploy HTTP/3 alongside HTTP/2 deliberately, and see where QUIC's gain is real and where the network is stable enough that the difference barely registers.
Source
HTTP/3: the past, present, and future (Cloudflare)
Cloudflare's walkthrough of TCP-level HoL blocking, handshakes, and QUIC's advantages on unstable networks.
The problem: handshake cost and HoL blocking
The classic stack is robust and proven, but it pays two clear costs: extra round-trips on connection setup and stream blocking when a single segment is lost. Both become visible exactly where the network is distant or unstable.
Round-trips to first byte
The classic stack stacks handshakes: one RTT for TCP (SYN/SYN-ACK) plus another for TLS 1.3. A fresh connection to a distant server pays both round-trips before the first request even leaves.
Separate layers
TCP and TLS were designed independently, so their handshakes do not combine: the transport opens a stream first, and only then does security run on top of it.
HoL blocking at the transport
HTTP/2 multiplexes streams in one connection, but TCP delivers bytes strictly in order. Losing a single segment delays every logical stream, even those unrelated to the lost data.
Binding to the 4-tuple
A TCP connection is defined by the IP:port pair on both sides. Changing networks changes the client address and breaks the connection, forcing a new one and paying for handshakes again.
HTTP/2 removed head-of-line blocking at the application layer through multiplexing, but left it at the transport: a single ordered TCP stream still holds every logical stream hostage to one loss.
The classic stack vs. QUIC + HTTP/3
The key difference shows up in the structure of the stack itself: where there used to be three independent layers with their own handshakes, QUIC keeps a single transport over UDP that embeds both streams and TLS 1.3.
TCP + TLS 1.3 + HTTP/2
classic stackHTTP/2 — framed multiplexing
Multiple streams in one connection, header compression with HPACK.
TLS 1.3 — separate record layer
Its own handshake on top of an already established TCP connection.
TCP — reliable byte stream
One ordered stream: losing a segment stalls every stream at once.
IP
Packet delivery between hosts.
QUIC + HTTP/3
next-generation transportHTTP/3 — HTTP mapped onto QUIC streams
The same HTTP semantics, QPACK header compression without HoL blocking.
QUIC — transport + integrated TLS 1.3
Streams, reliability, and encryption in one protocol; a 1-RTT handshake.
UDP — datagrams
A minimal kernel transport; all connection logic moves into QUIC.
IP
Packet delivery between hosts.
On the left, three independent layers stack their handshakes and inherit TCP's single byte order. On the right, QUIC folds transport and TLS 1.3 into one protocol over UDP, and streams become independent in delivery.
RFC
RFC 9000 (QUIC)
Flow-controlled streams, per-stream retransmission, and packet encryption as the core of the QUIC transport.
QUIC over UDP: streams without HoL blocking
QUIC (RFC 9000) is a user-space transport over UDP. The OS kernel only delivers datagrams, while all the logic of connections, multiplexing, and reliability lives in the QUIC library and works at the level of individual streams.
- QUIC is a user-space transport over UDP: connection, stream, and retransmission logic lives in a library rather than in the OS kernel.
- Inside one connection, independent streams run in parallel. Reliability and ordering are guaranteed per stream, not for the whole connection.
- A lost packet only delays the streams whose data it carried. The other streams keep being delivered without blocking — that is the absence of HoL blocking at the transport.
- In every QUIC packet the payload is encrypted and most header fields are protected (header protection); mainly the Connection ID stays visible for routing, so middleboxes see far less of the connection's internal structure than they do with TCP.
RFC
RFC 9001 (Using TLS to Secure QUIC)
How TLS 1.3 is embedded in QUIC: the handshake rides in packets and the record layer is replaced by packet protection.
The handshake: integrated TLS 1.3, 1-RTT, and 0-RTT
In the classic stack the TCP and TLS handshakes run one after another. QUIC combines them: the transport and cryptographic handshake happen together, so a new connection fits in one RTT and resumption fits in zero.
Integrated TLS 1.3
QUIC does not carry TLS records on top of itself — it pulls the TLS 1.3 handshake inside the transport (RFC 9001). Handshake messages ride directly in QUIC packets, and the record layer is replaced by per-packet protection.
1-RTT for a new connection
Transport parameters and key exchange are combined: the client sends ClientHello in the first flight, and application data can flow after a single RTT. There is no separate TCP handshake before it.
0-RTT on resumption
If the peers have talked before, the client uses a pre-shared key (PSK) and sends the first data immediately, without waiting for the server's reply. The first request leaves in zero round-trips.
0-RTT replay risk
Early 0-RTT data is not replay-protected and provides no forward secrecy. Only idempotent operations are safe over it — never state-changing requests.
Careful with 0-RTT. Early data can be replayed and provides no forward secrecy, so only idempotent requests are safe over 0-RTT — the same caveat that applies to TLS session resumption.
Related chapter
UDP protocol
The datagram transport under QUIC: why UDP became the foundation for a user-space transport.
Connection migration: connection ID instead of IP:port
A TCP connection is rigidly bound to a 4-tuple of addresses and ports, so a network change breaks it. QUIC relies on a dedicated connection ID, and that lets the connection survive a move between networks.
Connection ID instead of the 4-tuple
A QUIC connection is identified by a dedicated connection ID in the packet header, not by the IP:port pair. The client address can change, yet the server still recognizes the connection by its ID.
Surviving a network change
A Wi-Fi↔LTE switch changes the client IP. A TCP connection would break at that moment, while QUIC continues the existing connection with no new handshake and no loss of open streams.
Validating the new path
On an address change the server runs path validation to confirm the client is actually reachable there — protection against address spoofing and amplification.
Privacy through ID rotation
Peers use several connection IDs and rotate them so that an on-path observer cannot link a client's activity by ID across a network change.
In practice this is most visible in mobile scenarios: a Wi-Fi↔LTE switch on a phone does not drop the download and needs no new handshake, because the connection is recognized by its ID rather than its address.
RFC
RFC 9114 (HTTP/3)
Mapping HTTP semantics onto the QUIC transport with an internal framing layer similar to HTTP/2.
HTTP/3: mapping HTTP onto QUIC and QPACK
HTTP/3 (RFC 9114) keeps the same application semantics as earlier versions but carries it over QUIC streams. The key change in the details is header compression: HPACK is replaced by QPACK, designed for streams without a shared order.
Mapping HTTP onto QUIC
HTTP/3 keeps the same HTTP semantics (methods, status codes, headers from RFC 9110) but places each request-response on its own QUIC stream and uses its own binary framing, similar to HTTP/2.
QPACK instead of HPACK
HTTP/2's HPACK relies on strict ordering and is therefore incompatible with streams that share no global order. QPACK (RFC 9204) compresses headers so that decoding does not stall when packets are reordered.
Dynamic table under control
QPACK splits dictionary updates and references to them across different streams, letting the encoder choose its own trade-off between compression ratio and the risk of header blocking.
One stream per request
Because each HTTP request rides its own QUIC stream, a lost packet in one request does not stall the others — HoL blocking is eliminated at the application layer too.
HPACK in HTTP/2 relied on strict delivery order and therefore moved head-of-line blocking into header compression. QPACK (RFC 9204) breaks that link, allowing headers to be decoded even when packets are reordered.
Congestion, loss, and why UDP
QUIC does not abolish congestion control — it moves it into user space and makes it more precise. And the choice of UDP as the foundation is not about datagram performance, but about being able to deploy a new transport at all in today's internet.
Congestion control in user space
Congestion control and retransmission live in a library, not the kernel. Algorithms (CUBIC- or BBR-style) ship with the application — no waiting on the OS release cycle.
Cleaner loss signals
Every QUIC packet has a monotonically increasing number, and retransmitted data rides under a new number. This removes TCP's retransmission ambiguity and measures RTT and loss more precisely.
Why UDP, not a “new TCP”
Deploying a brand-new transport protocol next to TCP is not feasible: middleboxes pass essentially only TCP and UDP. QUIC builds on UDP precisely because that is the only way to deploy a user-space transport across the real internet.
Middlebox ossification
Firewalls and NATs ossified for decades around TCP's visible fields, blocking protocol evolution. QUIC encrypts almost all of its headers so the network's middle cannot depend on its internal structure and cannot stand in the way of future change.
Operations: deployment, fallback, and observability
Alt-Svc and HTTP/2 fallback
The browser first connects over HTTP/2 on TLS, and the server advertises HTTP/3 with an Alt-Svc header. If QUIC does not get through, the client transparently stays on HTTP/2 — HTTP/3 is almost always deployed as an addition, not a replacement.
UDP blocking
Some corporate networks throttle or drop UDP. A TCP fallback is therefore mandatory: without it, clients behind such networks simply cannot connect, and the fallback has to trigger quickly.
Server-side cost
Crypto and connection handling move into user space — usually pricier in CPU than hardware-accelerated TCP+TLS. Under high load that gap has to be budgeted into capacity upfront, not discovered in production.
Observability
Familiar tools rely on visible TCP fields, but QUIC encrypts them. Diagnosis uses qlog/qvis and server-side metrics, while passive on-the-wire analysis reveals almost nothing.
Why this matters for system design
- A combined handshake removes a full round-trip at startup (2-RTT TCP+TLS → 1-RTT QUIC) and noticeably speeds up the first request over long paths.
- Independent streams remove HoL blocking at the transport, so loss hurts unstable and mobile networks less.
- Connection migration by connection ID holds the session across a network change with no new handshake.
- QUIC encrypts headers and moves logic into user space — changing both server-side cost and the approach to observability.
Trade-offs and common mistakes
Assuming HTTP/3 is always faster than HTTP/2: on a stable wired network with low loss the gain from removing HoL blocking is small, and the extra CPU overhead can cancel it out.
Deploying HTTP/3 without a working HTTP/2 fallback: clients behind UDP blocking or a broken path are left with no access.
Sending non-idempotent requests over 0-RTT: early data can be replayed, which duplicates state-changing operations.
Expecting connection migration to hide every network change: it saves the connection but does not skip path validation and does not make recovery from long outages instant.
Porting TCP monitoring as-is: without qlog and server-side metrics, QUIC stays a black box because its headers are encrypted.
References
Source map: RFC 9000 anchors the QUIC transport, RFC 9001 the TLS 1.3 integration, RFC 9114 the HTTP/3 mapping, and RFC 9204 QPACK. Practical claims about latency gains and observability depend on the network, middleboxes, the QUIC implementation, and the quality of the HTTP/2 fallback — treat them as a signal for a decision, not a speedup guarantee for any product.
- RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport — the core QUIC transport: streams, low-latency connection setup, path migration, and connection IDs.
- RFC 9001 — Using TLS to Secure QUIC — how TLS 1.3 is embedded in QUIC: handshake over the transport, 1-RTT and 0-RTT, replacing the record layer.
- RFC 9114 — HTTP/3 — mapping HTTP semantics onto QUIC with an internal framing layer similar to HTTP/2.
- RFC 9204 — QPACK: Field Compression for HTTP/3 — header compression for HTTP/3 designed for streams without a shared order, reducing HoL blocking.
- Cloudflare — HTTP/3: the past, the present, and the future — a practical walkthrough of TCP-level HoL blocking, handshakes, and QUIC's advantages on unstable networks.
Related chapters
- TCP protocol - covers the reliable byte stream and handshake whose cost and transport-level HoL blocking QUIC is built to remove.
- TLS protocol - breaks down the TLS 1.3 handshake and 1-RTT/0-RTT that QUIC pulls inside the transport per RFC 9001.
- HTTP protocol - shows the HTTP semantics and the HTTP/1.1 → HTTP/2 evolution that HTTP/3 maps onto QUIC.
- UDP protocol - explains the datagram transport QUIC runs on and why it remains the only way to deploy a new transport across the internet.