Як виміряти затримку мережі: практичний посібник для розробників

Хочете виміряти затримку в мережі? Ви можете почати з простих вбудованих інструментів командного рядка, таких як ping та traceroute, щоб швидко отримати дані про Час кругового проходження (RTT). Або ж ви можете відкрити інструменти розробника у вашому браузері, щоб побачити, як затримки впливають на те, що насправді відчувають ваші користувачі.

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

Чому вимірювання затримки є обов'язковим

Перед тим, як перейти до "як", давайте поговоримо про "чому". Для розробників та мережевих інженерів затримка — це не просто число на екрані; це невидима рука, що формує весь досвід користувача. У сучасних додатках мілісекунди мають величезне значення. Навіть невелика затримка може стати різницею між сервісом, що відчувається миттєвим, і таким, що здається зламаним.

Подумайте про реальні наслідки:

• Відповідність API: Одна повільна API-виклик може створити ефект доміно, затримуючи все — від завантаження профілю користувача до обробки критичного платежу.
• Потоки даних в реальному часі: Для онлайн-ігор, живого відео або фінансових торгів низька та стабільна затримка є абсолютною основою. Без неї ці додатки просто не працюють.
• Утримання користувачів: Існує пряма залежність між повільно завантажуваними веб-сайтами та додатками і вищими показниками відмов та покинутих кошиків. Це серйозно впливає на прибуток.

Визначення ключових понять затримки

Щоб точно виміряти затримку в мережі, ви повинні знати, на що дивитесь. Два найосновніші поняття — це Час кругового проходження (RTT) та одностороння затримка.

RTT — це загальний час, який потрібен сигналу, щоб пройти від точки A до точки B і назад. Це найпоширеніший показник, який ви побачите, оскільки його легко виміряти — вам потрібно лише мати доступ до одного кінця з'єднання.

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

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

Щоб навести деякі цифри, експерти з моніторингу мережі зазвичай класифікують затримку так:

• Низька затримка: Менше 50 мілісекунд
• Помірна затримка: 50-150 мс
• Висока затримка: Понад 150 мс

З мого досвіду, швидкий тест до сусіднього сервера може показати цілком прийнятні 20-40 мс. Але це число може легко зрости до понад 200 мс для трафіку, який повинен перетнути океан, що може стати вирішальним для продуктивності вашого додатку.

Щоб зрозуміти жаргон, з яким ви зіткнетеся, ось швидка довідка.

Ключові поняття затримки на один погляд

Поняття	Що вимірює	Чому це важливо
Затримка (Ping)	Час, необхідний для того, щоб один пакет даних подолав шлях від джерела до призначення і назад. Вимірюється в мілісекундах (мс).	Це сирий показник затримки. Низька затримка є критично важливою для реальних додатків, таких як ігри, VoIP та відеоконференції.
Час кругового проходження (RTT)	По суті те ж саме, що і затримка, це загальна тривалість для відправлення сигналу плюс час для отримання підтвердження.	RTT є найпоширенішим і практичним способом вимірювання затримки з однієї точки, що робить його основним показником для таких інструментів, як ping.
Одностороння затримка	Час, необхідний для того, щоб пакет подолав шлях від джерела до призначення в одному напрямку.	Надає більш детальний погляд, особливо для асиметричних мереж, де шляхи завантаження та завантаження мають різні затримки.
Джиттер	Варіація затримки з часом. Вимірює непостійність часу прибуття пакетів.	Високий джиттер є таким же поганим, як і висока затримка для потокового медіа та онлайн-дзвінків, викликаючи затримки, буферизацію та збої.
Пропускна здатність	Максимальна кількість даних, яка може бути передана через мережеве з'єднання за певний проміжок часу. Вимірюється в Мбіт/с або Гбіт/с.	Часто плутають зі швидкістю, пропускна здатність стосується ємності. Ви можете мати високу пропускну здатність, але все ще страждати від високої затримки.

Ці поняття є основою для розуміння будь-якої проблеми з продуктивністю мережі.

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

Занурення в інструменти затримки командного рядка

