HTTP/1.1, HTTP/2 and HTTP/3: What Each Version Fixed and What It Left Broken

A request for /index.html means the same thing it meant in the nineties. What changed is the cost of asking for forty things at once, and each version of HTTP is the answer to the bottleneck the last one left behind.

Timeline

HTTP/1.1: text, one at a time

HTTP/1.1 keeps a TCP connection open for several requests (persistent connections), which saved the cost of a fresh handshake for each file. But on one connection, responses come back in order. A slow response blocks the ones behind it. This is HTTP-level head-of-line blocking.

Pipelining was meant to help (send several requests without waiting), but servers and proxies handled it unreliably, so browsers disabled it. The workaround was brute force: open six or so connections per host and spread requests across them, with tricks like domain sharding and bundling files together.

HTTP/2: many streams, one connection

What HTTP/2 left broken

HTTP/2 still rides on one TCP connection. TCP delivers bytes strictly in order, so when a single packet is lost, TCP holds back everything after it, including data belonging to other, unaffected streams, until the retransmission arrives. On a clean wired network that is rare. On lossy mobile or Wi-Fi it can make HTTP/2 worse than several HTTP/1.1 connections.

HTTP/3: a new transport underneath

HTTP/3 keeps HTTP/2’s ideas (streams, header compression via QPACK) but runs over QUIC, a transport built on UDP.

HTTP/1.1  : HTTP  / TLS / TCP
HTTP/2    : HTTP  / TLS / TCP
HTTP/3    : HTTP  / QUIC (streams + TLS 1.3 + loss recovery) / UDP

UDP is only the carrier. QUIC implements reliability, congestion control and encryption itself, in user space. That unlocks:

Side by side

Choosing and verifying

HTTP/3 is not automatically faster for every user. Gains are largest on high-latency, lossy or mobile networks. On a fast, stable connection, HTTP/2 and HTTP/3 are close. Some corporate networks block or throttle UDP, so clients must fall back to HTTP/2, and good deployments keep both enabled.

Servers advertise HTTP/3 with an Alt-Svc header, and browsers switch on later requests, which is why the first visit often shows h2.

curl -sI --http2 https://example.com | head -1     # HTTP/2 200
curl -sI --http3 https://example.com | head -1     # needs a curl built with HTTP/3
curl -sI https://example.com | grep -i alt-svc     # alt-svc: h3=":443"

In browser developer tools, add the Protocol column in the Network panel and look for h2 or h3.

Takeaway

Each HTTP version removed the bottleneck of the one before: HTTP/1.1 reused connections, HTTP/2 multiplexed requests on one connection, HTTP/3 stopped one lost packet from stalling everything by moving to QUIC. Enable all three with fallbacks, retire the old workarounds, and test on the networks your users really have.