What HTTP/1.1 Got Wrong
HTTP/1.1, standardised in 1997, assumed that each resource request was independent and relatively large. Browsers worked around its one-request-at-a-time limitation by opening multiple parallel TCP connections — typically six per domain. Each connection required a separate TCP handshake and TLS handshake, adding latency for every connection establishment. Modern web pages load hundreds of small resources (scripts, stylesheets, images, fonts), and the overhead of managing dozens of connections with their own handshakes became a significant performance bottleneck.
Pipelining — sending multiple requests without waiting for responses — was defined in HTTP/1.1 but disabled in most browsers because a slow response for one resource blocked all subsequent responses in the pipeline. This is the original head-of-line blocking problem at the HTTP level.
How HTTP/2 Solved the Request Problem
HTTP/2 (RFC 7540, 2015) introduced binary framing and stream multiplexing over a single TCP connection. Each HTTP request becomes an independent numbered stream. Frames from different streams are interleaved on the wire — the server can send half of stream 3's response, then some of stream 7's response, then the rest of stream 3's, in whatever order is most efficient. The client reassembles each stream independently.
This eliminated HTTP-level head-of-line blocking. A slow resource no longer prevents other resources from arriving. HTTP/2 also added header compression (HPACK) — HTTP headers are repetitive across requests, and HPACK uses a shared dictionary and Huffman encoding to shrink them dramatically. Server push allowed servers to proactively send resources the client would likely need, though this feature has been largely deprecated in practice due to implementation complexity.
HTTP/2's Remaining Problem: TCP Head-of-Line Blocking
HTTP/2's multiplexing elegantly solved the application-layer blocking problem, but revealed a more fundamental issue in the transport layer. TCP delivers data as an ordered byte stream and guarantees in-order delivery. If a single TCP packet is lost, TCP holds back all data received after that packet — even data belonging to completely independent HTTP/2 streams — until the lost packet is retransmitted and arrives. All streams share the same TCP connection and therefore all stall simultaneously when any packet is lost.
On a reliable low-latency wired connection with 0.01% packet loss, this is rarely noticeable. On a mobile connection with 1–2% packet loss, or on satellite internet with higher loss rates, TCP head-of-line blocking can degrade HTTP/2 performance below even HTTP/1.1 with multiple parallel connections — because HTTP/1.1's separate TCP connections are affected independently rather than all at once.
HTTP/3 and QUIC: Solving the TCP Problem
HTTP/3 (RFC 9114, 2022) replaces TCP with QUIC as its transport protocol. QUIC runs over UDP and implements its own reliability mechanism — but critically, it does so at the stream level rather than at the connection level. Each HTTP/3 stream has its own independent retransmission logic. A lost packet affects only the stream that contained it; every other stream continues delivering data without interruption.
QUIC also integrates TLS 1.3 directly into its handshake. A new QUIC connection requires only one round trip to establish (combining the transport and TLS handshakes that TCP+TLS require as two sequential round trips). For returning clients with cached session tickets, QUIC supports 0-RTT: data can be sent in the very first packet, with no handshake delay at all.
Connection Migration
TCP connections are identified by the four-tuple of source IP, source port, destination IP, and destination port. When your phone switches from Wi-Fi to cellular, your IP address changes — the TCP connection is torn down and must be re-established from scratch, interrupting any in-progress downloads or streaming sessions. QUIC connections use an opaque Connection ID instead of the network four-tuple. When the client's IP changes, it continues sending packets on the same Connection ID and the server recognises the migration without dropping the connection.
For mobile users who frequently move between networks — commuters, users in buildings with patchy coverage — QUIC connection migration means HTTP/3 sessions survive network transitions that would interrupt HTTP/2 sessions. Video streams and large downloads continue without a restart.
HTTP Version Comparison
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP | TCP | QUIC (UDP) |
| Multiplexing | No (one request per connection) | Yes (streams over one TCP) | Yes (independent QUIC streams) |
| HoL blocking | HTTP level + TCP level | TCP level only | None |
| Header compression | No | HPACK | QPACK |
| Connection setup | 1 RTT TCP + 1–2 RTT TLS | 1 RTT TCP + 1 RTT TLS 1.3 | 1 RTT (new) / 0 RTT (resumption) |
| Connection migration | No | No | Yes (via Connection ID) |
| Encryption mandatory | No | De facto (browsers require TLS) | Yes (TLS 1.3 built into QUIC) |
Real-World Performance
On fast, reliable broadband connections with low packet loss, HTTP/2 and HTTP/3 deliver similar page load times. Both multiplexing approaches handle the hundreds of small resources modern pages require without significant bottlenecks. The 0-RTT advantage of HTTP/3 is most visible on the initial page load latency for returning visitors — typically 20–50 ms savings.
The performance gap widens significantly on mobile and degraded networks. Cloudflare's measurements show HTTP/3 can be 10–30% faster than HTTP/2 at 1% packet loss, and progressively more advantageous as packet loss increases. For streaming services, the connection migration feature means fewer rebuffers during commutes. For global users connecting to CDN edge nodes over long distances, the reduced handshake RTT compounds across every page load.
Frequently Asked Questions
What is the main difference between HTTP/2 and HTTP/3?
The fundamental difference is the transport layer. HTTP/2 runs over TCP — a single lost packet stalls every stream. HTTP/3 runs over QUIC on UDP with per-stream reliability, so a lost packet only blocks its own stream. HTTP/3 also integrates TLS 1.3 into QUIC, reducing new connections to 1 RTT and enabling 0-RTT resumptions.
Does HTTP/3 require HTTPS?
Yes. QUIC has TLS 1.3 built in as a mandatory component — there is no unencrypted QUIC. Every HTTP/3 connection is always encrypted. This is a deliberate design decision to ensure encryption is non-optional from the start rather than becoming an optional feature that persists in unencrypted form for decades.
Is HTTP/3 faster than HTTP/2?
HTTP/3 is faster primarily on lossy or high-latency networks — mobile, satellite, and congested Wi-Fi. On these networks, TCP head-of-line blocking causes disproportionate HTTP/2 slowdowns. On fast, reliable wired connections with low packet loss, the difference is small. The 0-RTT resumption provides a consistent small latency advantage on returning visits.
Does HTTP/3 work on all networks?
Not always. HTTP/3 uses QUIC over UDP port 443. Some corporate firewalls block UDP 443 or misidentify QUIC. Browsers handle this gracefully — if QUIC fails, they automatically fall back to HTTP/2 over TCP. Most consumer networks pass QUIC without issue.
What is 0-RTT in HTTP/3?
0-RTT allows a client that has previously connected to a server to send the first HTTP request with the connection establishment packet, with no handshake delay. QUIC caches session tickets from previous connections. Standard HTTPS/TCP requires 2 RTTs before data; QUIC requires 1 RTT for new connections and 0 RTT for resumptions.
How do I know if a website uses HTTP/3?
In Chrome DevTools, open the Network tab, enable the Protocol column — HTTP/3 connections show as h3. Firefox's Network tab also labels HTTP/3 as h3. Check response headers for Alt-Svc: h3=":443" to see whether the server advertises HTTP/3 support.