HTTP/2 vs HTTP/3
Multiplexed streams over TCP versus QUIC-based transport
HTTP/2 introduced multiplexed streams, header compression, and server push over TCP connections, dramatically improving web performance over HTTP/1.1. HTTP/3 rebuilds the transport layer on QUIC (based on UDP) to eliminate head-of-line blocking, reduce connection setup latency, and enable seamless connection migration. HTTP/2 is universally supported today; HTTP/3 is rapidly gaining adoption and offers meaningful improvements for mobile and high-latency networks.
HTTP/2
HTTP/2, standardized in 2015 (RFC 7540), was a major evolution of the HTTP protocol designed to address the performance limitations of HTTP/1.1. Its most important feature is multiplexing: multiple requests and responses can be interleaved over a single TCP connection as independent streams, eliminating the need for workarounds like domain sharding and CSS spriting that HTTP/1.1 required. HTTP/2 introduced several performance features. HPACK header compression reduces overhead by encoding frequently used headers (like cookies and user-agent strings) efficiently. Server push allows the server to proactively send resources (CSS, JavaScript) before the client requests them (though this feature is deprecated in practice due to complexity). Stream prioritization lets clients indicate which resources are most important. Binary framing replaces HTTP/1.1's text-based protocol with a more efficient binary format. HTTP/2 is supported by virtually all modern browsers and web servers (nginx, Apache, Caddy, Cloudflare). It runs over TCP with TLS (HTTPS), and most implementations require TLS. The major remaining limitation is TCP's head-of-line blocking: if a single TCP packet is lost, all multiplexed streams are blocked until retransmission succeeds. This can negate multiplexing benefits on lossy networks (mobile, Wi-Fi).
HTTP/3
HTTP/3, standardized in 2022 (RFC 9114), replaces TCP with QUIC as the transport layer. QUIC is a transport protocol built on UDP that integrates TLS 1.3 encryption, provides its own reliable delivery, and supports independent stream multiplexing. This architectural change solves TCP's fundamental head-of-line blocking problem. HTTP/3's key innovation is that each QUIC stream is independent at the transport level. If a packet belonging to one stream is lost, only that stream is blocked while awaiting retransmission. Other streams continue unimpeded. This is a fundamental improvement over HTTP/2, where a single lost TCP packet blocks all streams. QUIC also reduces connection setup latency: it combines the transport handshake with TLS 1.3 in a single round trip (1-RTT), and returning clients can send data in the first packet (0-RTT). QUIC supports connection migration, meaning a client can switch networks (e.g., from Wi-Fi to cellular) without dropping the connection. The connection is identified by a connection ID rather than a source IP/port pair. HTTP/3 is supported by major browsers (Chrome, Firefox, Safari, Edge), CDNs (Cloudflare, Fastly, Akamai), and load balancers. Google reports that HTTP/3 reduces search latency by 2% and YouTube rebuffering by 9% compared to HTTP/2.
Key Differences
- **Transport protocol**: HTTP/2 runs over TCP. HTTP/3 runs over QUIC (UDP-based). - **Head-of-line blocking**: HTTP/2 suffers from TCP-level head-of-line blocking. HTTP/3 eliminates it with independent QUIC streams. - **Connection setup**: HTTP/2 requires TCP handshake + TLS handshake (2-3 round trips). HTTP/3 combines them in 1 round trip (0-RTT for returning clients). - **Connection migration**: HTTP/2 connections break on network changes. HTTP/3/QUIC connections survive network switches. - **Encryption**: HTTP/2 can technically run without TLS (h2c), but browsers require it. HTTP/3 mandates TLS 1.3 encryption always. - **Adoption**: HTTP/2 is universally supported. HTTP/3 support is growing rapidly (major browsers and CDNs support it). - **Middlebox compatibility**: HTTP/2 over TCP works with all network middleboxes. QUIC/UDP can be blocked by some firewalls and middleboxes. - **Performance impact**: HTTP/3 shows biggest improvements on lossy, high-latency networks (mobile, developing regions).
When to Use Each
**Use HTTP/2** as the minimum standard for all web properties. It is universally supported and dramatically better than HTTP/1.1. HTTP/2 remains the right choice when your infrastructure does not yet support QUIC, when your audience is primarily on reliable wired connections, or when network middleboxes in your deployment block UDP. **Use HTTP/3** when your CDN or load balancer supports it (Cloudflare, Fastly, and Google Cloud enable it by default), when your audience includes mobile users or users in regions with high-latency/lossy networks, and when you want the fastest possible connection setup for repeat visitors (0-RTT). Most sites should enable HTTP/3 where supported, with automatic HTTP/2 fallback.
Analogy
HTTP/2 is like a multi-lane highway built on a single bridge (TCP). If there is an accident on the bridge, all lanes stop until it is cleared (head-of-line blocking). HTTP/3 is like a highway where each lane has its own bridge (independent QUIC streams). An accident on one bridge blocks only that lane. Plus, QUIC bridges set up faster (0-RTT) and can even relocate (connection migration) if you change routes mid-journey.