HTTP/2 and HTTP/3 — what actually changed, and why

HTTP/1.1 can only have one request in flight per TCP connection at a time — send a request, wait for the full response, only then send the next one (Connection: keep-alive reuses the connection, but still serially). Browsers work around this by opening multiple TCP connections per host (historically 6), but that just moves the limit rather than removing it, and each connection pays its own handshake cost from the previous two lessons.

This single limitation is why front-end tooling spent years bundling many small JS/CSS files into one big file, spriting many small images into one — fewer, bigger requests genuinely outperformed many small ones under HTTP/1.1. That optimization is a direct, learned response to a protocol limitation, not a timeless best practice — which is exactly why it started reversing once HTTP/2 became widespread.

HTTP/2's core change is multiplexing — many requests and responses interleaved over a single TCP connection, each tagged with a stream ID so either side can reassemble them correctly regardless of arrival order.

One connection, one handshake, dozens of concurrent requests — this is exactly why bundling many small assets into one giant file stopped being a clear win: on HTTP/2, several smaller, cacheable files can now load in parallel over the same connection, and a change to one file doesn't invalidate the cache for the rest of a giant bundle.

HTTP/2 also added server push (a server proactively sending resources it knows the client will need next) and header compression (HTTP/1.1 headers are surprisingly large plain text, repeated on every request) — server push turned out to be hard to use correctly in practice and has since been deprecated in most browsers, a useful reminder that not every protocol feature survives contact with real-world usage.

Multiplexing solves head-of-line blocking within HTTP — but TCP itself still guarantees strict in-order delivery of every byte on the connection. If a single TCP packet is lost, TCP won't hand any later bytes to HTTP/2 until the lost packet is retransmitted and arrives — even bytes belonging to a completely different, otherwise-ready stream. HTTP/2 moved the head-of-line blocking problem down a layer; it didn't eliminate it.

HTTP/3 runs on QUIC, a transport protocol built on top of UDP instead of TCP. QUIC re-implements reliability and ordering itself (this domain's TCP vs. UDP lesson explained why UDP alone guarantees neither) — but does it per stream, so a lost packet only blocks the one stream it belonged to, not every other stream sharing the connection.

QUIC also folds the TLS handshake into its own connection setup (instead of TCP handshake, then a separate TLS handshake stacked on top), often reducing a brand-new connection to a single round trip instead of two or three — a direct, compounding win on top of the previous two lessons' handshake-cost discussion.

You almost never choose an HTTP version explicitly — browsers and servers negotiate the best one both sides support automatically, and CDNs/load balancers (covered in upcoming lessons) typically enable HTTP/2 and HTTP/3 by default with no application code changes required. What does change with your understanding: bundling everything into one giant JS file is no longer the obvious win it was under HTTP/1.1 — smaller, independently cacheable files can genuinely be the better call once HTTP/2+ is in play, which is exactly the trade-off modern bundlers (and Next.js's own automatic code-splitting) are built around.