Щоб дійсно відчути продуктивність вашої мережі, вам потрібно відкрити термінал. Командний рядок — це місце, де ви знайдете основні інструменти, які надають вам сирі, нефільтровані дані про ваше з'єднання. Це про те, щоб побачити, що насправді відбувається з пакетами, що переміщуються між вами та призначенням, і це є важливим першим кроком для будь-якого розробника, який серйозно ставиться до вимірювання затримки.

Класичний, основний інструмент — це ping. Він надзвичайно простий: відправляє маленький пакет даних (запит ICMP echo) на сервер і просто чекає, поки він повернеться. Цей простий круговий маршрут є основою для обчислення Часу кругового проходження (RTT) і надає вам миттєву перевірку стану з'єднання.

Ваш перший перевірка затримки з Ping

Запустити тест ping не може бути простіше. Відкрийте термінал або командний рядок, введіть ping і додайте домен, який ви хочете протестувати.

За замовчуванням ping буде працювати безкінечно на macOS та Linux, тоді як Windows відправляє лише чотири пакети і зупиняється. Для будь-якого реального аналізу вам потрібно буде контролювати це. Відправка десяти або двадцяти пакетів надає вам набагато надійнішу картину стабільності з'єднання, ніж просто кілька.

Коли тест завершиться, ви отримаєте акуратне резюме з важливими цифрами:

• Передані/отримані пакети: Це говорить вам, чи були втрачені дані під час передачі. Навіть невелика втрата пакетів є серйозним сигналом проблеми з мережею.
• Мін/середнє/макс/середнє відхилення: Це ваші основні статистичні дані затримки. Ви отримуєте найкращий час (min), середнє (avg) і найгірший випадок (max). mdev (середнє відхилення) — це ваш показник джиттера — наскільки затримка варіюється від одного пакета до наступного.

Уважно зверніть увагу на різницю між вашими мінімальними та максимальними RTT. Якщо вона велика, ваше з'єднання нестабільне, навіть якщо середнє виглядає нормально. Цей джиттер може бути набагато більш руйнівним для реальних додатків, таких як відеодзвінки або ігри, ніж з'єднання, яке постійно трохи повільне.

Звичайна помилка — це просто поглянути на середній RTT. Середнє значення 50 мс може здаватися нормальним, але якщо ваше мінімальне значення 20 мс, а максимальне — 250 мс, досвід користувача буде відчуватися ривками та ненадійно. Завжди дивіться на весь діапазон, щоб зрозуміти джиттер.

Слідуючи за маршрутом з Traceroute та MTR

Отже, що робити, коли ping виявляє високу затримку або втрату пакетів? Ваше наступне завдання — з'ясувати де проблема. Для цього призначений traceroute (або tracert на Windows). Він відображає весь шлях, яким проходять ваші пакети, показуючи кожен "стрибок" — кожен маршрутизатор — між вашим комп'ютером і кінцевим призначенням.

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

Але traceroute — це одноразовий знімок. Для більш динамічного, безперервного погляду більшість мережевих професіоналів, яких я знаю, клянуться в MTR (My Traceroute). MTR — це як суперзаряджений інструмент, який поєднує ping та traceroute. Він постійно відправляє пакети до кожного стрибка на маршруті, надаючи вам живий, оновлювальний погляд на затримку та втрату пакетів на кожній точці. Це робить його надзвичайно ефективним для виявлення періодичних проблем, які один traceroute ймовірно пропустить.

Чому ваш вибір інструмента важливий

Інструмент, який ви обираєте, і те, як ви його налаштовуєте, можуть суттєво змінити ваші результати. Це особливо вірно в ультра-швидких, низькозатриманих середовищах, таких як хмарні дата-центри.

Це насправді досить відкриваюче, наскільки різними можуть бути цифри. У детальному експерименті, проведеному Google Cloud, стандартний тест ping показав середній RTT 146 мікросекунд. Але коли вони використовували інший інструмент, який відправляє транзакції один за одним без паузи, RTT знизився до всього лише 66.59 мікросекунд — більше ніж удвічі швидше!

