For many tasks, delays between the client and the server are critical, for example, in online games, video / voice conferencing, IP telephony, VPN, etc. If the server is too far from the client at the IP network level, then delays (popularly "ping", "lag") will interfere with work.
The geographic proximity of a server does not always equal proximity at the routing IP level. So, for example, a server in another country may be "closer" to you than a server in your city. All because of the peculiarities of routing and networking.
How to choose a server as close as possible to all potential clients? What is IP connectivity? How to direct the client to the nearest server? Let's figure it out in the article.
Measuring delays
First, let's learn how to measure delays. This task is not as easy as it might seem, because delays can vary for different protocols and packet sizes. You may also miss short-term phenomena, such as dips lasting a few milliseconds.
ICMP - normal ping
We will use the Unix ping utility, it allows you to manually set the intervals between sending packets, which the windows version of ping cannot do. This is important, because if the pauses between packets are long, you can simply not see what happens between them.
Package size (option -s) β By default, the ping utility sends 64-byte packets. With such small packets, the phenomena that occur with large packets may not be noticeable, so we will set the packet size to 1300 bytes.
Interval between packets (option -i) β time between sending data. By default, packets are sent once per second, this is a very long time, real programs send hundreds and thousands of packets per second, so we set the interval to 0.1 second. Less simply does not allow the program.
As a result, the command looks like this:
ping -s 1300 -i 0.1 yandex.ru
This design allows you to see a more realistic picture of delays.
Ping over UDP and TCP
In some cases, TCP connections are handled differently than ICMP packets, and because of this, measurements may differ depending on the protocol. It also often happens that the host simply does not respond to ICMP, and a normal ping does not work. So, for example, the host does all his life microsoft.com.
Utility from the developers of the famous nmap scanner can generate any packets. It can also be used to measure latency.
Since UDP and TCP work on specific ones, we need to "ping" a specific port. Let's try to ping TCP 80, that is, the port of the web server:
$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44 seq=2876862274 win=64240 <mss 1398>
Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds
By default, nping sends 4 packets and stops. Option -c 0 turns on the endless sending of packets, to stop the program, you need to press Ctrl + C. Statistics will be shown at the end. We see that the average value of rtt (round-trip time) is 101ms.
MTR - traceroute on steroids
Program (Eng. My Traceroute) is an advanced utility for tracing routes to a remote host. Unlike the usual traceroute system utility (in windows it is the tracert utility), it can show delays to each host in the packet chain. It also knows how to trace routes not only via ICMP, but also via UDP and TCP.
$ sudo mtr microsoft.com
(Clickable) MTR program interface. Started traceroute to microsoft.com
MTR immediately shows the ping to each host in the chain, moreover, the data is constantly updated while the program is running and you can see short-term changes.
The screenshot shows that node #6 has packet loss, but in fact this is not entirely true, because some routers can simply discard packets with an expired TTL and not return an error response, so packet loss data can be ignored here.
WiFi vs cable
This topic is not exactly related to the article, but in my opinion it is very important in the context of delays. I really love WiFi, but if I have even the slightest opportunity to connect to the Internet with a cable, I will use it. Also, I always discourage people from using WiFi cameras.
If you play serious online shooters, stream video, trade on the stock exchange: please use the Internet by cable.
Here is a visual test to compare WiFi and cable connection. This is a ping to the WiFi router, that is, not even the Internet yet.
(Clickable) Comparison of ping to a WiFi router via cable and via WiFi
It can be seen that WiFi delays are 1ms longer and sometimes there are packets with ten times more delays! And this is only a short period of time. At the same time, the same router produces stable delays <1ms.
In the example above, WiFi 802.11n at 2.4GHz is used, only a laptop and a phone are connected to the access point via WiFi. If there were more clients on the access point, the results would be much worse. That is why I am so against the transfer of all office computers to WiFi, if it is possible to reach them with a cable.
IP connectivity
So, we have learned how to measure delays to the server, let's try to find the nearest server to us. To do this, we can look at how routing is arranged at our provider. To do this, it is convenient to use the service
When entering the site, we see that our IP address belongs to an autonomous system .
Looking at the autonomous systems connectivity graph, we can see through which upstream providers our provider is connected to the rest of the world. Each of the points is clickable, you can go in and read what kind of provider it is.
Connectivity graph of provider autonomous systems
Using this tool, you can study how the channels of any provider, including hosting, are arranged. See which providers it is connected directly to. To do this, you need to drive the IP address of the server into the bgp.he.net search and look at the graph of its autonomous system. You can also understand how one data center or hosting provider is related to another.
Most exchange points provide a special tool called looking glass that allows you to ping and traceroute from a specific router to the exchange point.
For example, from MGTS
So, when choosing a server, we can see in advance how it will look from different traffic exchange points. And if our potential clients are located in a certain geographical area, we can find the optimal location for the server.
Choose the nearest server
We decided to simplify the process of finding the best server for our clients and made a page with an automatic test of the nearest locations: .
When you visit the page, the script measures the delays from your browser to each server and displays them on an interactive map. When you click on the data center, information with test results is displayed.
The button leads to the latency test page to all our data centers. To view the test results, click on the data center point on the map
Source: habr.com