Network latency is the delay between a data packet being sent and it arriving at its destination.
Let’s watch it happen. Imagine you’re running a simple web server. A client requests a page.
GET /index.html HTTP/1.1
Host: example.com
Your server receives this request and starts building the response. It might need to fetch data from a database, process some logic, and then serialize the HTML.
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1500
<!DOCTYPE html>
<html>
<head>
<title>Example Page</title>
</head>
<body>
<h1>Hello, World!</h1>
<p>This is a sample page.</p>
</body>
</html>
The time it takes from when the client sends the GET request to when the server starts sending the HTTP/1.1 200 OK response is the round-trip time (RTT) for the request. The time from when the server starts sending the response to when the client finishes receiving it is the one-way delay. RTT is often used as a proxy for one-way delay because it’s easier to measure from a single point.
The total latency a user experiences is the sum of several components:
- Serialization Delay: The time it takes for the application to convert data into a format that can be sent over the network. This includes database queries, computation, and formatting.
- Queuing Delay: When network devices (routers, switches) are busy, packets have to wait in line. This is a major contributor to variable latency.
- Transmission Delay: The time it takes to push all the bits of a packet onto the network link. This depends on the packet size and the bandwidth of the link. A larger packet or a slower link means higher transmission delay.
- Propagation Delay: The time it takes for a signal to travel across the physical medium (e.g., fiber optic cable, airwaves). This is limited by the speed of light and is directly proportional to the distance. Traveling across the Atlantic takes longer than across a room.
High latency impacts user experience dramatically. For interactive applications like online gaming or video conferencing, even a few hundred milliseconds can make the difference between a smooth experience and an unusable one. Websites with high latency load slower, leading to increased bounce rates.
Consider the ping command. When you ping example.com, your machine sends a small ICMP echo request packet to example.com’s server. The server receives it and immediately sends back an ICMP echo reply. The ping utility measures the time between sending the request and receiving the reply – this is your RTT.
ping example.com
PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=118 time=25.3 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=118 time=26.1 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=118 time=25.8 ms
Here, time=25.3 ms is the RTT for that specific packet. This RTT includes the propagation delay across the internet, any queuing delays at intermediate routers, and the processing time on the destination server and your local machine.
The difference between the minimum, maximum, and average RTT values revealed by ping is often more telling than the average itself. A large variance (jitter) indicates that queuing delays are inconsistent, which is particularly problematic for real-time applications where consistent timing is key.
While you can’t change the speed of light, you can optimize for lower latency by minimizing the number of network hops between your client and server, choosing data centers geographically closer to your users, and ensuring your network infrastructure isn’t overloaded. Application-level optimizations, like reducing the size of data transferred or using techniques like prefetching, can also significantly mask the perceived latency for the end-user.
The most surprising aspect for many is how much of the observed latency is often due to bufferbloat – the excessive buffering in network devices that causes packets to be held for long periods, leading to high queueing delays even when the link isn’t fully saturated. This is a consequence of buffer sizes being designed for older, slower networks and not being adequately managed in modern high-speed infrastructure.
Understanding RTT is the first step to diagnosing why your application feels sluggish or why certain network operations are taking longer than expected.