Learning objective. Learn to think in round trips rather than milliseconds: how many RTTs a cold connection spends before the first response byte, where each one goes, and which ones 0-RTT and connection reuse can remove.
Why round trips, not milliseconds #
On a fast path an extra round trip is noise; on a 300 ms satellite or cross-continent path it is the whole story. The durable way to reason about latency is to count round trips, because that count is fixed by the protocol while the millisecond cost of each RTT is fixed by the path. A design that costs "2 RTT to first byte" costs 20 ms on a LAN and 600 ms over satellite: same protocol, same count, wildly different experience. Budget in RTTs first, then multiply by the path's RTT last.
QUIC's headline win is exactly an RTT saved at setup. It "relies on a combined cryptographic and transport handshake to minimize connection establishment latency" ([RFC 9000 §7]). The TLS 1.3 handshake and the transport handshake happen together, so a cold QUIC+TLS connection is ready in one round trip, where TCP+TLS classically spent two or three.
The cold-connection budget #
Trace the top half of Figure 8.1-1 and count. The client's first flight carries its Initial (ClientHello) and transport parameters. One round trip later the server's flight arrives: Initial and Handshake packets with the ServerHello and certificate, and it may already append 0.5-RTT data (application data the server sends before the handshake fully completes, [RFC 9000 §7.1]). The client can then send its request in a 1-RTT packet, and the response comes back one more round trip later. So a cold HTTP/3 GET reaches its first response byte at about two round trips: one for the handshake, one for the request/response exchange.
Two protocol features keep that budget from growing:
- Coalescing. Multiple QUIC packets (even different types) pack into one UDP datagram, so the handshake "could consist of as few as four UDP datagrams" rather than a separate datagram per packet ([RFC 9000 §7.1]). Fewer datagrams means fewer chances for a lost one to cost a PTO.
- 0.5-RTT data. The server needn't wait for the handshake to fully finish to start sending response data, shaving part of a round trip off the response ([RFC 9000 §7.1]).
Removing a round trip: 0-RTT #
The bottom half of the figure is the warm case. If the client has connected before and cached the server's transport parameters (§7.1), it can send its request as 0-RTT early data in the same first flight as its Initial ([RFC 9000 §7]). The request is now in flight during the handshake round trip, so the response arrives at about one round trip — the handshake RTT is saved outright.
The catch is what 0-RTT costs in exchange, covered in §2.3: early data is replayable, so it must be limited to idempotent requests, and it rides on remembered limits the server must not have shrunk (§7.1). 0-RTT is the single biggest RTT saving available and the one with the sharpest constraints. §8.3 returns to using it (and other savings) without speculation.
What each round trip is worth #
Because the count is small, each RTT you can remove is a large fraction of the total. On a 200 ms path:
| Scenario | Round trips to first byte | ≈ latency |
|---|---|---|
| Cold QUIC+TLS connection | ~2 | ~400 ms |
| 0-RTT resumption | ~1 | ~200 ms |
| Reused warm connection (no new handshake) | ~1 (request/response only) | ~200 ms |
| Extra Retry for address validation | +1 | +200 ms |
The table's most actionable row is the last one: an address-validation Retry adds a whole round trip ([RFC 9000 §8.1.2], and §8.2), and an already-open connection removes the handshake round trip entirely — which is why connection reuse and pooling matter far more on long paths than on short ones.
"1-RTT handshake" and "1-RTT to first byte" are different claims. The handshake completes in one round trip, but on a cold connection the request still needs a second round trip after it, so first byte is ~2 RTT. 0-RTT is what makes first byte ~1 RTT, by overlapping the request with the handshake. Keep the two counts separate or the budget arithmetic goes wrong.
editorial Before optimizing anything, write down the round-trip count for your critical request path and multiply by your users' real RTT (not your data center's). The biggest wins are almost always structural round-trip removals: reuse a warm connection instead of opening a new one, enable 0-RTT for safe idempotent requests, avoid designs that force a Retry. Shaving milliseconds off processing is not where they come from. A single avoided round trip on a mobile or trans-oceanic path beats any amount of server-side micro-optimization.
Takeaways #
Latency budgeting is round-trip counting: a cold QUIC+TLS connection reaches first byte at ~2 RTT (handshake + request/response), and 0-RTT or a reused warm connection collapses that to ~1 RTT, while an address-validation Retry adds one. Count the RTTs first and multiply by the path's RTT last. The next sections examine what inflates that budget on a real network: loss, reordering, and ACK delay (§8.2). §8.3 then shows how to shrink it safely.