HTTP has kept the same semantics — methods, status codes, headers — while overhauling how bytes travel underneath it three times. HTTP/1.1, HTTP/2, and HTTP/3 mean the same thing for a request and response, but they carry data over the network so differently that their performance characteristics diverge sharply.
HTTP/1.1: keep-alive and its limits
HTTP/1.1 introduced keep-alive (persistent connections), letting a single TCP connection be reused instead of opening a new one per request. But a connection still handled requests one at a time (pipelining effectively failed). So a slow response for an early request stalls everything behind it — Head-of-Line Blocking. Browsers worked around this by opening roughly six connections per domain, which spawned hacks like 'domain sharding' to spread files across hostnames.
HTTP/2: multiplexing
The heart of HTTP/2 is multiplexing. Over one TCP connection, many requests and responses are split into streams and exchanged concurrently. Requests no longer queue single-file, so head-of-line blocking at the HTTP layer disappears. Add HPACK header compression and (now largely deprecated) server push.
- Binary framing: binary frames instead of text — faster to parse, fewer errors.
- Multiplexing: many streams over one connection → fewer connections.
- Header compression (HPACK): stops resending repeated headers.
- Prioritization: weight streams so important resources arrive first.
But HTTP/2 has a lingering trap. Multiplexing removes blocking at the HTTP layer, yet head-of-line blocking remains at the TCP layer below. If a single packet is lost, TCP — to guarantee ordering — holds back data for all following streams until that packet is retransmitted. Because many streams share one TCP connection, a single loss stalls even unrelated streams.
HTTP/3: QUIC over UDP
HTTP/3 fixes TCP's limit by changing the transport entirely. It runs over a new protocol called QUIC, which is built on UDP. QUIC manages streams independently at the transport layer, so a lost packet on one stream doesn't affect the others — TCP's head-of-line blocking is gone at the root.
HTTP/1.1 -> TCP
HTTP/2 -> TCP (multiplexed streams, TCP HOL blocking remains)
HTTP/3 -> QUIC -> UDP (per-stream loss recovery, no TCP HOL)- Built-in TLS: QUIC integrates TLS 1.3, merging the connection and encryption handshakes → lower connection latency.
- 0-RTT resumption: send data immediately to a previously contacted server with no round trip.
- Connection migration: a connection ID keeps the session alive across Wi-Fi↔cellular switches (great for mobile).
- UDP-based: if an old firewall blocks UDP, clients fall back to TCP-based HTTP/2.
What it means in practice
The practical takeaway is that each version gets faster with less manual effort. Under HTTP/2 and HTTP/3, multiplexing can make HTTP/1.1-era optimizations like domain sharding, sprites, and over-bundling counterproductive. Most CDNs and servers support HTTP/2 by default and HTTP/3 is spreading fast, so your main job is to turn on TLS (HTTPS) and enable the latest version. Note that HTTP/2 and HTTP/3 assume HTTPS in practice, so TLS is a prerequisite for using the modern protocols.