How QUIC and HTTP/3 work: streams, connection IDs, 0-RTT and fallback explained

In short

HTTP/3 is HTTP carried over QUIC instead of TCP. QUIC runs on UDP, builds in TLS 1.3, and splits a connection into independent streams, so one lost packet no longer stalls every request on the connection. It can also keep a connection alive when your network address changes. The catch is that the gains depend on your network and your tuning, and that UDP is sometimes blocked, in which case clients fall back to HTTP/2 over TCP.

Why a new protocol at all

For about two decades, web traffic rode on TCP. TCP delivers one ordered stream of bytes, which is exactly what you want for a single download and exactly what hurts when you multiplex many requests on one connection. HTTP/2 put many requests on one TCP connection to avoid opening several. The price is that TCP does not know about those requests. If one packet is lost or arrives out of order, TCP holds back everything behind it until the gap is filled, including data for requests the loss did not touch. This is called head-of-line blocking.

The IETF's HTTP/3 specification, RFC 9114 (June 2022, Standards Track), states the contrast directly: in HTTP/3 "one stream that is blocked or suffers packet loss does not prevent progress on other streams," whereas on HTTP/2 over TCP a single lost or reordered packet can stall all active transactions. To get that behaviour the designers moved the stream logic down into the transport, which is what QUIC is.

The layers: HTTP/3, QUIC, UDP

Think of three layers.

1. UDP at the bottom. QUIC packets travel inside UDP datagrams. UDP gives no ordering or reliability, which is why QUIC can build its own.
2. QUIC (RFC 9000, May 2021). The abstract says it defines the core of the QUIC transport protocol: flow-controlled streams, low-latency connection establishment, and network path migration. It also integrates TLS 1.3, so encryption is not an optional add-on. The handshake, as RFC 9000 puts it, combines negotiation of cryptographic and transport parameters.
3. HTTP/3 on top. RFC 9114 maps HTTP semantics onto QUIC. It borrows heavily from HTTP/2's design, but swaps the header compression scheme HPACK for QPACK, because HPACK assumes in-order delivery, which QUIC does not guarantee across streams.

Streams that really are independent

QUIC supports bidirectional streams, where both ends can send, and unidirectional streams, where only one end sends. RFC 9000 is explicit that "QUIC does not provide any means of ensuring ordering between bytes on different streams." Each stream is ordered inside itself, but streams do not wait for each other.

Practically, if a lost packet carried part of an image, only the stream for that image waits for the retransmission. The script and stylesheet streams keep delivering. On a clean, fast network you will rarely notice. On a lossy mobile link you can.

Connection IDs and migration

A TCP connection is identified by the addresses and ports at both ends. When your phone moves from Wi-Fi to mobile data, that tuple changes and the connection breaks. QUIC identifies connections with connection IDs, and RFC 9000 says connection migration "uses connection identifiers to allow connections to transfer to a new network path". It also lets a connection continue after address changes such as NAT rebinding. In this version of the specification, only clients can migrate.

Delivery Hero, which we covered in HTTP/3 in production: an 18-market test, listed NAT timeout connection churn among the QUIC operational issues that get little attention, according to the abstract of its P99 CONF talk. The spec gives you the tools to deal with idle connections: RFC 9000 has an idle timeout section, and notes that applications can keep a connection from silently closing by generating PING frames or requesting other frames before the timeout.

Discovery and fallback

A browser does not know a server speaks HTTP/3 until told. An origin advertises it with the Alt-Svc response header (or the HTTP/2 ALTSVC frame) using the "h3" token; the RFC's example is Alt-Svc: h3=":50781", which means HTTP/3 on UDP port 50781. A client that sees this may attempt a QUIC connection to the indicated host and port.

If that fails, for example because a network blocks UDP, RFC 9114 says clients should attempt the TCP-based versions of HTTP. This is why rolling out HTTP/3 does not lock anyone out: in the Delivery Hero case reported by The Register, about 95% of users moved to HTTP/3, and the rest, largely on networks that block UDP, stayed on HTTP/2.