Це ідеальний приклад того, чому ping іноді може переоцінювати затримку. Це показує, що розуміння як працює інструмент є критично важливим для отримання вимірювань, яким ви можете довіряти.

Визначення максимальної швидкості вашого з'єднання з iperf

Затримка не завжди є повною картиною. Іноді вам потрібно знати максимальну кількість даних, яку ваше з'єднання може насправді пропустити — його пропускну здатність. Для цього вам потрібен інструмент iperf.

Поки ping вимірює затримку, iperf зосереджується на пропускній здатності. Він працює, налаштовуючи з'єднання клієнт-сервер, а потім передаючи якомога більше даних між ними протягом певного часу.

Щоб використовувати iperf, вам знадобляться дві машини:

1. На одній машині ви запускаєте iperf в серверному режимі. Він просто сидітиме і чекатиме на з'єднання.
2. На іншій машині ви запускаєте iperf в клієнтському режимі, вказуючи адресу сервера.

Клієнт підключиться, і тест почнеться. Вихідні дані повідомлять вам загальну кількість переданих даних і, що найважливіше, швидкість передачі (ваша пропускна здатність) в мегабітах або гігабітах на секунду. Це ідеальний спосіб протестувати мережеве з'єднання та дізнатися, на що воно насправді здатне.

Вимірювання затримки з точки зору користувача

Хоча інструменти командного рядка надають вам сирий, нефільтрований погляд на вашу мережу, єдина затримка, яка насправді має значення для веб-додатку, — це те, що насправді відчуває кінцевий користувач. Ось тут ми переключаємо нашу увагу з терміналу на сам браузер. Те, що відбувається всередині браузера, розповідає набагато багатшу, більш релевантну історію про продуктивність.

Це ніколи не просто про один круговий маршрут пакета. Затримка, яку користувач відчуває, є складним коктейлем з DNS-запитів, TCP-рукопожатій, TLS-угод, часу обробки сервера і, звичайно, часу, необхідного для фактичного відображення вмісту на екрані. На щастя, сучасні браузери постачаються з потужними вбудованими інструментами, які допомагають нам розібратися в цьому всьому процесі.

Занурення в інструменти розробника браузера

Кожен великий браузер — Chrome, Firefox, Edge, Safari — постачається з набором інструментів розробника. Вкладка "Мережа" в цих інструментах є вашим командним центром для розуміння того, як завантажується ваш сайт. Вона викладає все в графіку водоспаду, який є візуальним розподілом кожного запиту, який браузер робить для відображення сторінки.

Цей вигляд водоспаду є безцінним. Ви можете точно побачити, скільки часу знадобилося для завантаження кожного активу, від початкового HTML-документа та CSS-стилів до зображень і API-викликів. Що ще важливіше, він розбиває життєвий цикл кожного запиту на окремі фази:

• DNS-запит: Час, необхідний для перетворення доменного імені на IP-адресу.
• Початкове з'єднання: Час, витрачений на встановлення TCP-з'єднання з сервером.
• SSL/TLS-рукопожаття: Накладні витрати, необхідні для налаштування безпечного з'єднання.
• Час до першого байта (TTFB): Це дуже важливо. Він вимірює, як довго браузер чекав, перш ніж отримати перший байт даних від сервера.
• Завантаження вмісту: Час, витрачений на фактичне завантаження ресурсу.

Високий TTFB, наприклад, є класичним знаком повільного бекенду або проблеми з обробкою на стороні сервера — те, що простий тест ping ніколи не виявить. Аналізуючи цей водоспад, ви можете швидко виявити, які ресурси блокують відображення або просто займають занадто багато часу для завантаження.

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

Програмне вимірювання за допомогою Timing API

Для більш автоматизованих і точних вимірювань ви можете скористатися вбудованими JavaScript API браузера. Navigation Timing API та Resource Timing API надають вам програмний доступ до тих же детальних даних про продуктивність, які ви бачите в інструментах розробника. Це ідеально підходить для збору даних моніторингу реальних користувачів (RUM), щоб зрозуміти, як ваш сайт працює для реальних відвідувачів по всьому світу.

