Затримка, джиттер і втрати пакетів: у чому різниця
Висока швидкість передавання даних не гарантує плавного відеодзвінка чи гри. Для інтерактивних задач важливі також затримка, її коливання — джиттер — і втрати пакетів. Ці показники описують різні проблеми, тому їх варто вимірювати окремо.
Три показники на простому прикладі
Затримка показує, скільки часу потрібно даним, щоб пройти шлях між точками. Команда ping зазвичай повідомляє RTT — час від надсилання проби до отримання відповіді, тобто шлях туди й назад. Джиттер на практиці означає зміну затримки між послідовними пробами. Якщо відповіді приходять через 20, 21, 90 і 18 мс, середнє значення приховує один помітний стрибок. Втрата пакета означає, що проба або відповідь не надійшла за відведений час; іноді причина в перевантаженні, а іноді діагностичний трафік обмежено навмисно.
Показники пов’язані, але не замінюють один одного. Швидкий канал може мати рідкісні великі затримки через черги в маршрутизаторі. Під час відеодзвінка це спричиняє паузи, а при завантаженні великого файлу може бути майже непомітним. Окрема «погана» відповідь від проміжного маршрутизатора теж не доводить проблеми кінцевого з’єднання: потрібно перевірити кінцевий вузол і реальний застосунок.
Як перевірити якість з’єднання
Запустіть серію проб до тієї самої адреси, наприклад через перевірку ping, і запишіть час, мережу, мінімальний та максимальний RTT, втрати. Потім повторіть вимірювання кабелем або в іншій мережі. Перевірте швидкість з’єднання, але не прирівнюйте її до затримки. Якщо Wi-Fi показує стрибки, а Ethernet працює рівно, шукайте перешкоди чи перевантаження бездротової мережі, перш ніж звинувачувати віддалений сервер.
Порівнюйте вимірювання за однакових умов: той самий сервер, час доби, пристрій і метод. Паралельне завантаження файлів може створити чергу на домашньому маршрутизаторі та збільшити RTT. Перевірте окремо без навантаження й під час завантаження: різниця допоможе зрозуміти, чи потрібне керування чергами або швидший вихідний канал.
Як читати результат без хибних висновків
Невеликі коливання неминучі; універсального порога «доброго джиттера» для всіх застосунків немає. Для розмовного зв’язку важливі вимоги конкретної програми та її здатність компенсувати затримки буфером. Втрати ICMP-проб не завжди збігаються з втратами медіапотоку, який може використовувати інший протокол і маршрут. Якщо проблема помітна лише в одній грі чи службі, перегляньте її власну статистику і стан сервера. Для пошуку ділянки маршруту використовуйте traceroute, пам’ятаючи, що трасування також не показує всієї причини збою.
Технічні основи ICMP Echo наведено в RFC 792. Цей документ пояснює механізм проби, але не задає єдиної оцінки якості для всіх застосунків. Зберігайте кілька результатів із датами: повторювана тенденція корисніша за один випадковий стрибок.