HTTP/2 and HTTP/3

Version comparison

HTTP/2 multiplexing and frames

One TCP connection carries many independent streams, each with an odd client-initiated id, and each stream is a sequence of frames.

                  one TCP + TLS connection
 ┌──────────────────────────────────────────────────────┐
 │ stream 1  HEADERS ──── DATA ──── DATA ── END_STREAM   │  /index.html
 │ stream 3      HEADERS ── DATA ── END_STREAM           │  /app.css
 │ stream 5  HEADERS ─────── DATA ──────── END_STREAM    │  /app.js
 └──────────────────────────────────────────────────────┘
   frames from different streams interleave freely

Because one request can be cancelled with RST_STREAM while others continue, an aborted fetch no longer wastes a whole connection. That same cheapness was the basis of the HTTP/2 Rapid Reset denial-of-service class, which servers now mitigate by rate-limiting resets.

Pseudo-headers and what disappears

HTTP/2 and /3 replace the request line with four pseudo-headers, all lowercase and all before the regular fields.

Removed or forbidden: Connection, Keep-Alive, Transfer-Encoding, Upgrade, and Proxy-Connection are all connection-specific and are protocol errors in HTTP/2 and /3. There is no reason phrase, so HTTP/2 404 has no "Not Found" text on the wire.

HPACK and QPACK compress headers with a static table of 61 common name-value pairs plus a dynamic table shared across the connection, which is why repeated cookies and user agents cost almost nothing after the first request. HPACK's shared dynamic table is what made the CRIME-style HEIST concerns apply to headers, and QPACK reworks it to avoid QUIC head-of-line issues.

What HTTP/2 changed about optimization

Practices that were correct for HTTP/1.1 became counterproductive.

What still matters at every version: fewer bytes, correct caching, content-hashed filenames, and preload hints. And one thing gets worse, not better: because everything shares one TCP connection, a single packet loss stalls every stream until TCP recovers. That is precisely the problem HTTP/3 exists to solve.

QUIC and HTTP/3

QUIC is a transport built on UDP that folds in what TCP plus TLS did separately.

Because QUIC lives in userspace over UDP, it deploys without kernel changes, and it fails where UDP 443 is blocked. Clients handle that by racing QUIC against TCP and falling back, so a blocked network shows up as a latency cost, not an error.

Negotiation and discovery

HTTP/2 over TLS   ALPN offers "h2", server selects it in the handshake
HTTP/2 cleartext  h2c via Upgrade, no browser supports it
HTTP/3            advertised on an h2 or h1 response:

HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=86400

or resolved directly, skipping the first round trip:

$ dig HTTPS example.com +short
1 . alpn="h3,h2" ipv4hint=203.0.113.9

A browser's first request to a new origin cannot be HTTP/3, because it does not yet know QUIC is available. It learns from Alt-Svc or from the DNS HTTPS record and upgrades subsequent connections.

Verifying which version you got

curl -sI --http2 https://example.com | head -1        # HTTP/2 200
curl -sI --http3 https://example.com | head -1        # HTTP/3 200
curl -s -o /dev/null -w '%{http_version}\n' https://example.com
curl --http1.1 -sI https://example.com | head -1      # force downgrade
curl -sI https://example.com | grep -i alt-svc

# confirm ALPN selection in the handshake itself
openssl s_client -connect example.com:443 -servername example.com \
  -alpn h2 </dev/null 2>/dev/null | grep -i 'ALPN protocol'

nghttp -nv https://example.com                        # frame-level trace
dig HTTPS example.com +short                          # HTTPS/SVCB record