HTTP/1.1, HTTP/2, and HTTP/3

The evolution from HTTP/1.1 to HTTP/2 and HTTP/3 is mostly a story about reducing wasted time on the network without changing the core semantics of the web. Methods, status codes, and most application behaviour stayed familiar. What changed was how requests and responses are transported.

HTTP/1.1: simple and durable, but chatty

HTTP/1.1 runs over TCP and represents messages in a mostly text-based format. It introduced persistent connections, which avoided opening a fresh TCP connection for every request, but browsers still hit practical limits. To fetch many assets in parallel, clients often opened multiple connections to the same origin. Head-of-line blocking was a major problem because one slow response on a connection could delay the work queued behind it.

Pipelining existed on paper, but deployment issues meant it never became a dependable solution on the public web.

HTTP/2: multiplexing over one connection

HTTP/2 keeps HTTP semantics but switches to binary framing. Multiple streams can share one TCP connection, so a browser can request many resources at once without the old per-connection queueing problem inside the application protocol. Header compression reduces repeated metadata overhead, which matters because browsers send many similar headers across related requests.

This is a real improvement, but TCP still sits underneath. If packets are lost, TCP delivers bytes in order, so loss affecting one stream can still stall others sharing the same connection at the transport level. HTTP/2 removed much of the old application-layer blocking, not all network-layer blocking.

HTTP/3: QUIC and stream-level recovery

HTTP/3 moves from TCP to QUIC, which runs over UDP and includes transport security similar to TLS in its design. QUIC supports multiple streams with independent loss recovery, so packet loss on one stream is less likely to freeze unrelated streams. It also supports connection migration, which helps when a device moves between networks, such as switching from Wi-Fi to mobile data.

The performance benefit is not "HTTP/3 is always faster". It is that the protocol behaves better under packet loss, high latency, and connection changes.

What this means operationally

For most applications, upgrading protocol versions does not remove the need for caching, compression, or sensible asset strategy. A bloated page is still bloated on HTTP/3. The newer protocols simply spend less time fighting transport inefficiencies.

A practical summary is:

• HTTP/1.1 is widely compatible and operationally familiar.
• HTTP/2 improves parallelism and header efficiency.
• HTTP/3 improves recovery and connection behaviour on modern networks.

The application model stayed stable. The transport got smarter.

This is why protocol support is usually enabled at the edge, through a CDN or reverse proxy, rather than implemented application by application. Backend services keep speaking familiar HTTP semantics while the edge negotiates the most efficient transport version each client can support.