Why the closest geographical path on the internet isn't always the fastest

From time to time, we get asked why we route a certain country or region to a PoP that's not geographically closest to the end-user. After all, that's what CDNs are all about, accelerating content and caching on the edge.

The answer is pretty simple, but to understand the problem better, let's look at how the internet works. In a very simplified manner, the internet is a collection of fiber, wires and networking equipment connected to each other around the world.

Different internet providers in different countries have different connections between each other and even in a case where there is a potential connection between two regions, there is a chance that the ISP might not have access to that connection.

This can be nicely illustrated with the global submarine cable map provided by submarinecablemap.com:

For example, even though Brazil is geographically quite close to Africa, there's actually a very limited connectivity between these two regions and there's a high chance a connection from Brazil would first need to reach North America, then Europe and only then be on it's way to Africa.

To illustrate this in action, here's a network path from our Sao Paulo PoP going to our PoP in Lagos. It's first stopping for some sightseeing in New York, then visiting London for a bit. Only after over 142.5ms the first packets will reach their destination after travelling thousands of kilometers around the world:

traceroute -I 102.129.144.45
traceroute to 102.129.144.45 (102.129.144.45), 30 hops max, 60 byte packets
 1  * * *
 2  10.10.0.2 (10.10.0.2)  0.387 ms  0.400 ms  0.401 ms
 3  172.30.30.9 (172.30.30.9)  0.619 ms  0.857 ms  0.867 ms
 4  10ge0-1.core3.sao1.he.net (184.105.65.230)  127.126 ms  126.937 ms  127.131 ms
 5  100ge8-1.core1.nyc4.he.net (184.104.195.21)  126.928 ms  126.959 ms  127.166 ms
 6  100ge7-1.core1.lon2.he.net (72.52.92.165)  192.323 ms  192.363 ms  192.365 ms
 7  hurricane-ic-129713-ldn-b5.c.telia.net (213.248.93.82)  192.482 ms  192.772 ms  192.720 ms
 8  west-indian-ocean-cable-company-ltd.10gigabitethernet5-3.core1.lon3.he.net (184.104.202.194)  193.320 ms  192.022 ms  192.094 ms
 9  154.66.247.99 (154.66.247.99)  192.653 ms  193.109 ms  193.116 ms
10  154.66.247.147 (154.66.247.147)  284.804 ms  284.856 ms  284.803 ms
11  102.134.18.2 (102.134.18.2)  285.115 ms  285.080 ms  285.084 ms
12  102.129.144.45 (102.129.144.45)  285.081 ms  285.080 ms  285.069 ms

While this is an extreme example to illustrate the problem, the same issue happens regularly in real-world scenarios between different countries and regions. This happens especially often in less developed regions where many datacenters are connected in a way that they're only really useful to serve a single country.

The good news is that most network administrators are well aware of these problems. At bunny.net, we are constantly monitoring network routes and optimizing both the carrier selection and the routing itself to make sure we're always serving the end-user with the most optimal path.

In some regions like Singapore, we actually opened multiple PoPs with a different networking blend to ensure we can serve content as effectively as possible for nearby countries. As another example, we can also have a look at our recently opened PoP in Nigeria, which is configured to only serve users from within the country to avoid any long holiday trips like the example above. Nearby countries such as Ghana or Mali are on the other hand served by our Madrid or Paris PoP that are much better connected for these regions.

So if you ever wonder why you're being routed to a specific location that might not seem like the ideal destination at first, there's a high chance it simply offers a better route for your specific ISP.

Of course, no system is perfect and networks are changing day to day. While we do our best to stay on top of everything, don't be afraid to let us know something is off and our team will make sure to look into it.

Are you curious about routing yourself? Run a traceroute to bunny.net and see this in action.