What Is RTT? Round-Trip Time Explained

Round-trip time (RTT) is the time between a sender transmitting a packet and receiving the reply that acknowledges it, measured in milliseconds. It adds up propagation delay in both directions, serialization onto each link, queuing in routers and processing at the far end. It sets the floor for every handshake, request and TCP congestion window that crosses a network path.

In practice, RTT is mostly physics plus queues. Light in optical fiber travels at roughly 200,000 km per second, so every 1,000 km of fiber path adds about 10 ms of round trip time. As of 2026, a New York to London round trip typically measures 70 to 80 ms against a physical floor near 56 ms, which is why moving the server closer beats buying more bandwidth for most web and API traffic.

How round trip time is measured on the wire

Network RTT is measured by timestamping a packet on departure and again when its acknowledgment or reply arrives. ICMP echo (ping) does this explicitly. TCP does it implicitly on every connection: the kernel samples the delay between sending a segment and receiving its ACK, then keeps a smoothed RTT and an RTT variance to size its retransmission timeout, as specified in RFC 6298.

Each sample has four components. Propagation is fixed by path length and the speed of light in glass. Serialization depends on packet size and link rate, and it is negligible above 1 Gb/s. Processing is usually microseconds. Queuing is the variable part. A bloated buffer on a saturated home router or a congested peering link can add 100 to 500 ms under load, so the same path can show 20 ms idle and 300 ms during a large upload. QUIC tracks RTT the same way but subtracts the receiver's reported ACK delay (RFC 9002). That gives a cleaner propagation estimate than classic TCP.

Typical RTT values by distance

Real paths run 1.3 to 2.5 times their great-circle floor because fiber follows cables, landing stations and peering points, not straight lines.

Where RTT sits in the protocol stack

RTT is a multiplier, not a one-time cost. A cold HTTPS fetch spends one round trip on DNS (if uncached), one on the TCP handshake, one on TLS 1.3 (two on TLS 1.2), and one on the HTTP request itself before the first byte arrives. TCP slow start then grows the congestion window from an initial 10 segments (about 14.6 KB, per RFC 6928), roughly doubling it once per RTT.

RTT also caps steady-state throughput. A single flow cannot exceed its window divided by RTT. That is the bandwidth-delay product read backwards. A 4 MB receive window over a 100 ms path tops out near 320 Mb/s, whatever the link speed. The same window over 20 ms allows 1.6 Gb/s.

Why cutting RTT matters more than raw bandwidth

For objects under a few megabytes, total transfer time is dominated by the number of round trips, not by link speed. A cold 500 KB fetch needs about 9 round trips: 3 for DNS, TCP and TLS 1.3, then 6 slow-start rounds (14.6, 29.2, 58.4, 116.8, 233.6 KB, then the remainder). Bandwidth only affects the serialization of 4 megabits.

Ten times the bandwidth saves 36 ms on this fetch, while cutting RTT from 100 ms to 20 ms saves about 720 ms.

This arithmetic is the reason CDNs exist: terminating TCP and TLS at an edge 20 ms away replaces the expensive round trips, and cache hits remove the origin leg entirely. BlazingCDN's Anycast CDN routes each user to a nearby edge, measured June 2026 on a 100 MB HTTPS download at 27 ms and 1.12 Gb/s in Europe, 24 ms and 1.11 Gb/s in North America, and 47 ms and 761 Mb/s in Asia.

RTT vs. latency, ping time and TTFB

RTT vs. latency: latency usually means one-way delay, from sender to receiver. RTT is both directions plus the far end's turnaround. On symmetric paths RTT is roughly twice one-way latency, but asymmetric routing often breaks that assumption. Measuring true one-way latency requires synchronized clocks, which is why most tools report RTT.

RTT vs. ping time: ping reports ICMP echo RTT. Routers often rate-limit or deprioritize ICMP, and some networks route it differently from TCP. Ping can therefore read higher or lower than the RTT your application connections actually experience.

RTT vs. TTFB: time to first byte includes DNS, connection setup, TLS, request transit and server think time. A TTFB of 400 ms on a 50 ms RTT path means roughly 200 ms of round trips and 200 ms of origin or cache-miss processing. That split tells you whether to fix routing or the backend.

How to test round trip time on your own stack

The most reliable RTT figure comes from TCP connections your application already serves. ICMP tests are a quick sanity check, while kernel socket statistics and browser timing data show what users actually experience. Use at least two of these sources before drawing conclusions.

• ping and mtr: ping gives min, average and max ICMP RTT. mtr adds per-hop loss and delay, which shows where a path inflates.
• Kernel socket stats: on Linux, the ss utility with its TCP info option prints the smoothed RTT and RTT variance for each live socket. These are the exact values the stack uses to make decisions.
• Web server logs: nginx exposes a tcpinfo_rtt log variable in microseconds. Logging it per request gives you RTT distributions by client network for free.
• Real user monitoring: in the browser Navigation Timing data, connectEnd minus connectStart approximates one TCP handshake RTT (plus TLS on HTTPS). Track p50 and p95 by country.

Common RTT misconceptions

"A faster link fixes slow pages." It rarely does for small objects, as the worked calculation above shows. Bandwidth helps large downloads only after slow start has opened the window.

"RTT is fixed by distance." Distance sets the floor. Queuing under load, Wi-Fi retransmissions and poor peering routinely double the observed value, so measure loaded RTT, not idle RTT.

"Newer protocols make RTT irrelevant." TLS 1.3 and QUIC remove one or two handshake round trips, and 0-RTT resumption only helps returning clients, with replay-safety limits. Slow start and window-over-RTT limits still apply.

FAQ: what is RTT and how to measure round trip time

What is a good RTT for a website?

A good RTT between a user and the server answering their request is under 30 ms, and under 50 ms is acceptable. Above 100 ms, each round trip in connection setup and TCP slow start becomes visible to users, so a cold page load with 9 or more round trips loses close to a second to RTT alone.

Is RTT the same as latency?

RTT is not the same as latency, though the terms are often mixed up. Latency usually means one-way delay, while RTT measures the full trip there and back, including the far end's turnaround time. On symmetric routes RTT is about twice the one-way latency, but asymmetric routing makes that ratio unreliable for precise diagnosis.

How much RTT does distance add?

Distance adds roughly 10 ms of RTT per 1,000 km of fiber path, because light in glass travels about 200,000 km per second. Real routes are 1.3 to 2.5 times longer than the great-circle distance, so a 5,600 km transatlantic hop with a 56 ms physical floor typically measures 70 to 80 ms.

Why is my ping RTT different from application RTT?

Ping uses ICMP, which routers often rate-limit, deprioritize or route differently from TCP, so its RTT can diverge from what application connections experience. For accurate network RTT, read the kernel's smoothed TCP RTT from socket statistics, server logs such as nginx tcpinfo_rtt, or browser connection timing from real users.

Measure your RTT budget per region

This week, log TCP handshake RTT for every request (server-side tcpinfo_rtt or browser connect timing), then plot p50 and p95 by country. Multiply each figure by the round trips your critical path needs: usually 3 for setup plus the slow-start rounds for your largest above-the-fold object. Any region where that product exceeds 500 ms needs a closer edge, not a fatter pipe. Fixing those regions first will move user-visible load times more than any bandwidth upgrade.

To compare your numbers against a nearby edge, the BlazingCDN performance metrics page publishes its June 2026 measurements and a public test file you can fetch from your own networks.