> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # HTTP/2 Fixed Head of Line Blocking, Then Reintroduced It - URL: https://debugly.dev/http2-head-of-line-blocking-vs-http3/ - Published: 2026-09-11T03:30:00.000Z - Updated: 2026-10-17T05:58:03.000Z - Description: HTTP/2 multiplexed many streams over one connection to escape head of line blocking, then moved the blocking one layer down into TCP, where a single lost… - Author: Rohit Bhadani - Tags: Deep Dive, Networking, Performance HTTP/2 was sold as the fix for head of line blocking. In HTTP/1.1, requests on a connection are strictly ordered, so one slow response delays everything behind it. HTTP/2 multiplexes independent streams over a single connection, so a slow response no longer blocks its neighbours at the HTTP layer. I have lost on-call weeks to this exact shape of slow burn, so the order below is the order I fix it in. That is all true. What is also true is that the blocking did not disappear. It moved down a layer, into TCP, where it is harder to see and in some ways worse. And HTTP/3 exists primarily to move it again. This is the story of a performance fix that relocated its own problem, told so you can reason about which protocol actually helps your workload. ## The HTTP/1.1 problem, briefly On one connection, responses come back in request order. If request one hits a slow query, requests two through ten wait, even though their data is ready. The fix people used was more connections, six per origin in browsers, which works but multiplies handshakes and congestion windows. HTTP/2's answer: one connection, many streams, interleaved frames. At the HTTP layer, ordering is per stream, not per connection. A slow stream no longer delays its siblings. This part works exactly as advertised. ## Where the blocking moved All those streams share one TCP connection, and TCP guarantees in order, lossless delivery of a byte stream. It does not know about streams. When a single TCP segment is lost, the receiver cannot deliver any bytes after the gap, so it withholds everything until the loss is retransmitted. From the streams' point of view, one lost packet now stalls all of them simultaneously. In HTTP/1.1 with six connections, one loss stalled one sixth of your parallelism. In HTTP/2 with one connection and sixty streams, one loss stalls all sixty. The blocking was not removed. It was consolidated. This is head of line blocking at the transport layer, and it is worst exactly where HTTP/2 was meant to help, on lossy networks, because more multiplexing means more streams share each loss. ## Seeing it The signature is a connection that shows high throughput in the aggregate but long tails on individual streams during loss. In a capture you see one retransmission followed by a pause across many streams, then a burst when the loss is recovered. The pause is TCP waiting, not your server thinking. You can observe it from the client with a throttled, lossy profile. Enable a couple of percent packet loss and compare HTTP/2 versus HTTP/1.1 versus HTTP/3 on the same page. HTTP/2 often degrades more than the older protocol under loss, which is the consolidated blocking showing up. ## What HTTP/3 changes HTTP/3 runs over QUIC, which is a transport built on UDP that gives each stream its own ordering guarantee. A lost packet affects only the stream it belongs to, because QUIC delivers streams independently. The head of line blocking that TCP imposed across streams is gone. QUIC also fixes connection migration, so a phone switching from WiFi to cellular does not tear down the session, and it integrates the TLS handshake, cutting setup round trips. But those are secondary to the core property for our purposes: independent stream delivery. The trade is that QUIC is UDP, which some networks and middleboxes treat poorly, and it moves congestion control and loss recovery into userspace, which is powerful but means behaviour varies by implementation. ## Which one helps your workload The honest partition is by loss and by object count. **Low loss, many small objects.** HTTP/2 shines. Multiplexing removes the HTTP layer ordering and the network rarely loses, so the consolidated blocking rarely bites. This is most datacentre and good WiFi traffic. **Lossy or mobile networks.** HTTP/3 helps, because independent streams stop one loss from stalling everything. If your users are on real mobile networks, HTTP/3 is the meaningful upgrade. **Few large streams.** The differences shrink. A single video stream does not benefit much from multiplexing, and loss recovery matters more than stream independence. ## The practical posture You usually do not choose per request. You choose what to offer at the edge and what your clients prefer. The sensible configuration is to serve all three and let negotiation pick, because the diversity of client networks is exactly the reason the protocols coexist. More important than the protocol choice is not misattributing the latency. A long tail under HTTP/2 on a lossy path is not your server. Before tuning the application, check the loss rate and the protocol in use, which is the partition the curl timing template gives you in [the curl flag that tells you which part was slow](https://debugly.dev/curl-timing-template-diagnose-latency/). And remember the keep alive interaction: because everything shares one connection, that connection's health matters more than ever, and idle timeouts on it affect all streams, which is the lesson of [connection reset at exactly sixty seconds](https://debugly.dev/econnreset-idle-timeout-keepalive-mismatch/). ## If it happens again Multiplexing removes ordering at the layer that knows about your streams, but any layer below that only sees bytes and will impose its own ordering. HTTP/2 fixed the HTTP layer and inherited TCP's. HTTP/3 fixes the transport by giving streams independence. Choose by your loss profile, and when a page is slow, ask which layer is holding the line before you blame the code. There is a meta lesson here that applies beyond protocols. Every fix that removes ordering at one layer should be checked for the ordering it inherits from the layer below, because the constraint rarely disappears, it relocates. The same relocation happens when you move caching from the application to a CDN, or retries from the client to a mesh. The blocking, like the cost, does not vanish. It moves somewhere with a different name and a different on call rotation. --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev)