How HTTP/2 and HTTP/3 work

What HTTP/1.1 left on the table

HTTP/1.1 (1999) is human-readable: request lines like GET /api/user HTTP/1.1, header blocks, blank line, optional body. It works, but three structural costs show up on every modern page with dozens of assets:

• Head-of-line (HOL) blocking at the application layer — on one TCP connection, response B cannot start until response A finishes. Browsers opened 6–8 parallel connections per host as a workaround, which multiplied TCP handshakes and TLS round trips.
• Redundant headers — every API call resends User-Agent, Accept, cookies, and auth tokens. On chatty SPAs, headers can exceed JSON payloads.
• No server-initiated push of critical CSS without hacks — developers inlined critical CSS, sprited images, and concatenated JS bundles because each new file meant another sequential wait on a crowded connection.

HTTP/2 (2015, RFC 7540) and HTTP/3 (2022, RFC 9114) keep the same semantics — methods, status codes, URLs — but redesign how bytes move. Your REST handlers stay identical; nginx, Cloudflare, or Envoy terminate the new protocols at the edge.

HTTP/2: one TCP connection, many streams

HTTP/2 replaces the text wire format with binary framing. Every message splits into frames (HEADERS, DATA, SETTINGS, WINDOW_UPDATE, etc.) tagged with a stream ID. Stream 1 might carry your HTML document; streams 3, 5, and 7 fetch CSS, JS, and a WebP hero image concurrently on the same TCP socket.

Key mechanisms:

• Multiplexing — interleaved frames from different streams share bandwidth fairly (in theory). No browser connection cap gymnastics for HTTP/2-enabled origins.
• HPACK header compression — a dynamic table on each side stores recently seen header name/value pairs. The second request to /api/feed might send a one-byte index instead of repeating a 400-byte cookie header.
• Flow control — per-stream and connection-level credit, similar in spirit to TCP rwnd. A slow consumer cannot stall unrelated streams indefinitely if the server respects WINDOW_UPDATE frames.
• Stream prioritization — weight trees let browsers hint "HTML before decorative images." Real-world benefit varies; many stacks simplified or ignored complex priority trees after measurement showed marginal gains.
• Server Push (largely retired) — the server could preemptively send assets before the client asked. Cache mismatches and double downloads made push rare in production; most CDNs deprecated it in favor of <link rel="preload"> hints.

Clients negotiate HTTP/2 via ALPN during the TLS handshake: the ClientHello lists h2 and the server picks it over http/1.1. Cleartext HTTP/2 exists (h2c) but is uncommon on the public internet because intermediaries expect HTTP/1.1 text.

The TCP problem HTTP/2 could not fix

Multiplexing solves application-layer HOL blocking, but HTTP/2 still rides on TCP. If one packet is lost, TCP retransmits and the entire connection stalls until recovery — even streams whose data was already received sit idle. On a clean datacenter link you never notice. On a lossy LTE handoff, one dropped packet can freeze all twelve parallel downloads for an RTT.

That transport-level stall is why Google started QUIC (Quick UDP Internet Connections) in 2012 and standardized it as HTTP/3's foundation. QUIC implements reliability, encryption, and congestion control in user space over UDP, decoupling loss recovery per stream instead of per connection.

HTTP/3 and QUIC: UDP with TLS baked in

HTTP/3 (RFC 9114) maps HTTP semantics onto QUIC (RFC 9000). Important properties:

• Independent streams — loss on stream 5 does not block delivery of stream 7's frames. Each stream has its own byte offset and reassembly buffer.
• Integrated TLS 1.3 — QUIC encrypts almost everything, including packet headers (with a few exposed bits for routing). There is no cleartext QUIC on the public web.
• 0-RTT resumption — repeat visitors can send application data in the first flight if they hold valid session tickets. Useful for API latency; watch replay risk on non-idempotent POSTs (see our idempotency keys explainer).
• Connection migration — QUIC connections are identified by cryptographic IDs, not the 4-tuple (src IP, src port, dst IP, dst port). A phone switching from Wi-Fi to cellular can migrate without a full new handshake — valuable for mobile wallets and live dashboards.
• User-space implementations — browsers and servers update QUIC without waiting for OS kernel TCP stack releases. Faster iteration, but CPU cost can exceed kernel TCP on high-throughput servers unless tuned.

