Head-of-Line Blocking
Head-of-line blocking occurs when one stalled item in a shared ordered channel blocks everything queued behind it, appearing at both the HTTP application layer and the TCP byte stream layer.
Definition
Head-of-line blocking is a queueing pathology where a single delayed or lost item prevents delivery of subsequent independent items sharing the same ordered channel. In HTTP/1.1, one slow response blocks the connection; in HTTP/2 over TCP, one lost packet stalls every multiplexed stream because TCP guarantees byte order across the whole connection.
Context and scope
Explains why HTTP/2 can underperform HTTP/1.1 on lossy links, why packet loss on one stream degrades all streams, and why QUIC moved loss recovery into per-stream scope.
Common misconceptions
- HTTP/2 eliminated head-of-line blocking — it fixed the application layer and exposed the TCP layer underneath
- Opening more connections removes head-of-line blocking — it shards the problem across parallel ordered channels
- Only slow servers cause it — random packet loss on any shared stream triggers it just as effectively
Anti-patterns
- Comparing HTTP/2 against six parallel HTTP/1.1 connections on a lossy network and declaring the results protocol-intrinsic
- Multiplexing hundreds of streams over one connection on lossy paths with no packet-loss telemetry
- Treating inter-stream delay as application jitter instead of transport reordering behavior
Related concepts
Related examples
Authoritative source
What it is
Two layers produce it. At the HTTP layer, HTTP/1.1 serves one request per connection at a time, so a slow handler queues everything behind it. At the transport layer, TCP delivers an ordered byte stream: a lost segment holds back all later bytes, even ones belonging to unrelated multiplexed HTTP/2 streams.
How it works
HTTP/2 removes the first layer with interleaved frames but inherits the second: the frames of all streams ride one ordered byte stream. A 1 percent loss rate can stall a majority of streams behind retransmissions. QUIC fixes the transport layer by tracking delivery per stream and only blocking the stream that lost data.
When to care
On clean datacenter networks the effect is small; on mobile and long-haul paths with real loss it dominates. Protocol choice, connection count, and stream count are all levers that trade multiplexing efficiency against stall blast radius.
Pitfalls
Diagnosis requires per-stream timing and retransmit counters, since the symptom is diffuse latency across unrelated requests. Test protocol candidates on synthetic loss, not only on clean links, before concluding which performs better for your users.