HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP (Hypertext Transfer Protocol) is the application-layer protocol that powers the web. Its evolution across three major versions reflects the changing demands of web applications -- from static document retrieval to complex, latency-sensitive single-page applications serving billions of users. Understanding the differences between HTTP/1.1, HTTP/2, and HTTP/3 is critical for system design because the choice of HTTP version affects page load performance, server resource utilization, and infrastructure requirements for CDNs, load balancers, and API gateways.

HTTP/1.1, standardized in 1997 (RFC 2068, revised as RFC 2616 and then RFC 7230-7235), introduced persistent connections (keep-alive) so clients could reuse a TCP connection for multiple requests instead of opening a new one for each resource. However, HTTP/1.1 processes requests sequentially on each connection: the client must wait for the response to request N before sending request N+1 (head-of-line blocking at the application layer). While pipelining was theoretically supported, it was poorly implemented by proxies and servers and was never widely adopted. To work around this, browsers open 6-8 parallel TCP connections per origin, leading to TCP congestion control contention, redundant TLS handshakes, and inefficient use of network resources. Techniques like domain sharding, CSS sprites, and resource inlining emerged as workarounds but added complexity to application development.

HTTP/2, standardized in 2015 (RFC 7540) and derived from Google's SPDY protocol, fundamentally changed how HTTP requests are transmitted. HTTP/2 introduces binary framing: requests and responses are broken into small frames that are interleaved (multiplexed) on a single TCP connection. Multiple streams can be in-flight simultaneously, eliminating application-layer head-of-line blocking. HPACK header compression reduces redundant header bytes (cookies, user-agent, etc.) that were sent with every HTTP/1.1 request. Server push allows the server to proactively send resources the client will need (though this feature saw limited adoption and was deprecated in some implementations). HTTP/2 reduced page load times by 15-50% compared to HTTP/1.1 and is now the default for major CDNs and web servers. However, HTTP/2 still runs over TCP, which means transport-layer head-of-line blocking persists: a single lost TCP packet blocks all multiplexed streams.

HTTP/3, standardized in 2022 (RFC 9114), replaces TCP with QUIC (RFC 9000) as the transport protocol. QUIC runs over UDP and provides per-stream flow control and loss recovery, meaning a lost packet on one stream does not block other streams -- solving the transport-layer head-of-line blocking that plagued HTTP/2. QUIC integrates TLS 1.3 directly into its handshake, reducing connection setup from 2-3 RTTs (TCP + TLS) to 1 RTT, or 0 RTT for resumed connections. QPACK (the HTTP/3 analog of HPACK) provides header compression adapted for QUIC's out-of-order delivery. By 2026, HTTP/3 adoption has reached approximately 30% of global web traffic, with CDNs like Cloudflare, Fastly, and Akamai supporting it by default. The benefits are most pronounced on lossy mobile networks, where TCP's sensitivity to packet loss causes disproportionate performance degradation.

HTTP/1.1 is like a single-lane road where cars (requests) must follow each other -- if the car in front stops, everyone behind waits. Opening multiple TCP connections is like adding parallel single-lane roads, but each has its own traffic signal and toll booth overhead. HTTP/2 is like a multi-lane highway on a single road: cars can travel side by side (multiplexing), but if there is a pothole (packet loss) on the road surface itself, all lanes are affected because they share the same pavement. HTTP/3 is like giving each lane its own separate road surface: a pothole in lane 1 only affects lane 1, while lanes 2 and 3 continue unimpeded.