Head-of-line blocking, QUIC and HTTP/3

Why it matters

"Why does HTTP/3 exist?" tests whether you understand layering rather than version numbers. The answer also shows where the network/application boundary sits and what it costs to move transport logic out of the kernel.

Core ideas

Blocking at each layer. In HTTP/1.1 a connection carries one response at a time, so a slow response delays the next one; pipelining did not solve this because responses must still return in request order. HTTP/2 multiplexes streams over one TCP connection, fixing the HTTP-level problem but exposing TCP's: TCP delivers a single ordered byte stream, so a lost segment holds back data for every stream until it is retransmitted, including data that has already arrived. The pattern recurs elsewhere: one slow item at the head of a shared queue delays everything behind it.

What QUIC changes. QUIC runs over UDP and provides many streams with ordering only within each stream, so a loss on one stream does not block the others. Packet numbers are never reused, so a retransmission travels in a new packet and RTT samples are unambiguous. TLS 1.3 is built in: a new connection usually needs one round trip before application data, and resumption allows 0-RTT with the same replay caveats as TLS. Nearly all header fields are encrypted, which limits middlebox interference and keeps the protocol evolvable. Connections are identified by connection IDs rather than the address four-tuple, so a client can migrate between networks; a load balancer that routes only by addresses breaks migration, so deployments either route by connection ID or tell clients not to migrate.

HTTP/3. HTTP semantics mapped onto QUIC streams, with QPACK header compression designed to avoid reintroducing blocking across streams.

The boundary moves. With TCP, the kernel owns reliability and congestion control and the application sees one byte stream. A QUIC stack usually ships as a library inside the application, so it can evolve with each release and expose stream-level events, but the application now owns pacing, loss recovery bugs and their CPU cost.

Costs. User-space stacks spend more CPU per byte than mature kernel TCP with hardware offloads, some networks block or throttle UDP (so clients keep a TCP fallback), and operators lose visibility that plaintext TCP headers used to give.

Common misconceptions

• "QUIC eliminates head-of-line blocking." It removes blocking across streams caused by transport loss; data within one stream is still delivered in order.
• "QUIC is unreliable because it uses UDP." UDP is only the substrate; QUIC implements reliability, flow control and congestion control.
• "HTTP/3 is always faster." Gains concentrate on lossy, high-latency or mobile paths and on connection setup; on clean networks the difference can be small and CPU cost higher.
• "QUIC does not need congestion control." It needs it just as TCP does, and implementations use the same families (Reno-like, CUBIC, BBR).

How to approach it

Explain blocking layer by layer with one concrete lost packet, then show what each protocol change fixes. For depth, read the stream and migration sections of RFC 9000 and the design discussion of the QUIC SIGCOMM paper, keeping its measurements tied to that deployment.