HTTP/1.1 vs HTTP/2 vs HTTP/3

Methods, status codes, headers, caching, cookies — the semantics in HTTP: Requests, Responses, Headers and Status Codes — are the same across all three versions; an application handler cannot tell which one the client used unless it asks. What changed is the transport binding: how requests are framed, whether they share a connection, what a lost packet costs, and how many round trips it takes to start. Every row in the matrix below is a consequence of the transport choice, not of HTTP.

The rows that matter most in production are setup cost and loss behaviour, and both are easiest to see on one concrete case: a page needing six 30 kB assets from one origin, RTT 80 ms, and exactly one packet lost early in the transfer. The proportions below are an educational model — real outcomes depend on the congestion controller, the loss position, retransmission timers and whether the loss is detected by duplicate ACKs or a timeout — but the shape is what each transport guarantees.

HTTP/1.1 opens six connections, pays six handshakes (in parallel, so two RTTs of wall-clock, but six times the handshake CPU) and the loss stalls one asset while five proceed. HTTP/2 pays one handshake, then the loss stalls *all six* streams for at least one RTT while TCP retransmits, because every stream’s bytes sit behind the hole in one byte stream. HTTP/3 pays one combined round trip and the loss stalls only the stream whose data was in the lost packet — but every stream shares the congestion window, which shrinks on the loss, so the others slow rather than stop.

The choice follows the link. Inside a data centre — sub-millisecond RTT, negligible loss, warm pooled connections — HTTP/1.1 with keep-alive is perfectly adequate and the easiest to debug, proxy and load-balance; HTTP/2 is worth it when the protocol on top wants streams (gRPC requires it) or when a client makes many concurrent small requests to one backend and pooling dozens of h1 connections is awkward. HTTP/3 buys nothing here that justifies its CPU and tooling cost.

Public websites get HTTP/2 from any modern server or CDN for free, and it is the default answer: one connection, compressed headers, no sharding hacks. HTTP/3 shines on lossy, high-latency, mobile last miles — 1 RTT setup, connection migration when the phone changes network, and loss that stalls one image instead of the whole page. The pragmatic deployment is a CDN or edge load balancer that terminates HTTP/3 and HTTP/2 from clients and speaks HTTP/1.1 or /2 to origins over warm connections, so the origin never runs a QUIC stack.

Two constraints override preference. Browsers only speak h2 and h3 over TLS, so a plaintext endpoint is HTTP/1.1 (or h2c for non-browser clients). And anything in the path must support the version: a load balancer that balances TCP connections undermines h2, a firewall that drops UDP/443 removes h3, and an old proxy that buffers whole responses turns any streaming design into a batch one. Measure with real clients on real networks; the win from h3 is a distribution, not a constant.