Head-of-Line Blocking: HTTP/1.1 vs HTTP/2 vs HTTP/3

Head-of-Line Blocking Across HTTP Versions

Head-of-line (HOL) blocking is one of the most important performance problems in web protocols. It occurs when a single slow or lost piece of data blocks all other data behind it in a queue.

HTTP/1.1: Double HOL Blocking

HTTP/1.1 suffers from HOL blocking at two levels:

HTTP-level HOL blocking: With persistent connections, only one request can be in-flight at a time per connection. If the server is slow to respond to one request, all subsequent requests on that connection must wait.

TCP-level HOL blocking: Even with HTTP pipelining (rarely used in practice), TCP delivers all bytes in strict order. A lost packet at the TCP level stalls all data until retransmitted.

Browsers work around this by opening 6-8 parallel TCP connections per origin, but this wastes resources and does not fully solve the problem.

HTTP/2: Half Solved

HTTP/2 introduced multiplexing, which completely eliminates HTTP-level HOL blocking. Multiple requests and responses are interleaved as frames on a single connection.

However, HTTP/2 still runs on TCP. If a single TCP packet is lost, all streams are blocked until that packet is retransmitted — even streams whose data was not in the lost packet. On networks with 1-2% packet loss, this TCP-level HOL blocking can negate much of HTTP/2's multiplexing benefit.

HTTP/3: Fully Eliminated

HTTP/3 runs on QUIC, where each stream has independent delivery. A lost packet on Stream 1 only blocks Stream 1. Streams 2, 3, and 4 continue receiving data immediately. This is the first HTTP version to completely solve HOL blocking at every layer.

Packet loss scenario (Stream A loses a packet):

HTTP/2 over TCP:  Stream A: [blocked]  Stream B: [blocked]  Stream C: [blocked]
HTTP/3 over QUIC: Stream A: [blocked]  Stream B: [flowing]  Stream C: [flowing]