Why are downloads slower if the server is far away?

Question

I know that because of the distance the data has to travel, and light only being so fast, the connection will take longer, and the first bit should arrive slower than downloading from a server which is closer, but once that first bit arrives from the server, shouldn't the rest follow straight after?

For example, if 100 cars set off from France to Spain, it wouldn't take long for the first car to arrive and they should all arrive at the same time. If they set off from China to Spain, it would take much longer, but after the first car arrived, wouldn't the others arrive just after in a continuous stream?

Or does it send one bit (or one packet), then by the time it sends the next, some other bits/packets have been sent so there is "traffic" in between?

Answer 1

Using the car analogy, there's 1000+ km between central France and central Spain. After a certain number of cars arrive at the destination, you need to ACKnowledge that they arrived by sending a car in the other direction which incurs delay. To minimize effects of the long pipe, you need to keep both sides of the road filled with traffic. This ties into the question of window sizes to allow the pipe to remain full. Of course, we're assuming the app is able to not let the network buffers flush out and have nothing left to send.

Tuning TCP for High Bandwidth-Delay Networks gives a concise technical explanation of the Long Fat Network issue with respect to the Bandwidth-Delay Product with some simple animations to illustrate the issue with keeping the pipe full in both directions!

Answer 2

There are a few reasons why connections to servers a long distance away are frequently slower than more local servers.

1. The sender doesn't know how many packets it can safely send into the channel at once. It has to guess based on the acknowledgements coming back from the destination. The higher the latency the longer it takes for the speed to settle down ot the available capacity.

2. Older versions of TCP had a hard limit on how much data could be "in flight" at one time. Later extensions raised this limit but some systems may not support them or may have a local hardcoded limit.

3. The more hops there are in the chain the more likely one of them is to have problems at any given time. Longer distances typically mean more hops.

4. Local traffic (especially in europe) is frequently passed directly from content provider to access provider over cheap peering links. Long distance traffic has to pass over more expensive transit links to major worldwide networks (often but not always teir 1 providers). If either the content or access provider is a cheapskate these links may be undersized.