HTTP/3 and QUIC: stream-level loss isolation

HTTP/2 fixed the application-layer queue. TCP re-introduced the same queue at the byte level. HTTP/3’s answer: throw away TCP entirely and rebuild reliability on UDP — per stream, not per connection. One lost packet stalls one stream, not fifty.

Why QUIC instead of TCP

TCP guarantees delivery in order. A packet containing bytes 1000–1099 of the stream gets lost. TCP retains incoming bytes 1100–1199 in a buffer, waiting for the retransmitted packet. Only after retransmission does the application receive bytes 1100+. At the HTTP/2 layer, if stream #1 uses bytes 1000–1099 and stream #2 uses bytes 1100–1199, both streams block — even though stream #2 has already arrived.

QUIC (RFC 9000) is built on UDP and reimplements reliability at the stream level:

• QUIC numbers packets, not byte offsets of a unified stream. Each packet carries frames from one or more streams, each frame tagged with its stream ID and offset.
• Loss recovery is per stream. When packet N is lost, only the streams whose data was in packet N retransmit. Streams whose data arrived in other packets keep flowing.
• TLS 1.3 is built into QUIC. The QUIC handshake and TLS handshake happen together — there is no separate TCP handshake then TLS handshake. A cold QUIC connection costs 1 RTT; with session resumption, 0 RTT for application data.

QPACK: header compression without stream coupling

HTTP/3 replaces HPACK with QPACK (RFC 9204). The problem with HPACK on QUIC: HPACK’s dynamic table is ordered, so if a HEADERS frame adding entry index 60 arrives out of order (or is lost), all subsequent HEADERS frames that reference index 60 are blocked. On TCP this is invisible; on QUIC streams it would defeat stream independence.

QPACK’s fix: separate the dynamic table updates into a dedicated control stream. Regular HEADERS frames on request streams reference only the static table or absolute indexes they know have already been acknowledged. Stream B’s HEADERS only blocks on stream B’s own dependencies, not on stream A’s table updates.

The static table in QPACK has 99 pre-indexed entries (vs HPACK’s 61), covering even more common headers and method+status combinations.

Connection migration

QUIC connections are identified by a connection ID — a token chosen at connection setup — not by the 4-tuple (src IP, src port, dst IP, dst port). When a mobile device switches from WiFi to LTE (changing its local IP), the QUIC connection can migrate:

1. Client sends a PATH_CHALLENGE from the new IP.
2. Server validates and responds with PATH_RESPONSE.
3. Connection continues without re-handshaking.

HTTP/2 on TCP would lose the connection on an IP change — the 4-tuple changes, the TCP connection resets, triggering a new handshake (1–2 RTT). For mobile users, QUIC connection migration is a visible latency win on network handovers.

HTTP/3 version negotiation

HTTP/3 cannot be negotiated via ALPN alone — QUIC packets travel on UDP, and many firewalls block UDP/443. Two discovery paths exist:

1. Alt-Svc header: An HTTP/1.1 or HTTP/2 response includes Alt-Svc: h3=":443"; ma=86400. The browser notes this and tries HTTP/3 on the next navigation to that origin (within ma seconds).
2. HTTPS / SVCB DNS records (RFC 9460): the server publishes a DNS record advertising HTTP/3 support, so browsers can try it even on the first connection.

On first navigation, the browser uses TCP-based HTTP/1.1 or /2, learns about /3 via Alt-Svc, then attempts /3 on subsequent navigations. If /3 fails (UDP blocked), the browser falls back silently to /2.

0-RTT resumption

QUIC inherits TLS 1.3’s 0-RTT resumption: if the client has a cached session ticket from a previous connection, the first QUIC packet can carry application data (the HTTP request) alongside the TLS handshake material. This saves one full RTT — meaningful on intercontinental links (100–300 ms).

The same caveat as TLS 1.3 0-RTT applies: 0-RTT data is replayable. A network attacker could replay the initial request. Servers must only honour 0-RTT for idempotent methods (GET, HEAD). For non-safe methods (POST), modern stacks respond 425 Too Early, prompting the client to retry after the handshake completes.