Ви можете отримати ці метрики всього за кілька рядків JavaScript, прямо в консолі браузера. Щоб отримати основні показники продуктивності для основного завантаження сторінки, наприклад, ви можете використовувати performance.getEntriesByType('navigation'). Це повертає об'єкт, наповнений цінними часовими мітками.

З цих даних ви можете обчислити важливі метрики:

• Час DNS-запиту: domainLookupEnd - domainLookupStart
• Час рукопожаття TCP: connectEnd - connectStart
• Час до першого байта (TTFB): responseStart - requestStart
• Загальний час завантаження сторінки: loadEventEnd - startTime

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

Спрощення перевірок за допомогою інтегрованих інструментів

Перемикання між терміналом, інструментами розробника браузера та власними скриптами може швидко набриднути. Тут інтегровані розширення браузера можуть дійсно полегшити ваш робочий процес, об'єднуючи ці перевірки. Наприклад, набір ShiftShift Extensions включає вбудований інструмент Speed Test, який ви можете відкрити миттєво з будь-якої вкладки.

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

Як спроектувати тест на затримку, який дійсно щось говорить

Кожен може виконати команду ping і отримати число у відповідь. Але якщо ви хочете дані, яким ви дійсно можете довіряти — дані, які допоможуть вам приймати реальні рішення — вам потрібно бути більш обережним. Одна, ізольована вимірювання — це лише моментальний знімок у часі. Щоб дійсно зрозуміти поведінку вашої мережі, ви повинні думати як детектив, враховуючи, звідки ви тестуєте, як часто ви тестуєте і що ви насправді шукаєте.

Добре спроектований тест перетворює сирі дані на дієві інсайти. Погано спроектований? Це просто шум.

Діаграма нижче розкриває всі маленькі затримки, які складаються в те, що користувач відчуває, коли завантажує веб-сторінку. Це чудове нагадування про те, що простий мережевий ping навіть не починає розповідати всю історію.

Як ви можете бачити, від початкового DNS-запиту до фінального рендерингу, кілька етапів сприяють загальному часу очікування.

Вибір ваших тестових кінцевих точок

Перше правило надійного тестування — це те, що географія має значення. Тест з вашого офісу в Нью-Йорку до сервера неподалік у Нью-Джерсі абсолютно нічого не говорить про досвід ваших клієнтів у Токіо. Щоб отримати реалістичну картину, ви повинні тестувати з різних місць, які насправді відображають вашу базу користувачів.

Ваш список кінцевих точок повинен охоплювати кілька ключових областей:

• Ваші найбільші центри користувачів: Де живе більшість ваших клієнтів? Тестуйте звідти.
• Міжконтинентальні маршрути: Подивіться, що відбувається, коли дані повинні перетнути океан. Тестуйте між Європою та Північною Америкою або Азією та США, щоб зрозуміти продуктивність на великі відстані.
• Ваші регіони хмари: Якщо ви на AWS, Azure або GCP, тестуйте з'єднання до і між конкретними регіонами дата-центрів, на які ви покладаєтеся.

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

Знайти правильний ритм тестування

Умови мережі постійно змінюються. Вони змінюються протягом дня, тижня і навіть хвилини. Тест, проведений о 3 годині ночі у вівторок, може виглядати фантастично, але цей результат марний, якщо ваш пік трафіку припадає на 2 годину дня у п'ятницю, коли всі онлайн.

Щоб отримати справжню базу, вам потрібно тестувати послідовно протягом часу. Змішуйте:

• Проводьте тести під час пікових годин роботи.
• Заплануйте деякі на нічні вікна обслуговування.
• Не забувайте про вихідні, коли патерни трафіку можуть бути зовсім іншими.

Повторюючи вибірку даних, ви можете згладити випадкові сплески і падіння. Так ви виявляєте повторювані проблеми, такі як перевантаження мережі кожного буднього дня відразу після обіду.

Не забувайте про джиттер

