HTTP/3 runs over QUIC on UDP and reduces one specific problem in HTTP/2 over TCP: transport-level head-of-line blocking. It does not isolate every stream from every delay. QUIC delivers each stream in order independently, while streams on one connection still share congestion control and connection-level flow control. IETF RFC 9000 Cloudflare engineer Alessandro Ghedini's QUIC analysis

What changes when a packet is lost

HTTP/2 can multiplex several requests over one TCP connection. TCP presents their data as one ordered byte stream. If bytes are missing, later bytes cannot be delivered to the application until the gap is repaired. A packet loss affecting one response can therefore delay other responses carried by that same TCP connection.

With HTTP/3, each request uses a QUIC stream. Imagine a page loading its HTML, stylesheet, and images at once. If part of one image stream is lost, that stream waits for its missing data; already available data on another stream does not have to wait for the image's byte order. That is the transport-level head-of-line blocking QUIC avoids. In his technical explanation, Cloudflare engineer Alessandro Ghedini also points out that the streams still share the connection's congestion state.

So “other streams continue without delay” is too strong. The connection has shared congestion control and connection-level flow control, either of which can limit transmission. Severe loss can reduce progress across the connection. QUIC's narrower benefit is that a missing byte in one stream does not by itself hold back ordered bytes in every other stream.

A first handshake and a resumed 0-RTT connection

QUIC integrates TLS 1.3 into connection setup. A first-time client normally completes a handshake round trip before it can send application data at the 1-RTT level. A returning client may be able to include 0-RTT early data in its first flight if it has resumption information and the server accepts it. This is conditional on prior state and server configuration; it is not a feature available on every connection.

Early data can be replayed across connections. TLS 1.3 therefore requires clients to send only data they consider safe to replay, and HTTP/3 requires replay mitigations when 0-RTT is used. RFC 8446, 0-RTT and Anti-Replay RFC 9114, Early Data

For example, a product-list read can often be designed to tolerate repetition, while creating an order, redeeming a one-time coupon, or charging a card can have side effects if repeated. Do not decide from the HTTP method name alone: an endpoint implemented as GET can still trigger side effects. Before enabling 0-RTT, assess whether the application action is safe to replay, how the server handles duplicates, and what happens when early data is rejected.

How a connection ID helps when the network changes

QUIC uses Connection IDs (CIDs) so a connection need not be identified only by its current IP addresses and ports. If a phone moves from Wi-Fi to cellular, the path may change; when the endpoints validate the new path and the server supports migration, the existing QUIC connection can continue. Treat this as a way to reduce reconnection work in supported circumstances, not a promise that a download can never be interrupted. Cloudflare's connection-migration explanation

A CID is not a fixed 64- or 128-bit number. RFC 9000 defines the length of a NEW_CONNECTION_ID frame's identifier as 1–20 bytes and also defines packet formats that can use a zero-length CID. Length and value depend on the connection and implementation. A CID does not automatically guarantee migration: path validation, server state and routing, and UDP reachability still matter.

What to check in a deployment

  • Compare HTTP/2 and HTTP/3 under recorded packet loss, round-trip time, device, and request-size conditions. A result from one network is not a universal performance result.
  • UDP may be blocked or perform poorly on some networks. Test that clients can recover through a supported alternative when HTTP/3 cannot be established.
  • Independent streams do not remove shared congestion control. Avoid saying that all effects of loss are confined to one stream.
  • Treat 0-RTT as a security decision as well as a latency option. Include replay consequences and duplicate-request handling in the design review.

Sources