Борьба за миллисекунды. Как выбрать сервер с наименьшим пингом

Для многих задач задержки между клиентом и сервером критически важны, например в онлайн играх, видео/голосовых конференциях, IP телефонии, VPN и т.д. Если сервер будет слишком удален от клиента на уровне IP-сети, то задержки (в народе «пинг», «лаг») будут мешать работе.

Географическая близость сервера не всегда равна близости на уровне IP маршрутизации. Так, например, сервер в другой стране может быть «ближе» к вам, чем сервер в вашем городе. Все из-за особенностей маршрутизации и построения сетей.

^[1]

Как выбрать сервер максимально близкий ко всем потенциальным клиентам? Что такое связность IP-сетей? Как направить клиента на ближайший сервер? Разберемся в статье.

Измеряем задержки

Для начала научимся измерять задержки. Эта задача не так проста, как может показаться, потому что для разных протоколов и размеров пакета задержки могут отличаться. Также можно не заметить кратковременные явления, например провалы продолжительностью в несколько миллисекунд.

ICMP — обычный ping

Будем использовать юниксовую утилиту ping, она позволяет вручную установить интервалы между посылками пакетов, чего не умеет версия ping для windows. Это важно, потому что, если паузы между пакетами долгие, можно просто не увидеть, что происходит между ними.

Размер пакета (опция -s) — по умолчанию утилита ping посылает пакеты размером 64 байта. С такими маленькими пакетами могут быть не заметны явления, проявляющиеся с большими пакетами, поэтому мы будет устанавливать размер пакета 1300 байт.

Интервал между пакетами (опция -i) — время между посылками данных. По умолчанию пакеты посылаются раз в секунду, это очень долго, реальные программы шлют сотни и тысячи пакетов в секунду, поэтому установим интервал 0.1 секунду. Меньше просто не разрешает программа.

В итоге команда выглядит так:

ping -s 1300 -i 0.1 yandex.ru

Такая конструкция позволяет увидеть более реалистичную картину задержек.

Пинг по UDP и TCP

В некоторых случаях, TCP-подключения обрабатываются не так, как ICMP пакеты, и из-за этого замеры могут отличаться в зависимости от протокола. Также часто бывает, что хост просто не отвечает на ICMP, и обычный пинг не работает. Так, например, всю жизнь делает хост microsoft.com.

Утилита nping ^[2] от разработчиков знаменитого сканера nmap умеет генерировать любые пакеты. Ее можно использовать в том числе для измерения задержек.
Так как UDP и TCP работают на определенных, нам нужно «пинговать» конкретный порт. Попробуем пропинговать TCP 80, то есть порт веб-сервера:

$ 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

По умолчанию nping посылает 4 пакета и останавливается. Опция -c 0 включает бесконечную посылку пакетов, чтобы остановить программу, нужно нажать Ctrl+C. В конце будет показана статистика. Видим, что среднее значение rtt (round-trip time) равно 101мс.

MTR — traceroute на стероидах

Программа MTR ^[3](англ. My Traceroute) — продвинутая утилита для трассировки маршрутов до удаленного хоста. В отличии от обычной системной утилиты traceroute (в windows это утилита tracert), умеет показывать задержки до каждого хоста в цепочке следования пакета. Также умеет трассировать маршруты не только по ICMP, но и по UDP и TCP.

$ sudo mtr microsoft.com

^{[4]
(Кликабельно) Интерфейс программы MTR. Запущенна трассировка маршрута до microsoft.com}

MTR сразу показывает пинг до каждого хоста в цепочке, притом данные постоянно обновляются, пока программа запущена и можно видеть кратковременные изменения.
На скриншоте видно, что на узле №6 есть потери пакетов, но на самом деле это не совсем так, потому как некоторые маршрутизаторы могут просто отбрасывать пакеты с истекшим TTL и не возвращать ответ с ошибкой, поэтому данные о потерях пакетов тут можно игнорировать.

WiFi против кабеля

Эта тема не совсем относится к статье, но на мой взгляд очень важна в контексте задержек. Я очень люблю WiFi, но, если у меня есть хоть малейшая возможность подключиться кабелем к интернету, я ею воспользуюсь. Также я всегда отговариваю людей использовать WiFi камеры.
Если вы играете в серьезные онлайн-шутеры, вещаете потоковое видео, торгуете на бирже: пожалуйста, используйте интернет по кабелю.

Вот наглядный тест для сравнения WiFi и кабельного подключения. Это ping до WiFi роутера, то есть еще даже не интернет.

^{[5]
(Кликабельно) Сравнение ping до WiFi роутера по кабелю и по WiFi}

Видно, что по WiFi задержки больше на 1мс и иногда бывают пакеты с задержками в десять раз больше! И это только короткий отрезок времени. При этом тот же самый роутер выдает стабильные задержки <1мс.

В примере выше используется WiFi 802.11n на 2.4GHz, к точке доступа по WiFi подключен только ноутбук и телефон. Если бы на точке доступа было больше клиентов, результаты были бы сильно хуже. Именно поэтому я так против перевода всех офисных компьютеров на WiFi, если есть возможность дотянуться до них кабелем.

IP связность

Итак, мы научились измерять задержки до сервера, попробуем найти ближайший сервер к нам. Для этого можем посмотреть, как устроена маршрутизация у нашего провайдера. Для этого удобно использовать сервис bgp.he.net ^[6]

При заходе на сайт видим, что наш IP-адрес принадлежит автономной системе AS42610 ^[7].

Посмотрев на граф связности автономным систем, можем увидеть через каких вышестоящих провайдеров наш провайдер связан с остальным миром. Каждая из точек кликабельна, можно зайти и почитать, что это за провайдер.

^{Граф связности автономных систем провайдера}

Используя этот инструмент можно изучить, как устроены каналы любого провайдера, в том числе и хостинга ^[8]. Посмотреть к каким провайдерам он подключен напрямую. Для этого нужно вбить в поиск bgp.he.net IP-адрес сервера и посмотреть на граф его автономной системы. Также можно понять, как один датацентр или хостинг-провайдер ^[8] связан с другим.

Большинство точек обмена обмена трафиком предоставляют специальный инструмент, называемый looking glass, позволяющий выполнить ping и traceroute со стороны конкретного роутера на точке обмена.

Вот, например, looking glass ^[9] от МГТС

Так, выбирая сервер, мы можем заранее посмотреть как он будет выглядеть с разных точек обмена трафиком. И если наши потенциальные клиенты находятся в определенной географической зоне, мы можем найти оптимальную локацию для сервера.

Выбираем ближайший сервер

Мы решили упростить процедуру поиска оптимального сервера для наших клиентов и сделали страницу с автоматическим тестом ближайших локаций: дата-центры RUVDS ^[10].
При заходе на страницу скрипт измеряет задержки от вашего браузера до каждого сервера и отображает их на интерактивной карте. При клике на датацентр показывается информация с результатами тестов.

^[10]

Кнопка ведет на страницу теста задержек до всех наших датацентров. Чтобы посмотреть результаты тестирования нажмите на точку датацентра на карте

Автор: ruvds

Источник ^[11]