Середня затримка — це хороший початковий пункт, але вона часто приховує більш підступну проблему: джиттер. Джиттер — це просто варіація вашої затримки з часом. Подумайте про це — стабільне з'єднання з передбачуваною затримкою 80ms часто набагато краще для реального часу, ніж те, що в середньому становить 50ms, але стрибає між 10ms і 200ms.

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

Розуміння джиттера означає дивитися за межі середнього. Це непомітний злодій, оскільки він показує, чому середні значення можуть бути такими оманливими. Наприклад, дані з Pandora FMS показують, що джиттер понад 30ms може підвищити рівень втрат пакетів у іграх до 15% — достатньо, щоб зробити гру непрохідною. Вимірювання стандартного відхилення ваших результатів затримки — це перший крок до визначення цього нестабільності.

Контрольний список дизайну тесту на затримку

Щоб зібрати все це разом, ось швидкий контрольний список, який допоможе вам. Дотримуючись цих кроків, ви зможете забезпечити, щоб дані, які ви збираєте, були як точними, так і дійсно корисними.

Пункт контрольного списку	Чому це важливо	Дієва порада
Визначте чіткі цілі	Ви не можете виміряти те, що не визначили. Ви усуваєте конкретну проблему чи встановлюєте базу?	Запишіть свою мету перед початком. "Діагностувати затримку для користувачів у Південно-Східній Азії" — це краща мета, ніж "перевірити затримку."
Виберіть різноманітні кінцеві точки	Один шлях не представляє ваш глобальний досвід користувачів.	Виберіть 3-5 місць: одне місцеве, одне на іншому континенті та кілька у ваших ключових ринках користувачів.
Встановіть ритм	Одноразові тести пропускають часові патерни, такі як перевантаження в пікові години.	Заплануйте тести, щоб вони автоматично виконувалися кожну годину протягом тижня, щоб захопити повний цикл поведінки мережі.
Вимірюйте джиттер	Середні значення приховують непередбачувану продуктивність, яка псує реальні програми.	Не просто дивіться на середній RTT. Обчисліть стандартне відхилення або використовуйте інструмент, як mtr, який показує мін./макс./середню затримку.
Використовуйте правильні інструменти	ping підходить для швидкої перевірки, але інструменти, як mtr або iperf, надають глибші інсайти.	Для веб-продуктивності використовуйте інструменти розробника браузера. Для сирих мережевих шляхів mtr — чудовий вибір.
Документуйте все	Ви забудете "чому" за вашим тестом через шість місяців.	Ведіть простий журнал: дата, час, кінцеві точки, використаний інструмент і коротка примітка про те, що ви спостерігали.

Будучи методичним, ви переходите від простого вимірювання затримки до справжнього її розуміння. Цей продуманий підхід відокремлює випадкове число від надійного показника продуктивності.

Як зрозуміти цифри (і чого уникати)

Добре, ви провели свої тести і маєте купу даних. Тут починається справжня робота — переклад цих сирих чисел у щось, що дійсно має значення. Дані розповідають вам історію про здоров'я вашої мережі; вам просто потрібно навчитися їх читати.

Наприклад, раптовий сплеск у часі кругового проходження (RTT) на traceroute — це класичний підказка. Якщо затримка стрибає на третьому хопі і залишається високою до самого кінця, ви, ймовірно, знайшли свою проблему: це той третій маршрутизатор або лінк відразу після нього. Але будьте обережні. Якщо тільки цей один хоп показує високу затримку, а фінальна точка все ще швидка, це може бути просто маршрутизатор, налаштований на зниження пріоритету для конкретного типу трафіку, який використовує ваш тест. Це поширена помилкова тривога, яка може відправити вас у глухий кут.

Розшифровка джиттера та втрат пакетів

Дивлячись за межі простого RTT, ви знайдете найкритичніші інсайти. Високий джиттер, що є просто модним словом для непослідовної затримки, може бути набагато більш руйнівним, ніж затримка, яка постійно висока. Це особливо вірно для всього реального часу.

