QUIC and HTTP/3: how the UDP-based transport works

QUIC is a transport protocol that runs over UDP and does the work of TCP and TLS combined: reliable delivery, congestion control and encryption with TLS 1.3. HTTP/3 is the version of HTTP that runs on QUIC.

The IETF published QUIC as RFC 9000 in 2021 and HTTP/3 as RFC 9114 in 2022, building on a protocol Google first deployed. The name is not an acronym.

HTTP/3 keeps the same methods, status codes and headers as HTTP/1.1 and HTTP/2, so applications rarely need to change. The difference is in how the bytes cross the network.

HTTP/2 multiplexes many requests as streams over one TCP connection. TCP delivers bytes strictly in order, so when one packet is lost, every stream waits for the retransmission, even streams whose data already arrived.

QUIC knows about streams. It tracks each stream's data separately, so a lost packet only delays the streams that had data in it. HTTP/3 also replaces HTTP/2's HPACK header compression with QPACK, because HPACK depends on in-order delivery.

The handshake is shorter too. A new HTTPS connection over TCP needs one round trip for TCP and one for TLS 1.3 before the request can go out, or two for TLS 1.2. QUIC combines its transport and TLS handshakes, so a new connection is ready after one round trip.

Changing TCP itself would be slow, because TCP is built into operating system kernels and many network devices make assumptions about its headers. QUIC runs in user space, inside the browser or server, and encrypts most of its own headers so network devices cannot come to depend on them.

A client that has connected to a server before can reuse keys from that session to send its first request in its first packets. This is 0-RTT (zero round-trip time) resumption, and it removes the handshake delay for repeat visits.

0-RTT data has no protection against replay. An attacker who records those first packets can send them to the server again, and the server may process the request twice. TLS 1.3 over TCP has the same feature and the same risk.

Servers should accept early data only for requests that are safe to repeat, such as a GET with no side effects. Payments and other state changes should wait for the full handshake. RFC 8470 defines the Early-Data header and the 425 Too Early status, so a server can ask the client to retry after the handshake completes.

A TCP connection is identified by the IP addresses and ports at both ends. When a phone moves from Wi-Fi to mobile data, its address changes and every TCP connection breaks, so the browser has to start over.

QUIC identifies connections with connection IDs carried in each packet. After the client's address changes, it keeps sending with a valid connection ID, the endpoints check the new path, and the connection continues. The client switches to fresh connection IDs on the new path so an observer cannot easily link the old and new addresses.

Migration needs support at both ends and in between. A load balancer in front of QUIC servers has to route packets by connection ID rather than by address. Otherwise, migrated packets can reach a server that knows nothing about the connection.

A browser cannot tell from a URL that a server speaks QUIC, so first contact usually happens over TCP with HTTP/2. The server advertises HTTP/3 in an Alt-Svc response header, such as Alt-Svc: h3=":443"; ma=86400, and the browser remembers it for later connections.

A DNS HTTPS record (RFC 9460) can advertise h3 before the first connection, so a browser that queries it can try QUIC straight away. Browsers keep TCP as a fallback, because some networks block UDP on port 443.

QUIC has costs. It can use more CPU per byte than kernel TCP, and its encrypted headers give network operators less to troubleshoot with.

To check a site, look for h3 in the Protocol column of your browser's network panel, or query the headers and DNS: