HTTP/3 and QUIC simulator

Both protocols load the same objects through the same simulated link, with the same congestion control and the same loss rate, so the differences come from TCP versus QUIC alone.

• Load 20 API responses with no loss and compare when the first one arrives: QUIC's handshake is one round trip shorter. Turn on 0-RTT resumption and it is shorter again.
• Set loss to 1% on the web page. In the HTTP/2 waterfall, red rows had arrived but waited behind another object's lost packet; HTTP/3 has none. Compare how much that moves the finish times.
• Load the 4 large files and switch from Wi-Fi to mobile at 0.6 s. HTTP/2 must open a new connection and start the unfinished files again; HTTP/3 pauses one round trip and carries on.

QUIC is a general-purpose transport protocol that provides what TCP and TLS provide together, reliable ordered delivery, congestion control and encryption, plus several independent streams on one connection. It runs in user space on top of UDP. HTTP/3 is the mapping of HTTP onto QUIC: each request and response uses its own QUIC stream, and headers are compressed with QPACK, a variant of HPACK that tolerates streams arriving out of order.

The changes target three weaknesses of TCP: the handshake cost of TCP followed by TLS, head-of-line blocking between unrelated streams, and connections that break when an address changes.

Over TCP, a client first exchanges SYN and SYN-ACK (one round trip), then the TLS 1.3 handshake (a second round trip), and only then sends its request; the response takes a third. QUIC carries the TLS 1.3 handshake in its first packets, so the request can go after one round trip. With 0-RTT resumption, a client that has a ticket from an earlier session sends the request with its first packet. Time until a small response has fully arrived, with no loss:

TCP delivers one ordered byte stream, so HTTP/2 streams sharing a connection all wait when any packet is lost. QUIC frames carry a stream ID and offset, and each stream is reassembled on its own; a lost packet delays only the streams whose data it carried. The web page over a 100 ms, 20 Mbit/s link, responses sent one at a time in order, averaged over 5 loss patterns:

A TCP connection is identified by its two IP addresses and ports. When a phone leaves Wi-Fi for mobile data its address changes, the connection is dead, and the client must open a new one and ask again for anything unfinished. QUIC packets carry connection IDs instead, so the connection can move: the client starts sending from the new address, the server checks it can be reached there (a PATH_CHALLENGE answered by a PATH_RESPONSE) and the transfer continues. Downloading four 600 KB files at 20 Mbit/s with a switch of network at 0.6 s:

A new transport directly on IP would be dropped by firewalls and NATs that only understand TCP and UDP, and TCP itself lives in operating-system kernels and middleboxes that change slowly. QUIC therefore runs over UDP and is implemented in libraries that ship with applications, and almost all of its headers are encrypted so that the network cannot come to depend on them.

The price is CPU: user-space packet processing, per-packet encryption and the lack of the offloads TCP has accumulated made QUIC expensive at first: Google measured its server CPU use at about 3.5 times that of TLS over TCP, brought down to about twice with optimization, and techniques such as UDP segmentation offload have narrowed the gap since. Some networks block or throttle UDP, so browsers race or fall back to TCP. Clients usually learn about HTTP/3 from an Alt-Svc response header or an HTTPS DNS record.

It is the same packet-level model as the HTTP/2 simulator: 1,200-byte packets through a bottleneck with a fixed rate and round trip, a seeded random loss rate, a congestion window that starts at 10 packets and is cut to 0.7 on loss, and RFC 9002's packet and time thresholds for detecting loss, applied identically to TCP and QUIC. TCP and TLS 1.3 take two round trips before the request, QUIC one, or none with 0-RTT. On a network change the TCP connection is replaced (two more round trips) and unfinished responses start again; the QUIC connection pauses one round trip for path validation and resends what was in flight. Not modeled: CPU cost, pacing, UDP blocking, QPACK and TLS record sizes.

Jim Roskind designed QUIC at Google in 2012; it was added to Chrome in June 2013 and served from Google's servers as an experiment from then on. In 2017 Adam Langley and colleagues reported that it carried an estimated 7% of Internet traffic, and that it cut Google Search latency by 8.0% on desktop and 3.6% on mobile and YouTube rebuffering by 18.0% and 15.3%. The IETF formed a QUIC working group in 2016 and reworked the design substantially, notably replacing Google's own cryptographic handshake with TLS 1.3. QUIC was published as RFC 9000 to 9002 in May 2021, and HTTP/3 as RFC 9114, with QPACK as RFC 9204, in June 2022.