Understanding HTTP Head‑of‑Line Blocking and How HTTP/2 and QUIC Address It

Recently, more websites support HTTP/2, which brings several improvements: TCP multiplexing to reduce latency, allowing out‑of‑order request‑response on a single TCP connection to address head‑of‑line blocking, and mandatory TLS for better security.

However, does HTTP/2 truly solve head‑of‑line blocking? In HTTP/1.1, pipelining sends multiple requests at once, but responses must be returned in the same order; if the first request is blocked, subsequent ones wait, as illustrated in the first diagram.

HTTP/2 solves this at the request level by framing: multiple requests share one TCP connection, each request‑response is split into frames, so a blocked request does not stall others. Yet this only solves request‑level blocking; the transport layer (TCP) can still suffer from packet loss, causing retransmission delays that affect all streams.

When a packet is lost, TCP’s congestion control and retransmission mechanisms introduce blocking that cannot be fully avoided, only mitigated.

To eliminate transport‑level head‑of‑line blocking, a new transport protocol is needed. Google’s QUIC implements a reliable, multiplexed transport over UDP, which lacks the inherent ordering constraints of TCP. QUIC thus removes transport‑level blocking, though its implementation details are complex.

In summary:

HTTP/2 over TCP resolves head‑of‑line blocking at the HTTP request level.

HTTP/2 over QUIC (or QUIC alone) resolves the transport‑level blocking, providing a more complete solution.

Source: https://liudanking.com/arch/what-is-head-of-line-blocking-http2-quic/