Discovery uses Alt-Svc or HTTPS DNS records: an HTTP/2 response advertises alt-svc: h3=":443" and the next navigation tries QUIC. Browsers fall back to HTTP/2 or HTTP/1.1 if UDP/443 is blocked by corporate firewalls — still a real deployment constraint in 2026.

Performance: what actually improves

Benchmarks are noisy, but patterns repeat:

• HTTP/2 vs HTTP/1.1 — biggest wins on asset-heavy pages with many small files and TLS (one handshake instead of six). Single large JSON API responses see modest gains.
• HTTP/3 vs HTTP/2 — largest on high-latency, lossy networks (mobile, emerging markets). Datacenter east-west traffic often ties because neither sees meaningful loss.
• TTFB unchanged — faster transport does not fix slow database queries or cold serverless starts. Profile origin before chasing protocol flags.
• Compression still matters — HPACK and QPACK (HTTP/3's header compression) help headers; Brotli/gzip on bodies remains separate.

Core Web Vitals tie-ins: multiplexing reduces queueing delay for render-blocking CSS/JS (see Core Web Vitals). HTTP/3 can improve LCP on mobile when image streams resume independently after packet loss. It does not replace image optimization or CDN caching policy.

Deployment checklist for operators

• Terminate at the edge first — enable HTTP/2 and HTTP/3 on your CDN or reverse proxy; origin can stay HTTP/1.1 behind private network if needed.
• Ensure TLS is modern — TLS 1.2 minimum, 1.3 preferred; valid certificate chain; OCSP stapling. HTTP/3 requires UDP/443 open on firewalls and load balancers.
• Disable broken middleboxes — some legacy proxies mishandle HTTP/2 cleartext upgrade; terminate TLS at edge and use HTTP/2 to origin.
• Watch QUIC CPU — high-QPS APIs on small VMs may need kernel TCP (HTTP/2) until QUIC builds are profiled.
• Do not concatenate assets blindly — HTTP/2 reduced the need for giant bundles, but HTTP/3 does not make 5 MB JS files free. Split by route; cache immutable hashed filenames aggressively via HTTP caching.
• Long-lived connections — WebSockets and SSE still use their own upgrade paths; HTTP/3 adoption for them is evolving (WebTransport over QUIC is the long-term direction).

Common misconceptions

• "HTTP/3 replaces REST" — same verbs, headers, and status codes; only framing and transport change.
• "Enable HTTP/2, skip HTTP/1.1" — keep HTTP/1.1 fallback for old clients and debugging with curl -v.
• "Server Push fixes performance" — largely abandoned; prefer preload hints and good cache headers.
• "QUIC is unencrypted UDP mayhem" — QUIC mandates TLS 1.3; it is not cleartext like raw DNS.
• "Multiplexing removes all blocking" — TCP HOL blocking remains on HTTP/2; only HTTP/3 addresses transport-level stalls per stream.

Practical summary

• HTTP/2 = binary frames + multiplexed streams + HPACK on TCP.
• HTTP/3 = same HTTP semantics on QUIC (UDP + TLS 1.3 + per-stream reliability).
• Enable both at CDN/proxy; measure mobile vs datacenter separately.
• Fix slow origins and caching before expecting protocol upgrades to rescue SLAs.
• Guard 0-RTT replay on state-changing endpoints with idempotency keys.

Related on Solana Garden: TCP congestion control, TLS and HTTPS, DNS resolution, HTTP caching, Explainers hub.