company_banner

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

    Для многих задач задержки между клиентом и сервером критически важны, например в онлайн играх, видео/голосовых конференциях, 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 <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 (англ. My Traceroute) — продвинутая утилита для трассировки маршрутов до удаленного хоста. В отличии от обычной системной утилиты traceroute (в windows это утилита tracert), умеет показывать задержки до каждого хоста в цепочке следования пакета. Также умеет трассировать маршруты не только по ICMP, но и по UDP и TCP.

    $ sudo mtr microsoft.com


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

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

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



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

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

    image
    (Кликабельно) Сравнение 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.
    При заходе на страницу скрипт измеряет задержки от вашего браузера до каждого сервера и отображает их на интерактивной карте. При клике на датацентр показывается информация с результатами тестов.





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

    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR

    Комментарии 13

      +2

      Вот бы еще автоматический тест на блокировки во всяких роскомнадзорах, спамхаусах и прочих блеклистах. А то бывает купишь сервер, а IP уже зашкварен прошлым владельцем.

        +3

        Я в таком случае просто удаляю и создаю сервер заново, обычно IP уже другой. Жаль только не получается такое с cloudflare.

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

        Это не совсем верная формулировка. Так выглядит интернет с точки зрения бордера Hurricane Electric, что, в общем случае, не совпадает с тем, как устроена маршрутизация у вашего провайдера, как минимум там не будет видно никаких приватных пиринговых стыков. Так же важно понимать, что там видно, как будут выходить пакеты из автономной сети, а не как они будут в неё приходить. Так же там присутствуют только автономные сети, что там происходит внутри эти автономных сетей — неизвестно. И traceroute тоже не особо много покажет, потому что у многих провайдеров используется MPLS внутри сети.
          0
          Трассировка маршрута к rusm9-ping-test.ruvds.com [213.226.114.65]
          с максимальным числом прыжков 30:

          1 <1 мс <1 мс <1 мс 192.168.1.1
          2 9 ms 8 ms 16 ms 001.128.133.79.chtts.ru [79.133.128.1]
          3 7 ms 7 ms 7 ms 188.254.2.46
          4 48 ms 48 ms 48 ms ae40.stkm-cr4.intl.ip.rostelecom.ru [217.107.67.31]
          5 49 ms 49 ms 49 ms s-b5-link.telia.net [62.115.168.242]
          6 52 ms 52 ms 52 ms s-bb3-link.telia.net [62.115.142.216]
          7 49 ms 49 ms 54 ms s-b10-link.telia.net [62.115.119.15]
          8 71 ms 69 ms 72 ms retnbaltic-ic-344425-s-b10.c.telia.net [62.115.174.227]
          9 59 ms 60 ms 60 ms ae4-9.RT.M9.MSK.RU.retn.net [87.245.233.69]
          10 59 ms 59 ms 60 ms ae0-1.RT1.M9.MSK.RU.retn.net [87.245.233.21]
          11 62 ms 58 ms 59 ms 213.226.114.65


          До того что в бункере 30мс, без Европы. p.s. статью не читал.
            0

            Особенно проблемы с WiFi в человейниках, когда у тебя в списке светится десяток соседских точек. С дешёвым маршрутизатором получить сколько-нибудь стабильное соединение вообще не реально. Там не только пинг большой, но и потери пакетов постоянные.

              0
              А если мне нужно выбрать сервер с лучшим пингом не ко мне а к другому серверу, к которому я не имею непосредственного доступа, что бы пинговать всех провайдеров из его подсети? Остается только купить по тестовому серверу у каждого провайдера, что бы померять?
                +1
                ruvds не облокатился никуда, немецкий сервак, никаких ограничений, пинг 30, в игры не играю, у меня все
                  0
                  В отличии от обычной системной утилиты traceroute (в windows это утилита tracert), умеет показывать задержки до каждого хоста в цепочке следования пакета.

                  У Винды кроме tracert есть ещё и pathping
                    0

                    В ближайшей убунте:


                    ping -s 1300 -i 0.1 yandex.ru

                    даёт


                    ping: cannot flood; minimal interval allowed for user is 200ms

                    (конечно, 0.2 работает, конечно статья хорошая — просто момент, что не описано окружение, в котором проверяли)

                    0

                    del

                      0
                      HE.net не видит (и вряд ли может видеть — смотря откуда инфу черпает, есть подозрение что из своего Full View) пиринговые стыки типа MSK-IX. А это в корне меняет дело с доступностью абонентов. Надо больше LG.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое