Head-of-Line Blocking
Definition
Head-of-line blocking happens when the first item in a queue or ordered stream is stuck, so everything behind it must wait, even if those later items are ready. It shows up when responses on a connection must be returned in the order requests were sent: one slow request stalls all the fast ones queued behind it. It is the classic reason naive HTTP pipelining disappoints, and chasing it out of the stack is what drove HTTP/2 and HTTP/3.
Key Takeaways
- One stuck item at the front of an ordered queue blocks all the ready items behind it.
- It is why HTTP/1.1 pipelining failed: a slow response held up every response queued after it.
- HTTP/2 fixes the application layer by multiplexing independent streams over one connection.
- A lost packet still stalls all HTTP/2 streams at the TCP layer; HTTP/3 over QUIC removes that by giving each stream independent delivery.
How It Works
- Requests share one ordered channel and responses must come back in request order.
- If the first request is slow, its response is not ready, so it sits at the head of the line.
- Later responses that finished quickly cannot be delivered until the head clears.
- Removing the ordering constraint (correlation IDs, independent streams) lets ready responses pass.
Where It Is Used
- HTTP/1.1 pipelining shipped disabled in browsers because of head-of-line blocking.
- HTTP/2 multiplexes streams so one slow response no longer blocks the rest at the app layer.
- HTTP/3 over QUIC removes transport-layer head-of-line blocking caused by TCP packet loss.