How QUIC and HTTP/3 work — the protocol that quietly replaced much of the web's transport layer

For nearly four decades, almost everything on the internet traveled over TCP — a reliable, byte-oriented stream that guarantees packets arrive in order, with exactly no losses and no duplicates. HTTP was layered on top, and when encryption became mandatory, TLS became a separate wrapper around the whole stack. QUIC, standardized as RFC 9000 and HTTP/3 in RFC 9114, collapses that layered stack into a single protocol: an encrypted, stream-oriented transport built on top of UDP. It is not a replacement for HTTP — it is a replacement for everything under HTTP.

The motivation is a specific failure mode of TCP that TLS and HTTP never got to fix: head-of-line blocking. TCP presents one ordered byte stream. If one packet is lost, every later packet — even ones for unrelated requests — must wait for the retried segment before the receiver can hand anything to the application. On a lossy cellular downlink, one dropped packet stalls every open request on that connection. Layered solutions helped but could not fully escape the problem, because every layer above inherited TCP's single-stream, all-or-nothing ordering discipline.

The stack, collapsed

QUIC is a deliberately single-layer protocol. It bundles what previously took three protocol layers into one: reliable transport (an ACK-based retransmission mechanism similar in result to TCP's), security (TLS 1.3 cryptography applied to every packet, including the handshake itself), and streams (multiple interleaved, individually ordered byte streams over the one connection). Because all of these live inside one protocol, the sender and receiver have a single set of state, a single packet format, and a single congestion control feedback loop. There is no TLS record layered onto a TCP segment layered onto an IP datagram — there is a QUIC packet, and everything else is a field inside it.

• Streams instead of one byte stream — a QUIC connection carries many independently ordered streams; a loss on one stream with data still in flight no longer blocks delivery of already-arrived data on other streams. This is the structural fix for HTTP head-of-line blocking
• TLS 1.3 encryption from packet one — the original TLS handshake is folded into the transport; data can even be sent inside the first flight (0-RTT). There is no unencrypted preamble, which removes an entire class of middlebox interference and snoopable pre-handshake traffic
• Connection migration — a TCP connection is identified by a four-tuple (addresses plus ports); change the Wi-Fi-to-cellular handoff and the connection is destroyed. QUIC identifies connections by a key-encrypted connection ID, so a device can move networks and the session simply continues
• Modern congestion control — the loss and congestion algorithms ride in the transport itself, not bolted onto a shared TCP socket, making it practical for each deployment to run current algorithms (CUBIC, BBR and successors) uniformly
• Header protection — QUIC applies per-packet cryptographic protection to its own header fields, throttling a middlebox's ability to inspect traffic patterns even without inspecting payloads

Building all of it on UDP was load-bearing. UDP is a bare service: send and receive datagrams, no ordering guarantee, no state in the network. That freedom is what lets QUIC evolve. TCP changes are painful because every change has to pass through a stack of interoperability requirements with two decades of middleboxes, NATs, and firewall code that makes fixed assumptions about it. A new UDP-based protocol is invisible to most of that infrastructure — UDP packets pass through — and because the payload is encrypted end-to-end, the middlebox cannot even reliably identify it. Protocols riding UDP have historically (and, on some networks, still do) suffered deprioritization or blocking; QUIC's answer is header protection plus an extension that lets a QUIC client masquerade as video traffic (RFC 9204) when it detects a hostile network.

What this means for you

One more design point deserves emphasis: QUIC's security was designed in from the start, rather than wrapped on later. That single decision cascades through everything else. The handshake is TLS; the loss recovery rides on the same keys; stream multiplexing is inside the encryption boundary; connection identity survives network changes because the connection ID is bound to the session keys. The layered alternative — "just put TLS around TCP and do multiplexing on top" — can get most of the way there, but each layer boundary remains a place where assumptions disagree and middleboxes can still reach in. QUIC's bet was that a smaller, single-layer, encrypted-by-default protocol would age better than a stack of patched-together layers, and a decade of production traffic at major web properties has vindicated the bet.

• Head-of-line blocking is a structural property — it lives in single-stream ordering, not in HTTP, so the fix has to come from the transport layer, which is exactly what QUIC's multiplexed streams provide
• One encrypted protocol ages better than a transparent wrapper — because every field is under the same keys, there is no unencrypted seam for middleboxes to probe, and the protocol can evolve behind an opaque payload
• Connection identity surviving network changes is a transport feature — key-bound connection IDs make the Wi-Fi-to-cellular handoff transparent to the session, something the TCP four-tuple cannot do

Sources: HTTP Developer — HTTP/3; RFC 9000 — QUIC: A UDP-Based Multiplexed Transport; RFC 9204 — Avoiding Blocking of QUIC (Packing QUIC Packets Inside UDP Fragments).

Corrections: Report an error at corrections@wireshaman.com.