HTTP/3 and QUIC

QUIC (RFC 9000, 2021) is a new transport built in userspace on top of UDP. UDP provides nothing but ports and a checksum (UDP: Datagrams and the Contract You Choose), and that is the point: every kernel and middlebox already forwards UDP, so a transport implemented inside the browser or the server library can be shipped and changed with an application update instead of an OS release. QUIC re-implements what TCP does — reliability, ordering, congestion control, flow control — but per stream, and with TLS 1.3 built into the handshake instead of layered on top.

HTTP/3 (RFC 9114) is HTTP semantics mapped onto QUIC streams: each request/response is one bidirectional QUIC stream, and QUIC, not HTTP, owns multiplexing and reliability. Header compression is QPACK rather than HPACK, redesigned so that streams do not have to wait on each other for dynamic-table updates. From the application’s point of view nothing changed: the same GET /users/42, the same status codes, negotiated by the same fetch().

A cold TCP + TLS 1.3 connection costs two round trips before the request: one for SYN/SYN-ACK, one for the TLS exchange. QUIC carries the TLS 1.3 handshake messages in its own CRYPTO frames inside the first packets, so transport and cryptographic setup complete together in one round trip. With a session ticket from a previous connection, a returning client can send 0-RTT data — the request in the very first packet — under the same rules and the same replay caveat as TLS 1.3 early data: only for idempotent requests, and the server may reject it (The TLS Handshake).

Because the handshake is TLS 1.3, QUIC connections are always encrypted, including almost all of the transport header. Packet numbers, ACK frames and stream ids are invisible to the network. That is deliberate: TCP’s plaintext headers let middleboxes make assumptions (rewriting options, dropping unknown flags), which ossified TCP so badly that extensions like multipath or larger initial windows took a decade to deploy. QUIC exposes only what routers need (connection ID and a version) so that the protocol can keep changing.

In QUIC, reliability is tracked per stream, and the unit of loss detection is the QUIC packet, not the stream’s byte position. When a packet carrying a piece of stream 7 is lost, stream 7 waits for the retransmission — but packets carrying streams 3 and 5 are delivered to the application immediately, because nothing about their ordering depends on stream 7. Packet numbers are never reused (a retransmission gets a new number), which removes TCP’s retransmission ambiguity and gives cleaner RTT estimates; ACK frames carry ranges, so a receiver can describe complex loss patterns in one frame.

This is why the accurate claim is that QUIC reduces head-of-line blocking to the stream that actually lost data — not that it eliminates it. Within a single stream, ordering is still enforced and a lost packet still stalls the bytes behind it, exactly as in TCP. A single large response on one stream gains nothing. And shared state can reintroduce cross-stream waits: QPACK’s dynamic table is updated on a separate encoder stream, and a header block that references an entry the decoder has not yet received blocks until it arrives — the design bounds this (encoders can choose not to reference in-flight entries) but does not make it impossible. Congestion control is also per connection: a loss on any stream shrinks the congestion window for all of them (Congestion Control: Protecting the Network, Head-of-Line Blocking).

QUIC also has per-stream and per-connection flow control like HTTP/2, plus a limit on the number of concurrently open streams, all advanced with dedicated frames — the same window-management bugs apply.

A TCP connection is identified by the 4-tuple (source IP, source port, destination IP, destination port); if the client’s IP changes — a phone walking out of Wi-Fi coverage onto LTE, a laptop switching networks, a NAT rebinding a port after an idle period (NAT: Many Private Hosts Behind One Public Address) — every TCP connection dies and HTTP/2 loses all its streams. A QUIC connection is identified by connection IDs chosen by each endpoint and carried in the packet header. When a client’s address changes it keeps sending with the same connection ID from the new address; the server validates the new path with a challenge and continues the connection — streams, keys and congestion state intact (congestion state is reset for the new path). The download continues; no reconnect, no re-handshake, no lost request.

The costs are concrete. CPU: QUIC runs in userspace, so every packet crosses the syscall boundary and is encrypted, acknowledged and paced by application code; without kernel offloads (UDP GSO/GRO, segmentation offload) operators have measured roughly two to three times the CPU per byte of TCP + kTLS, and even with them QUIC generally costs more. Networks: some corporate and institutional firewalls block or rate-limit UDP/443, some NATs expire UDP mappings after 30 s so idle connections need keep-alive PINGs, and a few middleboxes mangle UDP packets over ~1200 bytes — which is why QUIC’s initial packets are padded to exactly 1200 and path MTU discovery is per connection.

Discovery and fallback handle the hostile cases. A browser’s first connection to a site is TCP; the HTTP/2 response carries Alt-Svc: h3=":443"; ma=86400, and subsequent connections try QUIC, often racing it against TCP and falling back if the UDP path fails. The HTTPS DNS record can advertise h3 up front (DNS Record Types and What They Are For). Servers that terminate HTTP/3 at a CDN or load balancer usually speak HTTP/1.1 or /2 to the origin, so an application may never see a QUIC packet and still benefit from it on the last mile.