QUIC streams and head-of-line blocking

Your HTTP/2 connection has three requests in flight. One packet is dropped by a congested router. Now all three responses stall — even though two of them have all their bytes sitting in a buffer, ready to deliver. QUIC was built to make this impossible.

Head-of-line blocking in TCP

TCP delivers all bytes in a single ordered stream. If packet N is lost, all bytes after it — in every logical message — wait for packet N to be retransmitted before the receiver’s application can process them.

HTTP/2 multiplexes request-response pairs over one TCP connection. When TCP drops a packet, every HTTP/2 stream stalls — even those whose data arrived intact. This is connection-level head-of-line blocking.

Numbers: At 0.5% random loss and 100 ms RTT, a message blocked in TCP’s ordered delivery waits ~230 ms. QUIC reduces this to ~0.4 ms — a 575× improvement.

QUIC streams are independent

QUIC multiplexes many bidirectional and unidirectional streams over a single connection. Each stream has:

• Its own flow-control window (max-stream-data frame).
• Its own application-level framing (STREAM frames, each stamped with a stream ID and offset).
• Independent loss detection — a STREAM frame retransmit only affects its stream.

When a STREAM frame carrying stream 7’s data is lost, only stream 7’s receiver has to wait for the retransmit; streams 1, 3, and 5 keep flowing with new data.

Stream ID allocation

Stream IDs encode initiator and direction in the two lowest bits:

• Client-initiated bidirectional: 0, 4, 8, 12, … (last 2 bits = 00)
• Server-initiated bidirectional: 1, 5, 9, 13, … (last 2 bits = 01)
• Client-initiated unidirectional: 2, 6, 10, 14, … (last 2 bits = 10)
• Server-initiated unidirectional: 3, 7, 11, 15, … (last 2 bits = 11)

In HTTP/3, each HTTP request-response is one client-initiated bidirectional stream (IDs 0, 4, 8…). This encoding lets both sides allocate IDs independently without coordination.