HTTP/1.1, HTTP/2 and HTTP/3

All three versions carry the same HTTP semantics — methods, status codes, headers. What changes is how requests travel over the network.

#HTTP/1.1

• Text protocol over TCP. Persistent connections (keep-alive) let several requests reuse a connection, but one at a time: a slow response blocks the requests behind it.
• Browsers work around this by opening about six connections per origin, each with its own TCP and TLS handshake.

#HTTP/2

• Binary framing over one TCP connection, with many streams multiplexed at once: requests and responses interleave, so a slow response no longer blocks others at the HTTP level.
• Header compression (HPACK) shrinks repetitive headers such as cookies.
• Still on TCP, so a single lost packet stalls all streams until it's retransmitted (TCP head-of-line blocking).
• gRPC runs on HTTP/2.

#HTTP/3

• Runs over QUIC on UDP. Each stream is delivered independently, so packet loss only delays the affected stream.
• Faster connection setup: transport and TLS 1.3 handshakes combined into one round trip, zero for resumed sessions.
• Connections survive network changes (Wi-Fi to mobile) because they're identified by connection ID.

#Design implications

• Long-lived multiplexed connections change load balancing. With HTTP/2 or gRPC, one client may send all its requests over one connection, so an L4 load balancer that balances connections can pin a busy client to one backend. Balance requests at L7 instead (API gateway vs load balancer).
• Fewer connections, fewer handshakes. HTTP/2 and HTTP/3 make it cheaper to fetch many small resources; "bundle everything into one file" matters less than it did.
• Clients vary. Serve HTTP/2 and HTTP/3 at the edge (CDNs do this for you) and accept that internal hops may still be HTTP/1.1.

See TCP vs UDP for the transport-level trade-offs.