Борьба за миллисекунды. Как выбрать сервер с наименьшим пингом
Для многих задач задержки между клиентом и сервером критически важны, например в онлайн играх, видео/голосовых конференциях, IP телефонии, VPN и т.д. Если сервер будет слишком удален от клиента на уровне IP-сети, то задержки (в народе «пинг», «лаг») будут мешать работе.
Географическая близость сервера не всегда равна близости на уровне IP маршрутизации. Так например сервер в другой стране может быть «ближе» к вам, чем сервер в вашем городе. Все из-за особенностей маршрутизации и построения сетей.
Как выбрать сервер максимально близкий ко всем потенциальным клиентам? Что такое связность 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 от разработчиков знаменитого сканера 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
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
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
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 (англ. My Traceroute) — продвинутая утилита для тарссировки маршрутов до удаленного хоста. В отличии от обычной системной утилиты traceroute (в windows это утилита tracert), умеет показывать задержки до каждого хоста в цепочке следования пакета. Также умеет трассировать маршруты не только по ICMP, но и по UDP и TCP.
$ sudo mtr microsoft.com
(Кликабельно) Интерфейс программы MTR. Запущенна трассировка маршрута до microsoft.com
MTR сразу показывает пинг до каждого хоста в цепочке, при том данные постоянно обновляются, пока программа запущена и можно видеть кратковременные изменения.
На скриншоте видно, что на узле №6 есть потери пакетов, но на самом деле это не совсем так, потому как некоторые маршрутизаторы могут просто отбрасывать пакеты с истекшим TTL и не возвращать ответ с ошибкой, поэтому данные о потерях пакетов тут можно игнорировать.
WiFi против кабеля
Эта тема не совсем относится к статье, но на мой взгляд очень важна в контексте задержек. Я очень люблю WiFi, но если у меня есть хоть малейшая возможность подключиться кабелем к интернету, я ею воспользуюсь. Также я всегда отговариваю людей использовать WiFi камеры.
Если вы играете в серьезные онлайн-шутеры, вещаете потоковое видео, торгуете на бирже: пожалуйста, используйте интернет по кабелю.
Вот наглядный тест для сравнения WiFi и кабельного подключения. Это ping до WiFi роутера, то есть еще даже не интернет.
(Кликабельно) Сравнение ping до WiFi роутера по кабелю и по WiFi
Видно, что по WiFi задержки больше на 1 мс и иногда бывают пакеты с задержками в десять раз больше! И это только короткий отрезок времени. При этом тот же самый роутер выдает стабильные задержки <1мс.
В примере выше используется WiFi 802.11n на 2.4GHz, к точке доступа по WiFi подключен только ноутбук и телефон. Если бы на точке доступа было больше клиентов, результаты были бы сильно хуже. Именно поэтому я так против перевода всех офисных компьютеров на WiFi если есть возможность дотянуться до них кабелем.
IP связность
Итак мы научились измерять задержки до сервера, попробуем найти ближайший сервер к нам. Для этого можем посмотреть как устроена маршрутизация у нашего провайдера. Для этого удобно использовать сервис bgp.he.net
При заходе на сайт видим, что наш IP-адрес принадлежит автономной системе AS42610.
Посмотрев на граф связности автономным систем, можем увидеть через каких вышестоящих провайдеров наш провайдер связан с остальным миром. Каждая из точек кликабельна, можно зайти и почитать что это за провайдер.
Граф связности автономных систем провайдера
Используя этот инструмент можно изучить как устроены каналы любого провайдера, в том числе и хостинга. Посмотреть к каким провайдерам он подключен напрямую. Для этого нужно вбить в поиск bgp.he.net IP-адрес сервера и посмотреть на граф его автономной системы. Также можно понять как один датацентр или хостинг-провайдер связан с другим.
Большинство точек обмена обмена трафиком предоставляет специальный инструмент называемый looking glass, позволяющий выполнить ping и traceroute со стороны конкретного роутера на точке обмена.
Вот например, looking glass от МГТС
Так, выбирая сервер, мы можем заранее посмотреть как он будет выглядеть с разных точек обмена трафиком. И если наши потенциальные клиенты находятся в определенной географической зоне, мы можем найти оптимальную локацию для сервера.
Выбираем ближайший сервер
Мы решили упростить процедуру поиска оптимального сервера для наших клиентов и сделали страницу с автоматическим тестом ближайших локаций: дата-центры RUVDS.
При заходе на страницу скрипт измеряет задержки от вашего браузера до каждого сервера и отображает их на интерактивной карте. При клике на датацентр показывается информация с результатами тестов.
