HTTP/3 and QUIC, Explained — What Just Became a Standard Actually Changes

It's official: HTTP/3 is now a Proposed Standard — RFC 9114, published this month — joining QUIC itself, which was standardized as RFC 9000 in May of last year. In practice, HTTP/3 has been quietly carrying a meaningful slice of web traffic for a while; Chrome and Firefox speak it, and major CDNs serve it. But the RFC stamp marks the moment it stops being "that experimental Google thing" and becomes simply the third major version of the protocol the web runs on.

What actually changed under the hood is more interesting than most protocol bumps — HTTP/3 doesn't just tweak HTTP, it replaces the transport layer underneath it. Here's what that means in concrete terms, and one implication for monitoring that almost everyone misses.

The big move: TCP is out, UDP (via QUIC) is in

Every prior HTTP version — 1.0, 1.1, 2 — runs over TCP. HTTP/3 runs over QUIC, a transport protocol built on top of UDP. That sounds alarming ("isn't UDP the unreliable one?") until you see the design: QUIC reimplements the guarantees you want from TCP — reliable delivery, ordering, congestion control — in user space, on top of UDP's bare datagrams, where it can do them better and evolve them without waiting a decade for operating system kernels and middleboxes to catch up.

Why go to that trouble? Because TCP had accumulated problems that couldn't be fixed from inside:

• Head-of-line blocking at the transport layer. HTTP/2 multiplexes many streams over one TCP connection — but TCP doesn't know about streams. Lose one packet and TCP halts delivery of everything behind it until the retransmit arrives, stalling every stream to preserve an ordering guarantee that only one stream needed. QUIC makes streams first-class at the transport layer: a lost packet stalls only the stream it belonged to. This is the headline fix, and it matters most exactly where the modern web hurts — lossy Wi-Fi and cellular connections.
• Slow handshakes. A classic HTTPS connection stacks a TCP handshake and then a TLS handshake before the first byte of HTTP — two-plus round trips of pure ceremony. QUIC merges transport and cryptographic setup into a single handshake: one round trip to a fully encrypted connection, and zero (0-RTT) when resuming a connection to a server you've spoken to recently.
• Ossification. Because middleboxes across the internet inspect and "help with" TCP, changing TCP in practice became nearly impossible. QUIC encrypts almost all of its own transport metadata, which keeps middleboxes' hands off and preserves the ability to evolve the protocol.

TLS 1.3 isn't bolted on — it's load-bearing

With HTTP/1.1 and HTTP/2, encryption is a layer you add. With HTTP/3, there is no unencrypted variant and no version negotiation dance: TLS 1.3 is built into QUIC's handshake itself. The security consequences are tidy — no downgrade to older TLS versions, modern cipher suites only, encrypted handshake metadata — but the operational consequence is the one to internalize: you cannot deploy HTTP/3 without a working TLS 1.3 setup, and certificate problems surface inside the transport handshake rather than as a separate layer you can debug independently.

Connection migration: the mobile trick

One genuinely new capability: TCP connections are defined by the four-tuple of source/destination IP and port — change any of them (walk out of Wi-Fi range onto cellular) and every connection dies, to be rebuilt from scratch. QUIC identifies connections by a connection ID instead. When your phone's network changes, the same logical connection continues over the new path — no re-handshake, no dropped transfer. For anyone building for mobile users, this is the sleeper feature of the whole stack.

How clients find HTTP/3: Alt-Svc

Here's a subtlety with real operational consequences: a browser can't simply "try HTTP/3" against your domain — it discovers it. The current mechanism is the Alt-Svc response header, delivered over a normal HTTP/1.1 or HTTP/2 connection:

alt-svc: h3=":443"; ma=86400

Translation: "this origin also speaks HTTP/3 on UDP port 443; remember that for 24 hours." The first visit happens over TCP; subsequent requests can upgrade to QUIC. Two implications follow. First, your TCP stack isn't going anywhere — it's the front door through which HTTP/3 is advertised. Second, HTTP/3 support can silently break — a dropped header, a blocked UDP port — and browsers will simply fall back to HTTP/2 without anyone seeing an error.

State of support, mid-2022

Where things stand right now:

• Browsers: Chrome, Edge and Firefox ship HTTP/3 enabled by default; Safari's support is still partial.
• CDNs and servers: Cloudflare serves HTTP/3 at the flip of a switch, and LiteSpeed supports it natively — if you're behind either, you may be serving h3 already. nginx support is experimental (a separate development branch, not mainline), and Apache has no production support yet. For most sites, the pragmatic path to HTTP/3 in 2022 is a CDN in front, not a server upgrade.
• The network: QUIC needs UDP port 443 open end to end. Some corporate and institutional networks block or throttle it — which is fine, because fallback to TCP is built into the discovery model, but it means your HTTP/3 coverage is probabilistic, not universal.

Quick check on whether your site advertises it:

curl -sI https://example.com | grep -i alt-svc

The monitoring blind spot

Now the part that matters for anyone responsible for uptime: your HTTP/3 path can fail independently of your site being "up" — and most monitoring will never notice. Nearly all monitoring tools (and curl as commonly built) negotiate HTTP/1.1 or HTTP/2 over TCP. If a firewall change blocks UDP 443, a CDN toggle flips off, or the Alt-Svc header disappears in a config refactor, every conventional check stays green — while a chunk of your real users silently lose the fast path and fall back to TCP, or in the worst cases eat a timeout-then-retry delay first.

The inverse blind spot exists too: as HTTP/3 adoption grows, a team could someday have most traffic on h3 while their monitoring exercises only the TCP path — a check that's technically green and increasingly unrepresentative. Whatever tool you use, the near-term checklist is the same: verify the Alt-Svc header is present (a simple header assertion covers this today), confirm UDP 443 after firewall changes, and remember that protocol-level performance differences won't show up in a check that speaks a different protocol than your users do.

Monitor the site you actually serve

HTTP/3 is a genuine improvement — faster handshakes, no more transport-layer head-of-line blocking, connections that survive network switches — and with RFC 9114 published, the "should we take it seriously" question is settled. The deployment story in mid-2022 is CDN-first, and the monitoring story is: know which protocol your checks exercise, and assert on the headers that advertise the rest.

CompleteStatus HTTP checks let you assert on response headers — including Alt-Svc — so an accidentally-dropped h3 advertisement becomes an alert, alongside the response-time tracking that shows what your protocol stack is actually delivering. It's the same philosophy we laid out in ping vs HTTP checks: monitor at the layer where the truth lives. Start free, add a header assertion, and know the day your fast path quietly disappears.