RTT (Round-Trip Time)

RTT (round-trip time) is the delay between sending a packet and receiving the response that packet triggers. The IETF metric definition is exact. The source sends the first bit at time T. The destination receives it and immediately sends a packet back. The source receives the last bit of that response at T+dT (RFC 2681, section 2.4). Two things follow from that wording. RTT is not one-way latency doubled. You cannot in general add two one-way delays to get a round trip. Whatever time the far end spends recognising the packet and producing the response also lands inside your measurement (RFC 2681, section 2.7.3). RTT is also not TTFB or page-load time. Those add application work at the server on top of the transport round trips. RTT is the transport-level unit that the rest of web delay is priced in. It is the number a CDN exists to make smaller.

How it works

Nobody transmits an RTT. You either probe for it or the transport measures it for you. TCP does the latter. It has to decide how long to wait before treating a segment as lost. A sender keeps two variables: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation). It updates them from every new sample with weights RFC 6298 says SHOULD be alpha=1/8 and beta=1/4. It sets its retransmission timeout to SRTT plus four times RTTVAR, or plus the clock granularity if that is larger (RFC 6298, section 2). Two details matter in practice. Samples may never be taken from a retransmitted segment, because the reply is then ambiguous between the original and the copy. That rule is Karn’s algorithm, and TCP MUST use it (RFC 6298, section 3). However small the measured RTT is, the computed timeout SHOULD be rounded up to one second. So a packet lost on a 5 ms path still costs roughly a second of waiting before the retransmission (RFC 6298, rule 2.4).

Before an HTTPS response can arrive, the client pays a series of round trips in sequence. For an HTTPS origin the connection handshake alone is DNS, then TCP, then TLS (HTML Standard, link type "preconnect"):

• DNS. Resolving the name is its own latency cost when the answer is not already cached. That is why browsers offer a hint to perform it early (HTML Standard, link type "dns-prefetch"). On a CDN this step is also what picks your serving node.
• TCP. The three-way handshake is the procedure that establishes a connection (RFC 9293, section 3.5): SYN out, SYN-ACK back, ACK out. Data may only be exchanged after it completes. So it adds one RTT to network latency. That is precisely what TCP Fast Open was designed to reclaim.
• TLS. A TLS 1.3 full handshake is a 1-RTT handshake. Figure 1 of the specification shows the client sending its application data one round trip after the ClientHello (RFC 8446, section 2). Older versions are worse. A full handshake up to and including TLS 1.2 needs two full protocol rounds (four flights). Only after that may either side send application data.
• The request itself. The HTTP request out and the first response bytes back are one more round trip. So a cold HTTPS request is several RTTs of pure waiting before a single byte of content appears. The total is round trips times RTT: two independent levers.

Cutting the count is the other lever, and it is what recent protocol work attacks. TLS 1.3 added a zero round-trip time mode. This means saving a round trip at connection setup for some application data, at the cost of certain security properties. A returning client with a pre-shared key sends early data in its first flight. That is because the 0-RTT data is just added to the 1-RTT handshake in the first flight. That is 0-RTT. The price is real. The same section warns that the security properties for 0-RTT data are weaker than for other TLS data. It is not forward secret. There is no guarantee of non-replay between connections. QUIC is the transport under HTTP/3. It goes further and relies on a combined cryptographic and transport handshake to minimize connection establishment latency. This collapses the separate TCP and TLS round trips into one exchange.

RTT does not only delay the start. It throttles the middle. TCP may only have a window of data outstanding. During congestion avoidance that window is incremented by roughly 1 full-sized segment per round-trip time (see cwnd). Feedback arrives only once per round trip. So the longer the RTT, the slower a transfer ramps. As RFC 2681 puts it, the larger the value of delay, the more difficult it is for transport-layer protocols to sustain high bandwidths. That is why RTT, not link capacity, often decides observed throughput.

Why it matters for a CDN

A CDN attacks RTT the only way distance can be attacked. It answers from a node near the client instead of from the origin. Every setup step above is priced in whole RTTs. So shortening the path discounts all of them at once. The TCP handshake, the TLS handshake and the request round trip shrink together. That is why moving a serving PoP closer pays several times over on a single page load. The handshakes shrink because they terminate at the edge server, not at your origin. Fastly, for example, states plainly that it only supports 0-RTT between Fastly and requesting clients, not between Fastly and your origin servers. Vendors quote proximity in these terms. Cloudflare claims its anycast network reaches 95% of the world’s Internet-connected population within 50 milliseconds.

