Онлайн ping

Що ping вимірює і чого не вимірює

Ping надсилає вузлу невеликий ICMP Echo Request і засікає, скільки часу йде відповідь Echo Reply. Це весь механізм. Його описали 1981 року в RFC 792, а сам інструмент написали за вечір у грудні 1983-го — що дещо каже про те, як мало відтоді довелося міняти.

Число, яке він дає, — це час обігу: туди й назад, разом із часом, який дальній бік витратив на те, щоб помітити пакет і відповісти. Це не час завантаження сторінки, не міра пропускної здатності і не затримка в один бік — просто поділити навпіл не можна, бо шлях назад часто не збігається зі шляхом туди.

Одне варто розуміти до того, як читати будь-який результат на цій сторінці: перевірка йде з нашого сервера, а не з вашого комп'ютера. Вона вимірює маршрут між нашою мережею і вузлом, який ви назвали. Це саме те, що потрібно, коли питання звучить «чи доступний цей вузол з інтернету взагалі», і саме не те, коли питання звучить «чому в мене погане з'єднання»: для другого єдиний осмислений ping — той, який ви запустите самі, з машини, на якій проблема.

Як читати числа

Важать чотири значення, і люди зазвичай дивляться спершу не на те.

Затримка (мінімум і середнє)

Наскільки вузол далекий у мережевому сенсі. Беріть мінімум як чесну підлогу маршруту — це та спроба, у якій ніде нічого не стояло в черзі. Середнє показує, чого чекати на практиці.

Втрати пакетів

Найшкідливіше число з усіх. Будь-що більше за нуль до нормально утримуваного вузла потребує пояснення; кількох відсотків досить, щоб відеодзвінки затиналися, а передача файлів не виходила на швидкість, — бо втрати змушують TCP різко пригальмувати.

Джитер — розкид між мінімумом і максимумом

Для всього інтерактивного мінливість важить більше за саму затримку. Рівні 90 мс для голосового дзвінка комфортні; середні 40 мс, які стрибають від 10 до 300, — ні, бо приймальний бік мусить буферизувати під найгірший випадок.

TTL у відповіді

Узагалі не про час — і тихо корисний; про нього нижче.

Яка затримка нормальна

Тут є жорстка фізична підлога, і знати про неї варто, щоб перестати чекати неможливого. Світло в оптичному волокні йде приблизно на дві третини швидкості у вакуумі — близько 200 000 км за секунду, — тобто приблизно 1 мс затримки в один бік на кожні 100 км кабелю. А кабель ніколи не лежить по прямій.

• Менше 1 мс — та сама будівля або той самий дата-центр.
• 1–10 мс — те саме місто чи та сама регіональна мережа.
• 10–40 мс — та сама країна або сусідні країни.
• 70–120 мс — через океан. Лондон — Нью-Йорк фізично не може бути значно менше за 60 мс обігу, а 75–90 мс — добрий реальний результат.
• 150–300 мс — інший бік планети або маршрут, який дорогою заходить кудись несподівано.
• 500–700 мс — геостаціонарний супутниковий канал. Супутник висить на висоті 35 786 км; обіг угору-вниз двічі не вкладається менш ніж у приблизно 240 мс, а реальні канали дають помітно більше. Низькоорбітальні супутникові служби — інша річ, вони поводяться радше як 25–60 мс.

Якщо вузол у вашому ж місті відповідає за 120 мс, відстань цього не пояснює. Або трафік іде кругом — маршрути між сусідніми мережами інколи сходяться лише в іншій країні, — або десь на шляху затор.

Немає відповіді ≠ вузол лежить

Це найпоширеніше хибне прочитання результату, і воно коштує людям годин. Тайм-аут означає одну з кількох речей, і лише одна з них — «машина вимкнена»:

• ICMP фільтрують. Дуже багато вузлів і фаєрволів просто відкидають ехо-запити за політикою. Сервер за ними бездоганно віддає вебтрафік. Мовчання — це вибір у налаштуваннях, а не діагноз.
• Запит дійшов, а відповідь загубилася десь на зворотному шляху. Шляхи назад ламаються незалежно від шляхів туди.
• Маршрутизатор захищає себе. Мережеве обладнання обробляє ICMP програмно, а не швидким апаратним трактом, і навмисно обмежує, скільком воно відповість. Завантажений маршрутизатор відкине ваше ехо, пересилаючи при цьому гігабіти справжнього трафіку без жодної втрати.
• Вузол справді недосяжний. Можливо — і варто перевірити другим способом, перш ніж у це повірити.

