Latency, bandwidth, and round trips

Why fast servers still feel slow

You now know that opening a TCP connection costs a full back-and-forth before any data moves. This lesson names the costs, because they explain a mystery every engineer eventually hits: a server that responds in 2 ms can still feel slow from the other side of the world, and no amount of server power fixes it. Understanding why is how you avoid optimizing the wrong thing.

Two different measurements get mixed up constantly:

• Latency is the time one message takes to reach the other machine, set mostly by physical distance and the number of routers on the way. Measured in milliseconds (ms).
• Bandwidth is the volume a connection can carry per second, like the width of a pipe. Measured in bits or bytes per second.

A round trip is one message over and one reply back, and its duration is the RTT (round-trip time). Typical RTTs: a few ms within a city, ~70 ms across a continent, 150–250 ms between continents.

Here is the punchline: before a browser receives the first byte of a page, it spends several sequential round trips — the DNS lookup, the TCP handshake (lesson 3-2), the TLS handshake (unit 7), and finally the request itself. Each one must finish before the next starts, so the waiting adds up multiplicatively with distance.

When bandwidth matters, and when it does not

A useful mental formula for one download:

total time ≈ (setup round trips × RTT) + (size ÷ bandwidth)

The first term is latency's share, the second is bandwidth's. For a small request — an API call returning 2 KB of data — the transfer part is nearly zero and latency is everything. For a 2 GB video, the transfer term dominates and bandwidth is what you would pay to improve. Diagnosing "slow" starts with asking which term you are actually in.

This is also why HTTP clients reuse connections. Keep-alive (the default in HTTP/1.1) keeps the TCP+TLS connection open after a response so the next request to the same server skips both handshakes and pays only one round trip. Browsers go further and issue independent requests in parallel rather than queueing them.