HTTP/3 & QUIC

HTTP/3 is the third major version of the web's protocol, and its defining change is the layer beneath it: instead of running over TCP, it runs over QUIC, a new transport protocol built on UDP. This swap fixes performance problems that were baked into TCP and impossible to solve without replacing it — most importantly head-of-line blocking, faster connection setup, and the ability to survive a network change (Wi-Fi to cellular) without dropping the connection.

For most developers HTTP/3 is invisible — browsers, CDNs, and servers negotiate it automatically, and your application code doesn't change. But understanding why it exists explains a lot about web performance, and knowing its properties helps when you're tuning delivery, debugging latency, or deciding whether to enable it. This page covers what QUIC changes and what it means in practice.

TL;DR

Quick Example

Servers advertise HTTP/3 availability with an Alt-Svc header over an existing HTTP/2 connection; the browser then upgrades future requests to HTTP/3:

You verify it in browser dev tools (the "Protocol" column shows h3) or with a tool like curl --http3. No application code changes — the upgrade is negotiated at the transport layer.

Core Concepts

The Problem With TCP

HTTP/2 was a big step — it multiplexed many requests over one connection instead of opening several. But it still ran over TCP, which delivers a single ordered byte stream. If one packet is lost, TCP holds back everything after it until the retransmission arrives — even data for unrelated HTTP/2 streams. This is TCP head-of-line blocking: HTTP/2 removed application-layer HoL blocking but the transport underneath reintroduced it. On lossy networks (mobile, congested Wi-Fi) this hurts. You can't fix it in HTTP/2 because the limitation lives in TCP itself — hence a new transport.

QUIC: Independent Streams Over UDP

QUIC is built on UDP (which has no ordering guarantee) and implements its own reliable, multiplexed streams on top. The key difference: QUIC's streams are independent. A lost packet only stalls the stream it belongs to; other streams keep flowing. This eliminates transport-layer head-of-line blocking — the core win. QUIC also builds in loss recovery, congestion control, and flow control that were TCP's job, but redesigned and evolvable in user space rather than frozen in the OS kernel.

Faster Handshakes

Establishing a secure connection over TCP+TLS takes multiple round trips: the TCP handshake, then the TLS handshake. QUIC combines transport and cryptographic setup into one handshake — typically 1-RTT, and 0-RTT when resuming a prior connection (sending application data in the very first packet). On high-latency links, shaving round trips off connection setup is a noticeable speedup, especially for the many short connections the web makes.

Connection Migration

A TCP connection is identified by the four-tuple of IPs and ports — change your IP (walk out of Wi-Fi range onto cellular) and the connection breaks; everything must reconnect. QUIC identifies a connection by a connection ID independent of IP, so the connection migrates across network changes seamlessly. For mobile users switching networks constantly, this means downloads and calls don't drop.

Always Encrypted

QUIC integrates TLS 1.3 into the transport — encryption isn't optional, and even much of the transport metadata is protected. There is no plaintext QUIC. This improves privacy and also prevents middleboxes from ossifying the protocol the way they did with TCP.

What Changes in Practice

The wins are largest exactly where the old web struggled: mobile, lossy, and high-latency connections. On a fast, stable wired link the difference is smaller.

Best Practices

Enable It at the Edge

The simplest path to HTTP/3 is a CDN or reverse proxy that supports it (CDN, Nginx, Cloudflare, etc.) — turn it on there and clients upgrade automatically. Your origin and application code don't need to change. Most sites get HTTP/3 by flipping a provider setting, not by rewriting anything.

Keep the Alt-Svc Advertisement

HTTP/3 discovery relies on the Alt-Svc header advertised over an existing connection. Ensure it's present and its ma (max-age) is reasonable so clients remember to use HTTP/3 on return visits.

Don't Block UDP

HTTP/3 needs UDP (typically port 443). Some restrictive networks and firewalls block or throttle UDP, forcing fallback to HTTP/2. If you control network policy, allow QUIC/UDP; if you're debugging "why no h3?", suspect UDP filtering.

Rely on Graceful Fallback

HTTP/3 is designed to fall back cleanly to HTTP/2 over TCP when QUIC isn't available. Don't build anything that requires HTTP/3 — treat it as an automatic performance enhancement, with HTTP/2 as the guaranteed floor.

Measure Real-User Impact

The gains show up in real-world tail latency on mobile and lossy networks, not necessarily in a fast office benchmark. Measure with real-user monitoring across networks to see HTTP/3's effect, and confirm the h3 protocol is actually being used.

Common Mistakes

Assuming HTTP/3 Needs Code Changes

Expecting Big Gains on Fast, Stable Links

HTTP/3's advantages — no HoL blocking, connection migration, faster handshakes — matter most on lossy, mobile, or high-latency networks. On a fast wired connection with little loss, the improvement over HTTP/2 is modest. Set expectations by your users' real network conditions.

Forgetting UDP Can Be Blocked

If HTTP/3 isn't kicking in, a common cause is a firewall or network blocking QUIC's UDP traffic, silently forcing HTTP/2 fallback. Check UDP/443 reachability before assuming a config bug.

FAQ

What's the difference between HTTP/2 and HTTP/3?

HTTP/2 multiplexes requests over one connection but runs on TCP, which reintroduces head-of-line blocking (one lost packet stalls all streams) and needs multiple round trips to connect. HTTP/3 runs on QUIC over UDP, with independent streams (a loss stalls only its own stream), a combined faster handshake, connection migration across network changes, and mandatory encryption. The semantics of HTTP are the same; the transport underneath is completely different.

What is QUIC?

QUIC is a transport protocol built on UDP that provides reliable, multiplexed, encrypted streams — the things TCP+TLS provided, but redesigned. Its key improvements are independent streams (no transport-layer head-of-line blocking), a combined transport+TLS handshake (fewer round trips), connection migration via connection IDs, and built-in TLS 1.3. HTTP/3 is HTTP mapped onto QUIC.

Do I need to change my code to use HTTP/3?

No. HTTP/3 is a transport-layer upgrade negotiated automatically between client and server; HTTP semantics (methods, headers, status codes) are unchanged. You enable it on your server or CDN, advertise it via Alt-Svc, and browsers upgrade on their own — falling back to HTTP/2 when QUIC isn't available. Application code stays the same.

Why does HTTP/3 use UDP instead of TCP?

Because TCP's limitations (head-of-line blocking, slow handshakes, connection drops on IP change) are baked into the protocol and can't be fixed without replacing it — and TCP is effectively frozen by OS kernels and middleboxes. UDP is a minimal base that lets QUIC implement its own evolvable, independent-stream transport in user space, with encryption built in. UDP isn't "less reliable" here — QUIC adds reliability on top, per stream.

Is HTTP/3 always faster?

Not always — it depends on the network. Its biggest wins (no head-of-line blocking, connection migration, fewer handshake round trips) show up on lossy, mobile, or high-latency connections, where they can meaningfully cut tail latency. On a fast, stable, low-loss wired link, the improvement over HTTP/2 is smaller. It's a clear win to enable, but measure the impact against your users' real conditions.

Related Topics

References