Round-trip time (RTT) is the time it takes for the server to receive a data packet, process it, and send the client an acknowledgement that the request has been received. It is measured from the time the signal is sent till the response is received.
When a user clicks a button on a website, the request is sent to the server as a data packet. The server needs time (RTT) to process the data, generate a response, and send it back. Each action, like sending a form upon a click, may require multiple requests.
RTT determines the total network latency and helps monitor the state of data channels. A user cannot communicate with the server in less than one RTT, and the browser requires at least three round trip times to initiate a connection:
In some latency-sensitive services, e.g., online games, the RTT is shown on the screen.
Ping (RTT) in World of Tanks: on the top left
Distance and number of intermediate nodes. A node is a single device on the network that sends and receives data. The first node is the user’s computer. A home router or routers at the district, city, or country level are often intermediate nodes. The longer the distance between the client and server, the more intermediate nodes the data must pass through and the higher the RTT.
Server and intermediate node congestion. For example, a request may be sent to a fully loaded server that is concurrently processing other requests. It can’t accept this new request until other ones are processed, which increases the RTT. The RTT includes the total time spent on sending and processing a request at each hop, so if one of the intermediate nodes is overloaded, the RTT adds up.
You never know exactly to what extent the RTT will grow based on how the infrastructure is loaded; it depends on individual data links, intermediate node types, hardware settings, and underlying protocols.
Physical link types and interferences. Physical data channels include copper, fiber optic, and radio channels. The RTT here is affected by the amount of interference. On the Wi-Fi operating frequency, the noise and other signals interfere with the useful signals, which reduces the number of packets per second. So, the RTT is likely to increase over Wi-Fi than over fiber-optics.
To measure the RTT, you can run the ping command in the command line, e.g., “ping site.com.”
An example of a ping to google.com with calculated round trip time at the bottom line
Requests will be sent to the server using ICMP. Their default number is four, but it can be adjusted. The system will record the delayed time between sending each request and receiving a response and display it in milliseconds: minimum, maximum, and average.
The ping command shows the total RTT value. If you want to trace the route and measure the RTT at each individual node, you can use the tracert command (or traceroute for Linux or Mac OS). It is also can be performed via the command line.
Many factors affect RTT, making it difficult to establish a normal—the smaller the number, the better.
In online games, over 50 milliseconds are noticeable: players cannot accurately hit their targets due to network latency. Pings above 200 milliseconds matter even when users browse news feeds or place online orders: many pages open slowly and not always fully. A buyer is more likely to leave a slow website without making a purchase and never come back, which is what 79 percent of users do.
A jewelry store’s ping. The average RTT is 198 milliseconds
Ping for a German portal: the average RTT is 72 milliseconds
The RTT of a German news portal is almost three times lower than that of a US store because we ping from Germany. There are fewer nodes between the user and the server, which are both in the same country, so the RTT is lower.
Connect to a content delivery network (CDN). The hosting provider’s servers are usually located in the same region where most of the audience lives. But if the audience of the site grows or changes geographically, and content is requested by users who are far away from the server, RTT increases for them, and the site loading speed is slower. To increase the loading speed, use a CDN.
CDN (Content Delivery Network) is a service that caches (mostly static) content and stores it on servers in different regions. Therefore, only dynamic content is downloaded from the main source server, which is far from the user. Heavy static files—the main share of the website—are downloaded from the nearest CDN server, which reduces the RTT by up to 50 percent.
How a CDN works
For example, the client requests content from a CDN-connected site. The resource recognizes that there is a caching server in the user’s region and that it has a cached copy of the requested content. To speed up the loading, the site substitutes links to files so that they are retrieved not from the hosting provider’s servers, but from the caching server instead since it is located closer. If the content is not in the cache, CDN downloads it directly from the hosting server, passes it to the user, and stores it in the cache. Now a client on the same network can request the resource from another device and load the content faster without having refer to the origin server.
Also, CDN is capable of load balancing: it routes requests through redundant servers if the load on the closest one is too high.
Optimize content and server apps. If your website has visitors from different countries/regions, you need a CDN to offset the increased RTT caused by long distances. In addition, the RTT is affected by the request processing time, which can be improved by the below content optimizations:
For fast content delivery anywhere in the world, you need a reliable CDN with a large number of points of presence. Try Gcore CDN—this is a next-generation content delivery network with over 140 PoPs on 5 continents, 30 ms average latency worldwide, and many built-in web security features. It will help to accelerate the dynamic and static content of your websites or applications, significantly reduce RTT, and make users satisfied.