Якщо ваші результати показують середній RTT 40ms, але мінімум був 10ms, а максимум — 150ms, ваше з'єднання нестабільне. Ця величезна варіація саме те, що викликає дратівливі затримки у відеодзвінках і сплески затримки, які викликають гнів у онлайн-іграх.

Втрати пакетів — це ще більший червоний прапор. Навіть 1% втрата пакетів може абсолютно зламати програми на основі TCP, змушуючи їх постійно повторно надсилати дані і сповільнюючи все до повільного темпу. Коли ви дивитеся на результати тесту, будь-яка реальна різниця між надісланими пакетами та отриманими пакетами потребує негайного розслідування.

Одна з найбільших помилок, які я бачу, — це припущення, що один тест розповідає всю історію. Умови мережі постійно змінюються. Тест, проведений о 3 годині ночі, виглядатиме зовсім інакше, ніж тест о 3 годині дня під час пікових годин роботи. Єдиний спосіб отримати справжню базу продуктивності — це послідовне, повторюване тестування.

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

Найпоширеніші помилки вимірювання

Навіть з найкращими інструментами у світі кілька простих помилок можуть зробити ваші результати абсолютно марними. Уникнення цих поширених пасток є обов'язковим, якщо ви хочете дані, яким ви дійсно можете довіряти.

• Тестування через Wi-Fi: Справді, просто не робіть цього. Бездротові з'єднання відомі своєю примхливістю, схильні до перешкод від усього, від мікрохвиль до маршрутизатора вашого сусіда. Для будь-якого серйозного тестування затримки підключайтеся за допомогою Ethernet-кабелю. Це єдиний спосіб отримати стабільну, надійну базу.
• Забування про накладні витрати VPN: VPN чудові для безпеки, але вони додають додаткову зупинку та шифрування до подорожі вашого трафіку. Це завжди збільшить затримку. Якщо ви намагаєтеся діагностувати повільне з'єднання користувача, одним з ваших перших запитань має бути: "Ви на VPN?" Тестування з ним і без нього покаже вам, скільки затримки він додає.
• Ігнорування локального перевантаження мережі: Ваші результати тесту будуть спотворені, якщо хтось інший у вашій мережі займає всю пропускну здатність. Якщо колега транслює 4K-відео або завантажує величезні файли під час вашого тестування, ваші показники затримки будуть завищені, і ви в кінцевому підсумку будете переслідувати проблему, якої не існує.

Ще один тонкий, але критично важливий фактор — це інструмент, який ви вибираєте. Як ми вже обговорювали, різні утиліти вимірюють затримку по-різному. Завжди дотримуйтесь послідовності з інструментами, які ви використовуєте для порівняння, і переконайтеся, що ви розумієте, що кожен з них насправді вимірює — чи це простий ICMP-ехо, чи складний запит на рівні програми. І пам'ятайте, продуктивність може бути під впливом багатьох рівнів; наприклад, якщо ви заглиблюєтеся у веб-продуктивність, наш посібник про Cookie Editor Chrome Extension може показати, як елементи на стороні клієнта відіграють роль.

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

Поширені запитання про затримку мережі

Навіть з правильними інструментами кілька поширених запитань завжди здаються виникають, коли ви починаєте заглиблюватися у затримку мережі. Давайте пройдемося по деяким з найчастіших, які я чую, щоб допомогти вам зрозуміти ваші результати.

Яке насправді "добре" число затримки?

Це класичне питання "залежить від обставин", але ми безумовно можемо встановити кілька надійних орієнтирів. "Добра" затримка абсолютно відносна до того, що ви намагаєтеся досягти.

• Звичайний веб-серфінг: Для більшості з нас все, що нижче 100ms RTT, буде відчуватися цілком нормально. Сторінки завантажуються швидко, і ви не помітите жодної реальної затримки.
• Конкурентні онлайн-ігри: Тут кожна мілісекунда має значення. Серйозні гравці та трейдери з високою частотою шукають затримку значно нижче 20ms. Це різниця між перемогою та поразкою.
• Відеодзвінки та VoIP: Тут послідовність є ключовою. Вам потрібна стабільна затримка нижче 150ms і низький джиттер (менше 30ms), щоб уникнути ривчастого, несинхронного відчуття або, ще гірше, обривів дзвінків.

