On what kind of network can moving from HTTP/1.1 to HTTP/2 make performance worse rather than better, and what is the underlying reason?
answer
- h2 fixed HTTP-layer HOL, not TCP's
- one lost segment stalls every multiplexed stream
- h1.1's 6 connections = accidental fault isolation
- regression visible above roughly 1-2% loss
- one congestion window vs six; QUIC per-stream ordering fixes it
basics
~20 sLossy networks. HTTP/2 puts every request on one TCP connection, and TCP delivers bytes strictly in order, so one lost segment stalls all multiplexed streams. HTTP/1.1's six connections isolate the damage to one sixth of the traffic. HTTP/3 over QUIC fixes this with independent streams.
solid answer
~60 sHTTP/2 removes head-of-line blocking at the **HTTP layer** but inherits it at the **TCP layer**, and consolidating onto one connection makes that inherited blocking worse. TCP guarantees in-order delivery of a single byte stream. If one segment is lost, the kernel holds every later byte in its receive buffer - including bytes belonging to completely unrelated HTTP/2 streams - until the retransmission arrives, at least one round trip later. So a single loss stalls *all* concurrent requests. Under HTTP/1.1 with six connections, a loss on one connection stalls only the transfers on that connection; the other five keep delivering. Sharding across origins spreads the risk further still. So on links with meaningful packet loss - congested mobile, poor Wi-Fi, satellite - HTTP/2 can measurably underperform HTTP/1.1, and the effect grows with loss rate and latency. On clean networks HTTP/2 clearly wins, which is why it is still the right default. HTTP/3 is the actual fix: QUIC gives each stream independent ordering, so a lost packet delays only the streams whose data it carried.
go deeper
Know that HTTP/2 uses one TCP connection, that TCP delivers in order, so one lost packet stalls all the multiplexed requests.
Contrast it with HTTP/1.1's six connections isolating loss, and name HTTP/3 over QUIC as the fix.
Quantify roughly where the crossover sits, mention the single-congestion-window effect, and explain why it appears only in field percentiles on cellular rather than in synthetic tests.
Weigh the population: keep HTTP/2 as default, add HTTP/3 for the lossy tail, and decide what to measure - p95 by network class - rather than reverting a change that helps most users.
## Two different head-of-line problems **HTTP/1.1's head-of-line blocking** is at the message layer: one connection carries one request/response exchange at a time, so a slow response blocks everything queued behind it on that connection. HTTP/2 solves this with multiplexed streams and interleaved frames. **TCP's head-of-line blocking** is at the transport layer and HTTP/2 cannot touch it. TCP presents a socket as a single ordered byte stream. When segment N is lost, segments N+1, N+2 and so on may have arrived and be sitting in the receiver's buffer, but the kernel cannot hand them to the application without violating ordering. Everything waits for the retransmission - at minimum one round trip, more if the retransmission itself is lost or if a retransmission timeout is involved rather than fast retransmit. ## Why consolidation amplifies it HTTP/2's core benefit is putting everything on one connection. That is also the exposure. On one connection, the frames of every in-flight request are interleaved into the same byte stream, so a single lost segment stalls delivery of all of them. Concentration of benefit is concentration of risk. With HTTP/1.1's six connections, each connection is an independent TCP byte stream with its own sequence space. A loss on connection 3 stalls whatever connection 3 was carrying; the other five continue delivering to the application. Roughly, at a given loss rate and six connections, about one sixth of in-flight work is affected by any single loss instead of all of it. There is a second, subtler effect: **congestion response**. Six connections each hold their own congestion window, so the aggregate is more aggressive and a single loss halves only one of six windows. One connection means one window, and a loss cuts the whole flow's sending rate. That is arguably fairer to the network but slower for the individual page. ## Where it bites The crossover depends on loss rate, latency, and the size and count of objects. Empirically the regression starts to show around 1-2% packet loss and grows from there; on very lossy links (5% or more with high latency, such as congested cellular or satellite) HTTP/1.1 can complete a page load faster than HTTP/2. Below about 1% loss, HTTP/2's savings on handshakes, headers and queueing dominate comfortably. This is also why the regression is hard to see in the office. Your wired test network has near-zero loss and 5 ms round trips; the regression lives on a train in a tunnel. It shows up in field percentiles - p95 and p99 of real-user page load on cellular - not in synthetic tests. ## What does and does not mitigate it - **Do not go back to sharding.** It reduces exposure but reintroduces every cost HTTP/2 removed, and hurts the majority of users on clean links. - **Loss recovery improvements help.** Modern TCP stacks with SACK, RACK-TLP and BBR-style congestion control shorten stalls considerably; kernel and middlebox versions genuinely matter. - **Smaller objects and prioritisation help marginally** by reducing the amount of data waiting behind a stalled segment. - **HTTP/3 is the real fix.** QUIC implements streams above UDP with per-stream ordering, so a lost packet blocks only the streams whose bytes it carried; other streams are delivered immediately. QUIC also has cleaner loss signalling - unambiguous packet numbers, so retransmissions are never confused with originals - which makes recovery faster than TCP's. This is precisely why HTTP/3's benefit is largest exactly where HTTP/2 is weakest: lossy, high-latency mobile networks. ## The answer's shape If you can say (a) HTTP/2 fixed HTTP-layer head-of-line blocking but not TCP's, (b) single-connection consolidation turns one loss into a stall for everything, (c) HTTP/1.1's six connections accidentally provided fault isolation, and (d) HTTP/3 fixes it properly by moving stream ordering above an unordered transport - you have the whole question. Add that HTTP/2 remains the right default because most traffic is not that lossy, and you have the judgment part too.
- HTTP/2 is described as removing head-of-line blocking. How do you square that with this regression?It removes it at the HTTP layer: multiplexed streams mean a slow or large response no longer blocks other requests queued behind it on the same connection. It cannot remove TCP's, because TCP delivers one strictly ordered byte stream and the kernel will not hand over later bytes while an earlier segment is missing. Consolidating onto a single connection then means one loss stalls every stream at once.
- Would you switch back to HTTP/1.1 or re-shard domains to avoid this?No. The regression appears only above roughly 1-2% packet loss, while the great majority of traffic runs on far cleaner links where HTTP/2's savings dominate. Reverting would penalise most users to help a minority. The right responses are enabling HTTP/3 so lossy-network users get per-stream independence, keeping loss-recovery-modern TCP stacks, and measuring field percentiles by network type.
One wide conveyor belt versus six narrow ones: a jam on the single belt stops every parcel, while a jam on one of six stops only that sixth.
saying these in an interview costs you the question
- Claiming HTTP/2 eliminated head-of-line blocking completely
- Attributing the regression to HPACK or TLS overhead rather than TCP ordering
- Saying QUIC 'has no head-of-line blocking at all' - it still has it within a single stream
- Recommending domain sharding as the fix
- Expecting to reproduce the regression on a clean wired test network