HTTP/2 vs HTTP/3: QUIC, Multiplexing, and the Future of the Web Transport

HTTP/1.1 ruled the web for almost two decades. HTTP/2, released in 2015, brought multiplexing and header compression. HTTP/3, finalized in 2022 and dominant by 2026, abandoned TCP entirely in favor of QUIC over UDP. Each generation solves problems the previous version couldn’t.

This post compares HTTP/2 and HTTP/3 at a practical level: what each version does differently, the engineering reasons for the changes, and what to do (or not do) in your own applications.

HTTP/1.1 in a Sentence

For context: HTTP/1.1 was strictly one-request-per-connection. To load a page with 50 resources, browsers opened 6-8 parallel connections to amortize the latency. Each connection had its own TCP and TLS handshakes. Head-of-line blocking within each connection meant a slow response delayed everything after it.

This was fine on a 1995 web with 10 resources per page. It became painful as pages grew to hundreds of resources.

HTTP/2: Multiplexing Over TCP

HTTP/2 (RFC 7540, 2015) kept TCP but redesigned everything above it.

Multiplexing

A single HTTP/2 connection carries many parallel requests as streams. Each request/response pair is a stream with a unique ID. The TCP connection interleaves frames from multiple streams.

Stream 1: GET /styles.css        →
Stream 3: GET /app.js            →
Stream 5: GET /image.png         →
                                 ← (response frames for any stream, in any order)

No more “open 6 connections” hack. One connection, many streams.

Header compression (HPACK)

Headers in HTTP/1.1 are sent in full text on every request. HTTP/2 uses HPACK to compress them and reference common headers from a shared table, saving significant bytes.

Server push (now deprecated)

HTTP/2 could push resources to clients before they asked. In theory useful for pre-loading critical resources. In practice, complex and often counterproductive. Removed from major browsers; Chrome dropped support in 2022.

Binary framing

HTTP/2 uses a binary protocol, not text. Faster to parse, less ambiguous to handle. The text-mode debugging convenience of HTTP/1.1 (telnet host 80) is lost; tools like curl --http2 and Wireshark are required instead.

The TCP problem

HTTP/2 multiplexed at the application layer, but TCP still saw it as one byte stream. TCP head-of-line blocking still applied: if a single packet was lost or delayed, all streams sharing the connection waited for that packet to be retransmitted, even unrelated streams.

In good network conditions, HTTP/2 is dramatically faster than HTTP/1.1. In poor network conditions (mobile, lossy Wi-Fi), the head-of-line blocking can make it slower.

HTTP/3: HTTP Over QUIC

HTTP/3 (RFC 9114, 2022) keeps the HTTP semantics (request, response, headers, status codes) but changes the transport entirely.

Instead of running over TCP, it runs over QUIC — a new transport protocol over UDP.

QUIC fundamentals

• UDP-based. No TCP. The OS sees only UDP packets.
• Built-in encryption. TLS 1.3 is mandatory and integrated into the protocol (not bolted on like HTTPS over TCP).
• Built-in multiplexing. QUIC understands streams natively, not just bytes. Head-of-line blocking is per-stream, not per-connection.
• Connection migration. A QUIC connection survives IP changes (e.g., switching from Wi-Fi to cellular) without renegotiating.
• 0-RTT resumption. Repeated connections can send data immediately, no handshake delay.

What HTTP/3 inherits from HTTP/2

• Multiplexing and streams (now native to the transport)
• Header compression (now QPACK instead of HPACK, adapted for QUIC’s streaming semantics)
• Binary framing

What HTTP/3 adds

• Loss recovery is per-stream. Lose one packet for stream 5; stream 3 keeps flowing.
• Faster connection setup. One round trip for handshake + first request (vs ~2 for TCP+TLS+HTTP/2 first time).
• Resilience to network changes. Mobile users walking between Wi-Fi and cellular don’t see broken connections.

HTTP/3 vs HTTP/2: When the Differences Show Up

For a user on a fast, low-loss network (corporate Ethernet, good home Wi-Fi), the difference between HTTP/2 and HTTP/3 is small. Both multiplex; both compress headers; both ride TLS 1.3.

The differences appear in:

Mobile networks

Higher packet loss, frequent network transitions. HTTP/3 dramatically outperforms here.

Poor Wi-Fi

Same as mobile — head-of-line blocking matters when packets get lost.

Repeated requests

HTTP/3’s 0-RTT means a returning client doesn’t wait for the handshake. Useful for any API where the same client returns frequently.

Long-lived connections

QUIC connections survive IP changes. HTTP/2 connections don’t.

Benchmarks vary, but typical results show HTTP/3 with 10-30% latency improvements on lossy networks and negligible difference on clean ones.

Adoption State in 2026

• Chrome, Edge, Safari, Firefox — All support HTTP/3 by default.
• Cloudflare, Akamai, Fastly, CloudFront — All offer HTTP/3 termination.
• Major sites — Google, Facebook, YouTube, Cloudflare-fronted sites — virtually all HTTP/3-capable.
• Origin servers — Mixed. nginx 1.25+ supports HTTP/3; Apache requires modules; many older deployments are still HTTP/2.