Як правило, більшість мережевих професіоналів, яких я знаю, класифікують все, що нижче 50ms, як низьку затримку. Від 50-150ms — це помірна затримка, а коли ви перевищуєте 150ms, ви почнете відчувати затримку на більшості інтерактивних додатків.

Чому мої результати ping і тесту швидкості браузера ніколи не збігаються?

Це чудове питання і дуже поширена точка плутанини. Це відбувається тому, що команда ping та тест швидкості на основі браузера — це принципово різні інструменти, які вимірюють різні речі.

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

Протоколи також абсолютно різні. Ping використовує дуже легкий протокол під назвою ICMP. Більшість тестів браузера працюють через TCP, що вимагає цілого процесу налаштування (так званий "триступеневий обмін"), щоб встановити з'єднання. Цей початковий обмін додає трохи часу перед тим, як справжній тест навіть почнеться.

Нарешті, тести браузера часто включають більше, ніж просто чистий час подорожі по мережі. Їхнє число "затримки" може включати час обробки сервера або навіть невеликі затримки в самому браузері, що може збільшити фінальну цифру в порівнянні з сирим ICMP ping.

Як я можу насправді знизити затримку моєї мережі?

Зменшення затримки полягає в пошуку та усуненні вузьких місць, незалежно від того, чи вони у вашому офісі, чи в Інтернеті.

Перше місце, куди слід звернути увагу, - це ваше найближче оточення. Найбільш ефективна зміна, яку ви можете зробити, - це перехід з Wi-Fi на дротове Ethernet-з'єднання. Це змінює гру в плані стабільності та швидкості. Якщо вам потрібно використовувати Wi-Fi, наблизьтесь до вашого маршрутизатора і підключіться до діапазону 5GHz, якщо це можливо - зазвичай він менш завантажений.

Дивлячись за межі вашої локальної мережі, іноді зміна DNS може допомогти. Використання швидшого DNS-сервера може скоротити час початкового з'єднання на мілісекунди, коли ви шукаєте веб-сайт.

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

Я бачив, як корпоративні VPN додають до 70 мс до часу на зворотний шлях. Це може перетворити чудове з'єднання на неймовірно повільне. Завжди тестуйте з VPN і без нього, щоб побачити, який вплив на продуктивність ви насправді отримуєте.

У чому справжня різниця між затримкою та пропускною здатністю?

Правильне розуміння цього є основою для розуміння продуктивності мережі. Легко їх переплутати, але вони вимірюють дві дуже різні речі.

Ось аналогія, яку я завжди використовую: уявіть це як автомагістраль.

• Пропускна здатність - це скільки смуг має автомагістраль. Більше смуг означає, що більше автомобілів (даних) може їхати одночасно.
• Затримка - це швидкісний ліміт. Він визначає, як швидко один автомобіль (пакет даних) може дістатися з точки А в точку Б.

Ви можете мати величезну, десяти-смугову автомагістраль (величезна пропускна здатність) з швидкісним лімітом 20 миль на годину (висока затримка). Ви могли б перемістити величезну кількість даних врешті-решт, але реальний час, наприклад, відеодзвінок, буде болісно повільним. З іншого боку, з'єднання з дуже низькою затримкою відчувається неймовірно швидким і чуйним, навіть якщо його пропускна здатність не є величезною. Вам дійсно потрібен хороший баланс обох для чудового досвіду.

---

Готові зробити тестування продуктивності безперервною частиною вашого щоденного робочого процесу? Набір ShiftShift Extensions надає потужний Speed Test, форматер JSON та десятки інших інструментів для розробників прямо у вашому браузері, доступних за допомогою однієї команди. Припиніть жонглювати вкладками і почніть працювати розумніше. Завантажте ShiftShift Extensions безкоштовно та підвищте свою продуктивність сьогодні.