On a cache hit the client-to-edge round trip is the only RTT in the request. The long haul to the origin disappears for that request. On a miss it does not: the fetch to origin is paid on top. That gives you the one comparison worth making. Measure the RTT to your nearest edge and the RTT to your origin. The gap between them is the delay the CDN removes from every request it can serve itself.

What CDNs do

Vendors differ in how they steer a client to a near node and in how they handle the hop that is left:

• Cloudflare uses anycast. The same IP address is announced from nodes in many locations. BGP decides which one a client reaches. So the incoming request is routed to and answered by the node closest to the user.
• Amazon CloudFront steers with DNS instead. DNS routes the request to the CloudFront POP that can best serve it, typically the nearest in terms of latency. A POP miss then goes to the nearest regional edge cache. Only a miss there reaches the origin. There are documented exceptions. Dynamic requests and the proxy methods PUT, POST, PATCH, OPTIONS and DELETE go directly to the origin from the POP.
• Akamai reduces the distance itself. Its platform docs describe how it can reduce the distance between your users and your content, lowering latency. Its Image and Video Manager can also react to a measured RTT. The Slow Connection Quality Override is optional. You enable it and set a fixed quality value. It then applies that value instead of your static or perceptual quality, if the client round trip time (RTT) is 300ms or greater. The result is lower-quality images and a faster load.
• Fastly serves TLS 1.3 by default and offers 0-RTT. This can reduce the latency of resumed connections. Its replay guard is the interesting part. By default it answers only idempotent requests over 0-RTT: GET and HEAD without query parameters. It marks such requests with an Early-Data: 1 header per RFC 8470. Your own code can inspect that header.

Watch out for

• RTT is not TTFB, and not page-load time. The definition itself makes the far end’s turnaround part of the measurement. A real server does far more work than an echo responder. If TTFB is bad while RTT is fine, the problem is not the network. It is origin work or cache misses.
• A ping is not the RTT your transfer sees. RFC 2681 accepts ping as a round-trip measure. But it warns that a router may not handle an ICMP request in the fast path. It also warns that load on the reflecting point distorts the result. More generally, the value of the metric depends on the type of IP packet used to make the measurement. So ICMP echo RTT and the RTT governing your TCP connection are different numbers. Time a real TCP connect or read the transport’s own estimate when the difference matters.
• The two directions are not the same path. Forward and reverse routes can differ. So round-trip measurements actually measure the performance of two distinct paths together. Queueing can be asymmetric even when the routes match. A single RTT figure hides which direction hurts.
• RTT varies, so one sample proves nothing. The minimum of the metric indicates propagation and transmission delay alone. Values above the minimum indicate congestion on the path (RFC 2681, section 1.1). That spread is jitter. It is why TCP smooths its estimate rather than trusting the last sample.
• Bandwidth does not fix RTT. A long path limits how much data can usefully be outstanding. The window opens only about one segment per round trip during congestion avoidance. Buying capacity for a high-RTT path changes the ceiling, not the ramp.
• 0-RTT is not free. Early data is not forward secret. It has no non-replay guarantee between connections either (RFC 8446, section 2.3). Restrict it to safe, idempotent requests, as Fastly does by default.

Best practice

• Measure both legs continuously: client to edge and edge to origin. Treat the gap as the CDN’s contribution. A single figure from one location tells you nothing about the clients you actually serve. That is what RUM is for.
• Report the distribution, not an average. Keep the minimum as your propagation floor. Watch p95 and p99 for the congestion that sits above it.
• Attack the round-trip count as hard as the RTT itself. TLS 1.3, 0-RTT for safe requests, HTTP/3 and preconnect each remove whole trips. Only moving closer removes milliseconds from the trips that remain. Both multiply into the same total.
• Know which requests still pay the full origin RTT. Uncacheable and dynamic traffic does not benefit from a nearer cache. On CloudFront it bypasses the regional edge cache entirely. So shorten that path deliberately, for example with origin shield or by moving the origin.
• Alert on RTT and TTFB as separate signals. RTT moving alone points at routing or congestion. TTFB moving alone points at your application.