HTTP Protocol Versions
also called HTTP/1.1, HTTP/2, HTTP/3, QUIC
What each HTTP version changed, which problem it solved, and where the benefit actually shows up.
Definition
| Version | Key change | Solves | Remaining problem |
|---|---|---|---|
| HTTP/1.1 | Persistent connections, pipelining (unused in practice) | Handshake per request | One request at a time per connection |
| HTTP/2 | Multiplexed streams over one TCP connection, header compression, server push | Connection count, header overhead | TCP-level head-of-line blocking |
| HTTP/3 | HTTP over QUIC (UDP), streams independent | Head-of-line blocking, faster handshake, connection migration | Middlebox and UDP-throttling issues |
Where the gains actually land
HTTP/2's multiplexing removed the need for the workarounds of the HTTP/1.1 era — domain sharding, sprite sheets, inlining — because many concurrent requests over one connection stopped being expensive. Its benefit is largest for pages with many small resources.
HTTP/3's benefit is concentrated on poor networks. On a clean fibre connection the difference from HTTP/2 is small. On a mobile network with 2% packet loss, the difference is large, because a lost packet no longer stalls unrelated streams. Two further properties matter more than people expect: connection migration — a connection survives a change of IP address, so moving from Wi-Fi to cellular does not drop it — and a 0-RTT or 1-RTT handshake including encryption.
The general lesson: the value of each version is a function of network conditions and resource count, not of version number. Measuring across your actual user population is the only way to know what you will get.
Industry example
Cloudflare's position at the edge of a very large share of internet traffic makes them one of the main drivers and measurers of these transitions, and their published measurements consistently show the same shape: aggregate improvements are modest, and improvements for the worst-connected users are substantial.
That asymmetry is the architecturally interesting part. Protocol upgrades of this kind are best understood as tail-latency and equity improvements rather than throughput improvements. If your success metric is median page load, you will conclude the upgrade did nothing. If it is p95 for users on mobile networks in regions with poor connectivity, you will see a real gain.
Failure scenarios
- Server push, which sounded good, wasted bandwidth pushing resources clients already cached, and was effectively abandoned. A useful reminder that protocol features can be net negative.
- HTTP/2 to the edge, HTTP/1.1 to the origin, so the internal hop remains the bottleneck.
- UDP blocked or throttled by corporate networks, so HTTP/3 silently falls back — which is fine, provided you are measuring the fallback rate rather than assuming adoption.
- Too many concurrent streams on one connection, moving the queue from the network into the server.
Interview question
"Your team upgraded to HTTP/3 and median page load did not change. Was the upgrade worthless? How would you find out?"