Loss detection and congestion control

QUIC does its own loss detection and congestion control, described in RFC 9002 (May 2021, by J. Iyengar and I. Swett). The RFC specifies a sender-side congestion controller similar to TCP NewReno, but does not forbid others. Senders may choose a different algorithm, such as CUBIC, provided they follow the congestion control guidelines in RFC 8085.

Some detail on how loss is declared: the recommended initial packet reordering threshold is 3, and implementations should not go below 3, which keeps behaviour close to TCP. A time threshold can also declare loss, with a recommended RTT multiplier of 9/8 and a 1 ms timer granularity. A probe timeout firing does not by itself mean a packet was lost; RFC 9002 states that "A PTO timer expiration event does not indicate packet loss."

Why this matters: congestion control is chosen by whoever runs the sender, so two HTTP/3 servers can behave differently on the same lossy network. The Register's report of the Delivery Hero talk says the team blames Cloudflare's use of the Cubic algorithm for remaining latency in a high-loss market and saw no such problem with servers using BBR. That is one account of one deployment, not a general finding, and we have not confirmed it with Cloudflare.

0-RTT and its replay risk

QUIC can resume a connection and send application data before the handshake finishes, called 0-RTT, by reusing parameters from an earlier connection. RFC 9001 (May 2021, M. Thomson and S. Turner) warns that "This application data can be replayed by an attacker," so 0-RTT must not carry requests that would cause harm if repeated. In practice, this means servers should accept 0-RTT only for safe requests such as reads.

0-RTT saves a round trip, but only if the client can use it early. The Delivery Hero abstract notes that on Android, Cronet's initialization latency, about 800 ms at p90, reduces the benefit of 0-RTT.

Turning HTTP/3 on

If you use a CDN, this may be a setting. Cloudflare's documentation says HTTP/3 is available on its Free, Pro, Business and Enterprise plans, requires an SSL certificate on its edge network, and is enabled in the dashboard under Speed, Settings, Protocol Optimization, or by an API PATCH of the http3 setting to "on". The page states the setting covers the connection between users and Cloudflare, and that HTTP/3 to the origin is not supported yet.

To check what a site serves, look for the alt-svc header in a response, or use your browser's network panel, which shows the protocol used per request as h3. Firewall rules matter too: HTTP/3 needs UDP to reach the server, typically on the port in the Alt-Svc header.

How to test it on your own traffic

The Delivery Hero example is a useful template, because its abstract describes mixed results. HTTP/3 reportedly improved some metrics (up to 17% faster p90 response time, 48% fewer network-level failures) but lowered throughput by 4% or more in several of 18 markets. If you plan a rollout:

1. Run an A/B test, not a switch-over, so HTTP/2 stays as your baseline.
2. Segment by market or network type; an average can hide a region where things got worse.
3. Track more than latency: failures, throughput, and the share of users who fall back to HTTP/2.
4. Watch client start-up cost, especially on mobile where the network library may add its own delay.
5. Treat 0-RTT as an opt-in for safe requests only.

Common questions

Is HTTP/3 always faster? No. The protocol removes a specific problem, TCP head-of-line blocking, and adds others, such as UDP being blocked or rate-limited on some networks. Results depend on loss, latency, and implementation.

Is it more secure? QUIC always encrypts with TLS 1.3, so the transport is encrypted by design, but the usual application risks stay. 0-RTT adds a replay consideration.

Does it replace HTTP/2? Not yet. Clients fall back to TCP-based HTTP, so servers generally keep supporting HTTP/2 alongside HTTP/3.

Sources

• IETF RFC 9114: HTTP/3
• IETF RFC 9000: QUIC, a UDP-Based Multiplexed and Secure Transport
• IETF RFC 9001: Using TLS to Secure QUIC
• IETF RFC 9002: QUIC Loss Detection and Congestion Control
• Cloudflare documentation: HTTP/3
• P99 CONF 2026: HTTP/3 in Production: What the Numbers Actually Say
• The Register: HTTP/3 is faster with some work and help from Cloudflare