HTTP/1.1 vs 2 vs 3 (QUIC)

The recurring villain: head-of-line blocking

Each HTTP version exists to fix a specific bottleneck of the previous one, and the recurring villain is head-of-line (HOL) blocking: a stuck item stalls everything behind it. Knowing where HOL blocking bites in each version is the whole lesson.

HTTP/1.1

One request in flight per connection. You send a request, you wait for its full response, then you send the next. Keep-alive lets you reuse the connection but not overlap requests (pipelining exists on paper but is broken in practice). To get parallelism, browsers open about 6 connections per host, which means 6 handshakes and 6 slow-start ramps, and everything past 6 queues. HOL blocking here is at the request level: a slow response blocks its whole connection.

HTTP/2

Multiplexing. Many requests become independent streams over a single TCP connection, interleaved as frames, so you send all your requests at once and responses come back concurrently over one warm connection. Add header compression (HPACK), since HTTP headers are hugely repetitive. This kills application-level HOL blocking and the 6-connection tax. But there is a catch that interviewers love: TCP-level HOL blocking remains. Because all streams ride one TCP connection, a single lost TCP packet stalls TCP's ordered delivery, and every multiplexed stream waits for that retransmission, even streams whose data already arrived. On a clean network you never notice; on a lossy one, H2 can be worse than H1's separate connections.

HTTP/3 over QUIC

QUIC is a new transport built on UDP that reimplements reliability, ordering, and congestion control per stream. Because each stream is independently reliable, a lost packet only stalls its own stream, not the others: QUIC removes TCP-level HOL blocking. It also folds the transport and TLS handshake together for a faster (often 1-RTT, 0-RTT on resumption) setup, and supports connection migration: the connection is identified by a connection ID, not the 4-tuple, so a phone switching from Wi-Fi to cellular (new IP) keeps the same connection instead of re-handshaking.

When does H3 actually win? On lossy and mobile networks and paths with many short connections, where per-stream independence and connection migration matter most. On a stable, low-loss, high-bandwidth link (two datacenters), H3's advantage over H2 is marginal, and UDP can even be throttled or blocked by some middleboxes, and its user-space congestion control can burn more CPU than kernel TCP. So H3 is a clear win at the mobile-facing edge, a weak case for stable internal links.

Interview nuance: gRPC runs on HTTP/2 today. So internal service-to-service RPC is naturally H2 (multiplexed streams, which gRPC needs for streaming). The common real topology: public edge on H2 and H3 (serve mobile users the H3 benefit, fall back to H2), internal RPC on H2/gRPC where the network is stable and H3 adds little.

Recap: HOL blocking is the theme, H1 blocks per request and needs ~6 connections, H2 multiplexes over one TCP connection but still suffers TCP-level HOL blocking on loss, H3/QUIC removes it with per-stream reliability over UDP plus connection migration, so use H3 at the lossy/mobile edge and keep stable internal RPC on H2/gRPC.