Практичне правило: ping доводить досяжність, коли відповідає, і не доводить нічого, коли не відповідає. Якщо треба знати, чи служба працює, питайте службу — перевірте, чи приймає з'єднання її порт, або подивіться, що насправді віддає вебсервер. Вузол, який ігнорує ping і при цьому спокійно завершує TCP-рукостискання, не зламаний; він звичайний.

Поле TTL і що воно видає

Кожен пакет несе лічильник часу життя, який кожен маршрутизатор зменшує на одиницю, — тому пакет, що потрапив у петлю, зрештою вмирає, а не кружляє вічно. Операційні системи стартують із передбачуваних значень: 64 в Linux, macOS і більшості Unix-систем, 128 у Windows, 255 у чималої частини мережевого обладнання.

Відніміть побачений TTL від найближчого більшого стартового значення — і матимете кількість маршрутизаторів, які перетнула відповідь. TTL 57 означає старт із 64 і сім хопів. Це груба оцінка кількості хопів і груба підказка про операційну систему дальнього боку, отримані задарма, — і це подеколи найшвидший спосіб помітити, що трафік, який ви вважали місцевим, долає п'ятнадцять маршрутизаторів дорогою.

Затримка, пропускна здатність і те, що плутають

Затримка й пропускна здатність незалежні, а їхнє змішування стоїть за більшістю історій «ми збільшили канал, і це не допомогло». Пропускна здатність — скільки влазить у трубу за секунду; затримка — скільки часу йде одна річ. Супутниковий канал із величезною ємністю все одно має 600 мс затримки, а скромне з'єднання до близького сервера все одно відчувається миттєвим.

Що з двох вам важливе, залежить винятково від задачі. Завантажити великий файл — задача пропускної здатності. Голосовий дзвінок, віддалений робочий стіл, гра або сторінка, яка послідовно тягне сорок дрібних файлів, — усе це задачі затримки, бо кожен крок чекає на обіг, перш ніж рушити далі. Саме тому подвоєння швидкості каналу часто ніяк не змінює того, наскільки швидким відчувається сайт.

Є ще випадок, коли високий ping — узагалі не поломка: bufferbloat, роздуті черги. Коли канал зайнятий повністю — велике вивантаження, чиясь резервна копія, — пакети стоять у завеликих буферах, затримка йде в сотні мілісекунд, а пропускна здатність лишається чудовою. Якщо ping нормальний на вільній лінії й жахливий на завантаженій, це саме воно, і лікується воно керуванням чергами на вашому ж маршрутизаторі, а не чимось на тому боці.

Робочий порядок діагностики

1. Пінгуйте пункт призначення. Відповідь із притомною затримкою і без втрат означає, що мережевий шлях справний, а проблема вища за нього — у застосунку.
2. Пінгуйте щось свідомо справне поруч — великий публічний сайт. Якщо й до нього повільно або з втратами, справа у вашому боці, а не в пункті призначення.
3. Порівняйте звідкись іще. Запустіть перевірку на цій сторінці, з нашої мережі, до того самого вузла. Якщо в нас чисто, а у вас ні — різниця лежить на вашому шляху: провайдер, лінія, обладнання.
4. Перевіряйте службу, а не лише вузол. Вузол, що відповідає, з мертвою службою виглядає для ping точнісінько як здоровий.
5. Подивіться, у що розв'язується ім'я. Повільні або хибні відповіді часто є проблемою DNS, яку діагностували як мережеву, — а адреса, яку ви пінгуєте, може бути не тією, якою користується застосунок.

Чому ця перевірка обмежена навмисно

Ми надсилаємо невелику кількість пакетів, по одному на секунду, і зупиняємось. Цього досить, щоб побачити затримку, джитер і втрати, і цього свідомо недосить, щоб бути корисним тому, хто хоче спрямувати трафік на когось іншого. Приватні й зарезервовані діапазони відхиляються одразу: адреса всередині вашої мережі з нашої недосяжна за визначенням, тож перевірка до неї могла б дати лише оманливий результат.