The typical deployment is HTTP/3 at the edge, HTTP/2 or HTTP/1.1 between edge and origin. The user-facing benefit is captured; the origin connection complexity is avoided.

Network Considerations

QUIC over UDP has practical implications.

Firewall handling

Many firewalls have always blocked or rate-limited UDP. Some specifically allow well-known UDP ports (53 for DNS, 443 for QUIC). Others don’t. In restricted networks, HTTP/3 falls back to HTTP/2 automatically.

UDP performance kernel paths

TCP has been optimized in the kernel for decades. UDP at high bandwidth used to be slower because more processing happened in userspace. Modern kernels (Linux 5.x+) have UDP fast paths that close most of the gap.

NAT timeout

QUIC connections must keep NAT entries alive. The protocol sends keepalive frames. Most NATs work fine, but very aggressive consumer routers can drop UDP entries quickly, causing connection breaks.

How HTTP/3 Negotiation Works

A client doesn’t know whether the server supports HTTP/3 until it asks. The flow:

1. Client connects via HTTP/2 (TCP) to the server.
2. Server responds with an Alt-Svc header: Alt-Svc: h3=":443"; ma=86400 — “I support HTTP/3 on port 443 for the next 24 hours.”
3. Client caches this, and for future connections, tries HTTP/3 first.
4. If HTTP/3 fails (firewall blocks UDP), client falls back to HTTP/2.

This bootstrap-via-HTTP/2 model is the practical reason most sites still run both HTTP/2 and HTTP/3.

Server Push Was Deprecated

A note for anyone implementing HTTP/2 in 2026: don’t use Server Push. It’s been removed from Chrome and is deprecated in the HTTP/2 spec. The replacement is HTTP 103 Early Hints:

HTTP/2 103 Early Hints
Link: </styles.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script

HTTP/2 200 OK
...

The 103 hint tells the browser to start preloading critical resources while the main response is still being prepared. Better than Server Push in most ways.

What This Means for Your Application

You probably don’t change anything

HTTP semantics are unchanged: GET, POST, PUT, headers, status codes, JSON bodies. Your application code stays the same.

Make sure your edge supports HTTP/3

If you’re behind Cloudflare, Vercel, CloudFront — you have HTTP/3 by default. Confirm in DevTools (the h3 protocol indicator).

Don’t optimize for HTTP/1.1 anymore

• Don’t shard domains. With multiplexing, one connection is faster than many. Sharded domains (img1.example.com, img2.example.com) hurt instead of help.
• Don’t inline everything. With cheap multiplexing, separate files are fine. Inlining hurts caching.
• Don’t sprite images. CSS sprites were an HTTP/1.1 workaround; with multiplexing, separate images cache better.

Optimize for first-request latency

The bottleneck in 2026 is rarely throughput. It’s the latency to get the first byte. HTTP/3’s 1-RTT setup and 0-RTT resumption directly attack this.

Use 103 Early Hints

When your origin is slow to render but you know what assets will be needed, 103 tells the browser to start fetching them. Works on HTTP/2 and HTTP/3.

Diagnosing HTTP/3 Issues

A few practical tips:

Confirm HTTP/3 is negotiated

DevTools → Network → “Protocol” column. You’ll see h2, h3, or http/1.1.

Check Alt-Svc

curl -I https://example.com

Look for Alt-Svc: h3=":443". If present, the server is advertising HTTP/3.

Force HTTP/3 with curl

curl --http3 https://example.com

Requires curl built with QUIC support.

Check firewall

If HTTP/3 doesn’t work but HTTP/2 does, suspect UDP filtering on the path.

TLS, QUIC, and the Big Picture

HTTP/3’s choice to integrate TLS 1.3 into the transport is a meaningful architectural shift. Instead of:

• TCP (transport)
• TLS (encryption on top of TCP)
• HTTP/2 (application on top of TLS)

You have:

• QUIC (transport + encryption, integrated)
• HTTP/3 (application on top of QUIC)

The fewer-layer stack is harder to misconfigure (TLS settings are part of QUIC, not a separate concern) and faster to set up (one handshake, not two). See TLS handshake for what’s happening underneath.

TL;DR

• HTTP/2 multiplexed many streams over a single TCP connection. Still TCP. Still subject to TCP head-of-line blocking.
• HTTP/3 runs over QUIC (UDP-based transport with TLS 1.3 built in). No TCP. Per-stream loss recovery. Faster setup.
• HTTP/3 dominates on mobile and lossy networks. About the same as HTTP/2 on clean networks.
• All major browsers and CDNs support HTTP/3 in 2026.
• Don’t shard, sprite, or inline. Multiplexing makes those obsolete.
• Use 103 Early Hints instead of HTTP/2 Server Push (which has been deprecated).
• HTTP/3 is the practical default for client-facing connections in 2026.

Most application developers don’t write HTTP/3 code directly — the edge handles it. But understanding what’s happening makes a big difference when debugging performance, designing CDN-friendly applications, or thinking about geographic latency. For the encryption layer that QUIC depends on, see TLS handshake. For where this all gets deployed, see CDN vs edge computing.