Head-of-Line Blocking

How It Works

Head-of-line (HOL) blocking is one of the most important performance concepts in networking. It occurs whenever a queue or ordered sequence forces items at the back to wait for items at the front. In HTTP, it has plagued every protocol generation — each solving it at one layer while sometimes introducing it at another.

The Problem, Visualized

Imagine a checkout line at a grocery store. One person is paying with exact change, counting pennies. Everyone behind them waits, even though they could pay instantly. That's HOL blocking.

In networking, the "checkout line" is a TCP connection, and the "pennies" are a slow or lost response.

HTTP/1.1: Request-Level HOL Blocking

HTTP/1.1 uses a request-response model on a single TCP connection. The protocol supports "pipelining" in theory (sending multiple requests without waiting for responses), but in practice almost no browser implements it because a single slow response blocks everything behind it.

Connection 1:  [GET /page]──────[waiting]──────[GET /style.css][GET /app.js]
                              ↑ slow response
                              blocks everything

The 6-connection workaround:

Browsers work around this by opening up to 6 parallel TCP connections per origin. This is pure brute force — each connection has its own queue, so a slow response on connection 1 doesn't block connections 2-6.

Connection 1: [GET /page]──────[waiting]──────
Connection 2: [GET /style.css]────[done]
Connection 3: [GET /app.js]──────[done]
Connection 4: [GET /image1.jpg]──[done]
Connection 5: [GET /image2.jpg]──[done]
Connection 6: [GET /font.woff]───[done]

The cost of this workaround:

• 6 TCP handshakes (6 × 1 RTT)
• 6 TLS handshakes (6 × 1-2 RTTs)
• 6 slow-start ramps (each connection starts with a tiny congestion window)
• Memory overhead on both client and server for 6 connections per origin
• Connection limits at the server — multiply by thousands of concurrent clients

Domain sharding extended this further: serve images from img1.example.com and img2.example.com to get 12 connections to the same physical server. Clever, wasteful, and entirely an artifact of HOL blocking.

HTTP/2: Solved One Layer, Created Another

HTTP/2 introduced stream multiplexing: a single TCP connection carries many concurrent streams, each with its own request-response pair. No more 6-connection workaround — one connection handles everything.

Single TCP Connection:
  Stream 1: [GET /page]────────────────[response]
  Stream 2: [GET /style.css]──[response]
  Stream 3: [GET /app.js]────[response]
  Stream 4: [GET /image.jpg]─────[response]

HTTP-level HOL blocking is solved. But a new problem appears: TCP-level HOL blocking.

TCP guarantees ordered byte delivery. If the TCP segment containing part of Stream 2's data is lost, TCP cannot deliver Stream 3's and Stream 4's data to the application until Stream 2's lost segment is retransmitted and received. TCP doesn't know about HTTP/2 streams — it only sees a single byte stream.

TCP Byte Stream:  [S1 data][S2 data][S3 data][S4 data]
                              ↑ lost packet
                  TCP blocks ALL delivery until retransmitted

This means a lost TCP packet for Stream 2 blocks Streams 1, 3, and 4 — even though their data is sitting in the receive buffer, ready to be consumed.

The Impact: Packet Loss Makes HTTP/2 Worse

Here's where it gets counterintuitive. Under packet loss conditions, HTTP/2 can perform worse than HTTP/1.1:

Packet Loss	HTTP/1.1 (6 conn)	HTTP/2 (1 conn)	HTTP/3 (QUIC)
0%	Baseline	~15% faster	~20% faster
0.5%	~5% slower	~8% slower	~3% slower
1%	~10% slower	~18% slower	~6% slower
2%	~20% slower	~35% slower	~12% slower
5%	~40% slower	~60% slower	~25% slower

Approximate figures from Google's QUIC experiments and Cloudflare's measurements

Why? With 6 HTTP/1.1 connections, a lost packet on connection 1 only blocks that connection's requests. The other 5 connections continue unaffected. With HTTP/2 on 1 connection, every lost packet blocks ALL streams.

This is exactly the scenario on mobile networks, where packet loss rates of 1-5% are common. It's why Google invented QUIC.

HTTP/3 and QUIC: Finally Solved

