What is RTT (Round-Trip Time) and How to Reduce it?
Round Trip Time (RTT) is the time it takes for a data packet to travel from a sender to a receiver and back. Measured in milliseconds, RTT reflects propagation, processing, and queuing delays, and is a key metric for network performance. In ideal conditions, it can be approximated as twice the one-way propagation delay.
Round-trip time is an important metric in networking that can indicate the quality of communications between two endpoints. RTT can be directly impacted by a range of architecture design decisions, especially by your network topology.
What is Round-Trip Time (RTT)?
In networking, round-trip time (RTT), also known as round-trip delay time (RTD) is defined as a metric that measures in milliseconds the amount of time it takes for a data packet to be sent plus the amount of time it takes for acknowledgement of that signal to be received. This time delay includes propagation times for the paths between the two communication endpoints.
RTT vs. Ping – What’s the difference?
Round-trip time and ping time are sometimes considered synonymous. Although ping time can provide a good RTT estimate, the difference is that ping tests are usually performed within a transport protocol that uses ICMP packets. In contrast, RTT is measured at the application layer (layer 7 of OSI/ISO) and includes additional processing delays caused by higher-level protocols and applications (e.g. encrypted communication by HTTPs).
RTT vs. Latency – What’s the difference?
Network latency is closely related, but different from RTT. Latency is the time required for a data packet to travel from the sending endpoint to the receiving endpoint (only one trip). Many factors may affect this path.
The latency is not definitely equal to half of the RTT, because the latency may be asymmetric between any two given endpoints. RTT includes the processing delay at the echo endpoint.
What is a good round-trip time?
Every type of application will have its own requirements and it’s almost impossible to give a concrete time. What is bearable for one application may be unbearable for another.
For instance, AWS WorkSpaces, which is a fully managed and persistent desktop virtualization service that enables users to access their applications and the resources they need, has these thresholds for RTT:
- The round-trip time (RTT) from the client's network to the AWS Region that the WorkSpaces are in should be less than 100ms.
- If the RTT is between 100ms and 200ms, the user can access the WorkSpace, but performance is affected.
- If the RTT is between 200ms and 375ms, the performance is degraded.
- If the RTT exceeds 375ms, the WorkSpaces client connection is terminated.
So based on this, your users should have 100ms RTT for normal usage of your application and a maximum of 200ms before your application will degrade the quality of your service.
Why is RTT in networking important?
Network round-trip time tends to have a great impact on your end-user experience in interactive applications, such as web browsing. Network administrators can use it to diagnose the speed and reliability of the network connection and many web applications disconnect if RTT is too high.
How to calculate or measure RTT
RTT calculation
The best way to calculate RTT is to understand that when a user loads a web page in a browser, they must first send out a request to load the page. This requires at least one RTT to get the response to the user.
RTT is a complex metric that has several components. It includes propagation delay, processing delay, queuing delay, and encoding delay. But normally processing delay, queuing delay, and encoding delay have negligible values.
Propagation delay is the length of time taken for a request to reach its destination. The propagation delay is usually the dominant component in RTT and you can get a good estimate of RTT by a simple formula: RTT = 2 x Propagation delay.
You should also understand that it generally takes more than a single request to load the entire page. The page might consist of images, scripts, etc., each requiring a separate request to load. If the page consists of 20 components, it may take RTT x 20 to request the entire page.
Measure RTT
Although it is not the most accurate way to estimate RTT, the most common tool used to measure the RTT is a ping command. A ping command sends Internet Control Message Protocol (ICMP) echo request packets to the destination and then reports the time, in milliseconds, that it takes to receive a response signal. As you can see below, it can be used in Windows command-line (CMD) by typing ping “server ip or link”.
You can use the following Linux command to measure average, maximum, and minimum RTT for a specified server.
ping -c 20 -i 1 "domain name or ip address" \*example ping -c 20 -i 1 google.com
If you need to know more information about the “route” from the starting-point to the origin server, you can use the command traceroute and get information about how much time every hop in the route takes.
What influences RTT
These are some basic things that can influence RTT:
- Physical distance – the distance between a start point (origin) and end point (user computer) is a main factor, because of the limitation of the speed of light which is the maximum speed your packets can travel between these two points. This can only be reduced by moving content closer to the user.
- Response time of the origin server – the amount of time it takes a server to process and respond to a request is a potential bottleneck in network latency. When a server is overwhelmed with requests, such as during a DDoS attack, its ability to respond efficiently can be inhibited, resulting in increased RTT.
- Transmission medium (cables) – the way in which connections are made affects how fast the connection moves; connections made over optical fiber will behave differently than connections made over copper. Likewise, a connection made over a wireless frequency will behave differently than that of a satellite communication.
- Network traffic in an area – the amount of traffic on the local area network can bottleneck a connection before it ever reaches the public internet.
How to reduce RTT
This section is separated into two – General and CDN, because the CDN is a separate way to reduce the overall RTT.
General ways to reduce RTT:
- Reducing the number of unique hostnames from which resources are served cuts down on the number of DNS resolutions that the browser has to make.
- Minimizing HTTP/S redirects from one URL to another cuts out additional RTTs and wait time for users.
- Removing “broken links” or requests that result in 404/410 errors, avoiding wasteful requests.
- Combining external scripts into as few files as possible cuts down on RTTs and delays in downloading other resources.
- Combining external stylesheets and files into as few files as possible cuts down on RTTs and delays in downloading other resources. Combine images into as few files as possible.
- Browser caching: this can be used to reduce RTT by leveraging browser caching. Browsers will cache certain resources of a website locally in order to help improve their RTT.
- Bringing content closer to the user: create a server close to your user, or you can use CDN which can do this automatically for you, when there is a demand for specific content in a specific area. Learn more about this below.
Reducing RTT using Amazon CloudFront CDN distribution
One of the original issues CDNs (Content Delivery Networks) were designed to solve was to reduce RTT. They have been largely successful, and it’s now reasonable to expect a decrease in your RTT of 50% or more after onboarding a CDN service. You will read about the main reasons why this is possible in the section below.
Stormit recommends using cloud-based CDN such as Amazon CloudFront, which is a network of strategically placed servers, each holding a copy of your content. CloudFront works seamlessly with any AWS origin, such as Amazon S3, Amazon EC2, Elastic Load Balancing, or with any custom HTTP origin.
CDN is able to address the factors influencing RTT in the following ways:
- Points of Presence (PoPs) – A CDN maintains a network of geographically dispersed PoPs—data centers, each containing cached copies of site content, which are responsible for communicating with site visitors in their vicinity. They reduce the distance a signal has to travel and the number of network hops needed to reach a server.
- Load distribution – During high traffic times, CDNs route requests through backup edge servers with lower network congestion, speeding up server response time and reducing RTT.
- Web caching – A CDN caches HTML, media, and even dynamic content on a PoP close to your user. In many cases, a user’s request can be addressed by a local PoP and does not need to travel to an origin server, thereby reducing RTT.
- Scalability – A CDN service operates in the cloud, enabling high scalability and the ability to process a vast amount of user requests. This eliminates the possibility of server congestion.
- CDN has more functions including security and cost reduction. Learn more in our article – What is CDN and Why use it?
Stormit offers custom Amazon CloudFront pay-as-you-go pricing and you pay only for what you use. There is no minimum fee and you can start as low as 1TB/month.
Learn more about Amazon CloudFront and how Stormit can help you reduce costs associated with using it or contact us for a free consultation.
FAQs
Round Trip Time (RTT) is the time it takes for a data packet to travel from a source device to a destination and back. It’s a key metric for measuring network latency and is expressed in milliseconds.
You can measure RTT using tools like ping, which sends ICMP echo requests and measures the time until the reply arrives. In formulas, RTT ≈ 2 × one-way propagation delay + processing + queuing delays.
RTT measures latency (time) for a complete packet trip, while TTL (Time To Live) is a cache lifespan in DNS, CDN, or browser cache. TTL doesn’t measure time but prevents data from circulating indefinitely.
Mean RTT is the average of multiple RTT measurements over time. It helps smooth out spikes and gives a more accurate view of typical network performance.
Yes. “Round trip” describes the journey of a packet to its destination and back to the sender – a two-way process.
To lower RTT, use a CDN (like Amazon CloudFront or FlashEdge) to serve content from edge servers closer to users, optimize DNS resolution, enable HTTP/2 or keep-alive, compress files, and reduce server processing time.
An AWS Solutions Architect with over 5 years of experience in designing, assessing, and optimizing AWS cloud architectures. At Stormit, he supports customers across the full cloud lifecycle — from pre-sales consulting and solution design to AWS funding programs such as AWS Activate, Proof of Concept (PoC), and the Migration Acceleration Program (MAP).
