HTTP/1 vs HTTP/2 vs HTTP/3

Picking HTTP/2 over HTTP/1 gave an instant 2× speedup on a typical page load with no app code changes. HTTP/3 fixes the one failure mode HTTP/2 still had. In interviews: naming the specific wins of each version shows you understand the transport, not just "we'll use REST."

• HTTP/1.1 (1999) — one request at a time per TCP connection; browsers work around by opening 6 connections.
• HTTP/2 (2015) — many requests concurrently over one connection (multiplexing) + header compression + server push.
• HTTP/3 (2021) — same as HTTP/2 but over QUIC/UDP, eliminating head-of-line blocking.

One request sent, one response returned, repeat. To parallelize, browsers open 6 TCP connections per hostname. Each connection needs its own handshake (3-way TCP + TLS = ~200ms at typical latencies). Modern pages fetch 50–100 resources; even with 6 connections, you're blocked on "the 7th request can't start until slot 1 is free."

Workaround: domain sharding. Serve assets from 4 subdomains so the browser opens 24 connections. Common in 2010; now dead.

One TCP connection. Many streams multiplexed inside it. Each stream carries one request + response. Requests go out in parallel without waiting.

• Multiplexing. 100 requests over one connection, not 6.
• HPACK header compression. Repeated headers (cookies, UA) compressed to a few bytes each. Saves 50–90% header bytes.
• Stream prioritization. CSS blocking render gets priority over a below-fold image.
• Server push. Server sends resources the client will need before the client asks. Cool in theory, effectively abandoned in practice — caching issues made it a net loss.

Adoption: ~95% of top-1M sites support HTTP/2 today. It's the default. You should never deploy HTTP/1.1-only in 2025.

HTTP/3 runs HTTP semantics on QUIC over UDP. QUIC implements its own reliable delivery, per-stream — a lost packet only blocks its own stream. The 47 other in-flight streams keep flowing.

Other wins:

• 0-RTT resumption. Returning visitors send the first HTTP request before the handshake completes. Saves a full RTT — 100ms+ on mobile.
• Connection migration. QUIC connections are identified by a connection ID, not IP. Switch from WiFi to cellular mid-video — the connection survives.
• Encrypted transport by default. QUIC bundles TLS 1.3. No plaintext HTTP/3 exists.

Cost: UDP is often rate-limited or blocked on enterprise networks. HTTP/3 clients fall back to HTTP/2. This is fine — you get the win for most users and degrade gracefully for the rest.

YouTube/Netflix serve media over HTTP/3 for mobile users. Video conferencing uses HTTP/3 for signaling. Live streaming uses HTTP/3 for low-latency ingest. E-commerce benefits directly from HTTP/2 multiplexing of product-image loads.