QUIC (RFC 9000) is a UDP-based transport that provides TCP-like reliability with one critical difference: each stream has independent loss recovery.

QUIC Connection (over UDP):
  Stream 1: [data][lost][retransmit]──[data]
  Stream 2: [data]──────[data]──────[data]    ← not blocked!
  Stream 3: [data]──[data]──────────[data]    ← not blocked!

When Stream 1 loses a packet, QUIC retransmits it for Stream 1 only. Streams 2 and 3 continue receiving data without interruption. This is possible because QUIC, unlike TCP, knows about multiplexed streams at the transport layer.

How QUIC achieves this:

1. Per-stream flow control: Each stream has its own flow control window, separate from the connection-level window
2. Per-stream ordering: Data is delivered to the application in order within each stream, but streams are independent
3. Single packet number space: QUIC packets have monotonically increasing packet numbers (never retransmitted), eliminating ambiguity in loss detection
4. Built-in encryption: TLS 1.3 is integrated into the QUIC handshake, enabling 1-RTT connections (and 0-RTT for resumed connections)

QUIC Packet Structure:
┌─────────────────────────────────────────┐
│ QUIC Header (connection ID, packet num) │
├─────────────────────────────────────────┤
│ Frame: Stream 1 data (offset 0-499)     │
│ Frame: Stream 3 data (offset 200-699)   │
│ Frame: ACK for received packets         │
└─────────────────────────────────────────┘

A single QUIC packet can carry frames from multiple streams. If this packet is lost, QUIC retransmits the individual frames — potentially in a new packet mixed with new data for other streams.

Beyond HTTP: HOL Blocking Everywhere

HOL blocking isn't just an HTTP problem. It appears in many systems:

Switch Buffers

Network switches have output queues per port. If the output port is congested, packets queue up. A burst of traffic to one destination blocks packets to other destinations if they share an output queue. Modern switches use Virtual Output Queues (VOQ) to solve this.

TCP Receive Buffer

Even within a single application, TCP's ordered delivery means a lost segment holds up all subsequent data. This is why database replication over TCP can stall — one lost packet in a continuous stream stops the entire replication pipeline.

Message Queues

A consumer processing messages from a queue encounters HOL blocking when one message takes a long time to process — all subsequent messages wait. Partitioned queues (Kafka) solve this by giving each partition independent ordering.

Measuring HOL Blocking Impact

Browser DevTools

Open Chrome DevTools → Network tab → check the Stalled column. This shows how long each request waited before being sent. High stalled times on HTTP/1.1 are direct evidence of HOL blocking.

Simulating Packet Loss

Use Linux tc (traffic control) to add artificial packet loss and measure the impact:

# Add 2% packet loss on the egress
sudo tc qdisc add dev eth0 root netem loss 2%

# Run HTTP/2 vs HTTP/3 benchmark
h2load -n 1000 -c 1 -m 100 https://example.com/  # HTTP/2
# vs
h2load --npn-list h3 -n 1000 -c 1 -m 100 https://example.com/  # HTTP/3

# Remove the loss simulation
sudo tc qdisc del dev eth0 root

Wireshark Analysis

In a packet capture of an HTTP/2 connection:

1. Filter for TCP retransmissions: tcp.analysis.retransmission
2. Note the timestamp of the retransmission
3. Check the TCP stream for out-of-order delivery notifications
4. Observe the gap between the retransmission and when subsequent data is delivered to the application

Practical Recommendations

For web applications: Enable HTTP/3 if the CDN/server supports it. Cloudflare, Google, and Fastly all support HTTP/3 by default. The fallback to HTTP/2 is automatic.

For mobile-heavy traffic: HTTP/3 gives the biggest improvement on lossy mobile networks. Prioritize QUIC support for mobile clients.

For backend service-to-service: HTTP/2 is usually fine because internal networks have near-zero packet loss. The overhead of QUIC's per-stream management isn't justified when loss is negligible.

For real-time applications: QUIC's independent streams are ideal for multiplexed real-time data (e.g., multiple video feeds, chat channels). Each stream degrades independently under loss.

The evolution from HTTP/1.1 to HTTP/3 is fundamentally the story of eliminating head-of-line blocking at every layer. Understanding this single concept explains why three generations of protocols exist and when each one is the right choice.