How HTTP/3 changed the web (and why you didn't notice)
HTTP/3 quietly replaced TCP with UDP and rewrote the assumptions of decades-old web infrastructure. Here's what changed, why it's faster, and why your browser is probably already using it.
Every popular browser ships HTTP/3 support. Cloudflare, Google, Meta, and most major CDNs serve over HTTP/3 by default. Roughly 30% of global web traffic in 2026 runs on it. Yet most people have never heard of it.
That's the trick of good infrastructure: it changes everything underneath without changing what you see. Here's what HTTP/3 is, what it actually changed, and why it took 25 years for the web to finally fix some old problems.
The two-line summary
HTTP/3 is HTTP delivered over QUIC, a new transport protocol that runs on UDP. It replaces the TCP+TLS combination that HTTP/1.1 and HTTP/2 use, fixing a class of problems baked into TCP since the 1980s.
The wins are in latency, packet loss handling, and connection migration. The cost was a decade of engineering work to get there.
A quick lineage
| Version | Year (RFC) | Transport | Key features |
|---|---|---|---|
| HTTP/1.0 | 1996 | TCP | One request, one connection, then close |
| HTTP/1.1 | 1997 | TCP | Keep-alive, pipelining (rarely worked), chunked |
| HTTP/2 | 2015 | TCP + TLS | Multiplexed streams, header compression, push |
| HTTP/3 | 2022 | QUIC over UDP | All of HTTP/2 plus 0-RTT, no head-of-line blocking, connection migration |
Each version aimed at problems the previous version surfaced. HTTP/3 is the first to require a transport-layer change.
What was wrong with HTTP/2 over TCP
HTTP/2 introduced multiplexing: many requests share one connection, and responses interleave so a slow file doesn't block a fast one — at the HTTP layer. Big improvement over HTTP/1.1's "one slow image stalls the whole queue."
But underneath HTTP/2 ran TCP, which doesn't know about multiple HTTP streams. To TCP it's all one byte stream. If one packet in that stream gets lost:
- TCP must wait for the retransmission before delivering the bytes after it (because TCP is in-order).
- All HTTP/2 streams sharing the connection are stalled on that one missing packet.
- Multiplexing benefits collapse the moment packet loss happens.
This is head-of-line blocking at the transport layer. HTTP/2 fixed it at the application layer; TCP brought it back at the transport layer.
QUIC fixes that.
What QUIC does
QUIC ("Quick UDP Internet Connections") is a new transport protocol designed at Google in the early 2010s and standardized as RFC 9000 in 2021. It runs on UDP at the network layer but reimplements reliability, ordering, and congestion control on top — per-stream, not per-connection.
Key changes:
Per-stream loss handling
Each HTTP request gets its own QUIC stream. A lost packet on stream 3 stalls stream 3, but streams 1, 2, 4, 5 continue. Multiplexing actually works under packet loss.
TLS is built in
In HTTP/2 over TCP, you do a TCP handshake (1 RTT), then a TLS handshake (1–2 RTTs), then HTTP. That's 2–3 round trips before any data flows.
QUIC merges the handshake. TLS 1.3 negotiation happens within the QUIC handshake. First request data can ride along — 0-RTT for resumed connections, or 1-RTT for new ones. Massive improvement on cold-start latency.
Connection migration
Most TCP connections die when your IP changes — you switch from Wi-Fi to cellular, your phone changes networks. The TCP four-tuple (local IP, local port, remote IP, remote port) is part of the connection identity.
QUIC connections are identified by a connection ID that's independent of IP/port. When your IP changes, the connection survives. That's why a video call on QUIC can move from Wi-Fi to cellular without reconnecting — something HTTP/2 over TCP couldn't manage.
Encryption everywhere
QUIC encrypts not just the payload (like TLS over TCP does) but also most of the transport headers. ISPs and middleboxes can't see TCP-level metadata to optimize or interfere. This trades some debuggability for privacy and resistance to "ossification" — the slow death where new TCP options stop working because middleboxes mangle them.
Why it took so long
QUIC needed years of work because:
- TCP is everywhere. Decades of network gear (routers, firewalls, CDNs) assumed TCP. QUIC needed to demonstrate it could compete on every dimension before adoption.
- UDP is sometimes blocked. Restrictive networks (corporate, hotel Wi-Fi) blocked unfamiliar UDP traffic. Browsers fall back to HTTP/2 over TCP when QUIC can't get through.
- Standardization is slow. Google ran "gQUIC" in production for years to learn what worked, then helped the IETF standardize what eventually became RFC 9000.
- Operating system kernels are slow to change. TCP is implemented in the kernel; QUIC is implemented in userspace. This was deliberate (so it can iterate faster) but creates new performance challenges.
What it changed for users
In practical terms:
- Connections feel snappier, especially over high-latency or lossy networks (cellular, distant servers).
- Mobile transitions between networks don't break video streams or downloads.
- HTTP/3 is automatic — Chrome, Firefox, Safari, Edge all support it. They negotiate it during the first request via the
Alt-Svcheader. - CDNs serve it transparently. Cloudflare, Google, Fastly all default to HTTP/3 where supported.
You don't choose HTTP/3. You're either using it or you're not, depending on whether the server supports it and your network allows UDP/443.
How to tell which version you're using
In any modern browser, open DevTools → Network → check the "Protocol" column. You'll see h3, h2, or http/1.1 per request.
For a quick command-line test:
curl -I --http3 https://example.com
If it returns headers, you're using HTTP/3. (Requires curl built with HTTP/3 support — check curl -V for "HTTP3".)
Why some sites still don't have HTTP/3
A short list:
- Sites running on origin servers that haven't been updated. HTTP/3 needs server software that supports it (nginx 1.25+, Apache 2.4+, Caddy, IIS, modern Node).
- Sites behind hardware load balancers that don't speak QUIC.
- Sites on CDNs that haven't enabled HTTP/3 (most have, by default).
- Sites whose middlebox stack mangles UDP/443 traffic.
For most public sites, "no HTTP/3 support" is a slowly-disappearing artifact.
Quick FAQ
Does HTTP/3 use port 443 too? Yes — UDP port 443. The port-number is shared with HTTPS over TCP, but the transport is different.
Does HTTP/3 require HTTPS? Yes. QUIC has TLS built in; there's no plaintext HTTP/3.
What's the difference between HTTP/3 and QUIC? QUIC is the transport protocol. HTTP/3 is HTTP-over-QUIC. You could in principle run other protocols on QUIC; HTTP is the first major one.
Is HTTP/3 faster everywhere? Almost everywhere. The benefit is largest on high-latency or lossy connections — mobile, distant servers, Wi-Fi at coffee shops. On a fast wired connection to a nearby server, HTTP/2 and HTTP/3 perform similarly.
Does HTTP/3 fix everything? No. The biggest remaining bottleneck for web performance is now usually the application — large bundles, render-blocking scripts, slow-rendering UIs. HTTP/3 fixed the transport. The rest is still in your code.
TL;DR
- HTTP/3 = HTTP over QUIC, which runs on UDP.
- Fixes head-of-line blocking, merges TCP and TLS handshakes, supports connection migration.
- About 30% of web traffic uses it in 2026, growing.
- Browsers handle the choice automatically — you're already using it on most major sites.
The web's been quietly running on a different transport for years. Most people haven't noticed because the only sign was that things felt a bit faster.