HTTP/3 and QUIC

HTTP/3 keeps HTTP's meaning and moves it onto a new transport called QUIC (RFC 9000). QUIC runs on UDP. It does the jobs TCP does, reliability, ordering and congestion control, but in user space and with different choices. Those choices are why HTTP/3 exists.

The big idea: recovery per stream

QUIC knows about streams. A lost packet only stalls the streams whose data it carried. The other streams keep delivering. That removes the transport-level head-of-line blocking that TCP causes. Compare it with HTTP/2 on TCP, where one lost packet holds back every stream.

Walking through it: the handshake count

A new TCP connection plus TLS 1.3 needs two round trips before the first request. QUIC carries the TLS 1.3 handshake inside its own handshake:

HTTP/2 over TCP + TLS 1.3:  1 RTT (TCP) + 1 RTT (TLS) + request
HTTP/3 over QUIC:           1 RTT (QUIC with TLS) + request
HTTP/3, resumed session:    0-RTT, request sent in the first flight

With a resumed session, 0-RTT lets the client send its request in the very first packet. It has the same replay caveats as TLS 0-RTT. See TLS for those.

Connection migration

A TCP connection is identified by its four values: source IP, source port, destination IP and destination port. When a phone moves from Wi-Fi to 5G, the IP changes, and every TCP connection dies. QUIC identifies connections by a connection ID instead. The connection survives the switch, so the request does not have to start again.

Encrypted transport headers

Almost everything in a QUIC packet is encrypted, including packet numbers and ACKs. Middleboxes such as NATs and firewalls cannot inspect or change those fields. That is why QUIC can change over time without waiting years for every router to update.

Why build on UDP rather than a new IP protocol? Because the internet's middleboxes reliably pass only TCP and UDP. UDP was the only practical way to ship a new transport.

Discovery and fallback

Browsers learn that a server speaks HTTP/3 from an Alt-Svc: h3=":443" response header or a DNS HTTPS record. They race QUIC against TCP, and fall back if UDP is blocked. As of 2025 to 2026, HTTP/3 carries a large share of browser traffic to big CDNs and to Google and Meta properties. Many internal service-to-service calls still use HTTP/1.1 or HTTP/2.

Common mistakes

• Blocking UDP on the firewall. HTTP/3 then fails silently, and clients fall back to TCP with extra latency.
• Assuming HTTP/3 is always faster. The gain is largest on lossy, long or mobile paths. On a clean datacenter link, the difference is small.
• Building your own reliability on UDP. If you need reliable delivery over UDP, use QUIC instead of inventing one.

Check yourself

• Why does one lost packet stall all streams on HTTP/2 but only one stream on HTTP/3? HTTP/2 runs on one TCP byte stream, which must be ordered. QUIC tracks loss and ordering per stream.
• A user switches from Wi-Fi to 5G mid-download. What does QUIC do? The connection ID stays the same, so the connection continues over the new IP address.

Key takeaways

• HTTP/3 runs on QUIC over UDP. QUIC recovers loss per stream, which removes transport-level head-of-line blocking.
• QUIC combines transport and TLS 1.3 setup in one round trip, and supports 0-RTT on resumption.
• Connection IDs let a connection survive a network change.
• Browsers fall back to HTTP/2 when UDP is blocked.

Further learning

For the handshake and encryption that QUIC carries, see TLS.

RFC 9114: HTTP/3 is the specification, with the protocol's details in one place.