Для багатьох завдань затримки між клієнтом та сервером критично важливі, наприклад, в онлайн іграх, відео/голосових конференціях, 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.
Утиліта від розробників знаменитого сканера 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 пакети та зупиняється. Опція -с 0 включає нескінченну посилку пакетів, щоб зупинити програму, потрібно натиснути Ctrl+C. Наприкінці буде показано статистику. Бачимо, що середнє значення rtt (round-trip time) дорівнює 101мс.
MTR - traceroute на стероїдах
Програма (англ. My Traceroute) - просунута утиліта для трасування маршрутів до віддаленого хоста. На відміну від звичайної системної утиліти traceroute (у windows це утиліта tracert), вміє показувати затримки до кожного хоста в ланцюжку проходження пакета. Також вміє трасувати маршрути не тільки ICMP, але і UDP і TCP.
$ sudo mtr microsoft.com
(Клікабельно) Інтерфейс програми MTR. Запущено трасування маршруту до microsoft.com
MTR відразу показує пінг до кожного хоста в ланцюжку, причому дані постійно оновлюються, поки програма запущена і можна бачити короткочасні зміни.
На скріншоті видно, що на вузлі №6 є втрати пакетів, але насправді це не зовсім так, тому що деякі маршрутизатори можуть просто відкидати пакети з TTL і не повертати відповідь з помилкою, тому дані про втрати пакетів тут можна ігнорувати.
WiFi проти кабелю
Ця тема не зовсім відноситься до статті, але, на мій погляд, дуже важлива в контексті затримок. Я дуже люблю WiFi, але, якщо я маю хоч найменшу можливість підключитися кабелем до інтернету, я нею скористаюся. Також я завжди відмовляю людей використовувати WiFi камери.
Якщо ви граєте в серйозні онлайн-шутери, мовите потокове відео, торгуєте на біржі: будь ласка, використовуйте інтернет кабелем.
Ось наочний тест для порівняння WiFi та кабельного підключення. Це ping до Wi-Fi роутера, тобто ще навіть не інтернет.
(Клікабельно) Порівняння ping до WiFi роутера по кабелю та по WiFi
Видно, що WiFi затримки більше на 1мс і іноді бувають пакети із затримками в десять разів більше! І це лише короткий час. При цьому той же роутер видає стабільні затримки <1мс.
У прикладі вище використовується WiFi 802.11n на 2.4GHz, до точки доступу WiFi підключений тільки ноутбук і телефон. Якби на точці доступу було більше клієнтів, результати були б гіршими. Саме тому я проти перекладу всіх офісних комп'ютерів на WiFi, якщо є можливість дотягнутися до них кабелем.
IP зв'язність
Отже, ми навчилися вимірювати затримки сервера, спробуємо знайти найближчий сервер до нас. Для цього можемо подивитися, як влаштовано маршрутизацію у нашого провайдера. Для цього зручно використовувати сервіс
При заході на сайт бачимо, що наша IP-адреса належить автономній системі .
Подивившись на граф зв'язності автономним систем, можемо побачити через яких вищих провайдерів наш провайдер пов'язаний з рештою світу. Кожна з точок клікабельна, можна зайти та почитати, що це за провайдер.
Граф зв'язності автономних систем провайдера
Використовуючи цей інструмент, можна вивчити, як влаштовані канали будь-якого провайдера, у тому числі і хостингу. Подивитися до яких провайдерів він безпосередньо підключений. Для цього потрібно вбити в пошук IP-адресу сервера bgp.he.net і подивитися на граф його автономної системи. Також можна зрозуміти, як один датацентр чи хостинг-провайдер пов'язаний з іншим.
Більшість точок обміну трафіком надають спеціальний інструмент, званий, looking glass, що дозволяє виконати ping та traceroute з боку конкретного роутера на точці обміну.
Ось наприклад, від МГТС
Так, вибираючи сервер, ми можемо заздалегідь подивитися, як він виглядатиме з різних точок обміну трафіком. І якщо наші потенційні клієнти знаходяться у певній географічній зоні, ми можемо знайти оптимальну локацію для сервера.
Вибираємо найближчий сервер
Ми вирішили спростити процедуру пошуку оптимального сервера для наших клієнтів та зробили сторінку з автоматичним тестом найближчих локацій: .
Під час заходу на сторінку скрипт вимірює затримки від вашого браузера до кожного сервера та відображає їх на інтерактивній карті. При натисканні на датацентр показується інформація з результатами тестів.
Кнопка веде до сторінки тесту затримок до всіх наших датацентрів. Щоб переглянути результати тестування, натисніть на точку датацентру на карті
Джерело: habr.com