Задержка, джиттер и потери пакетов: в чём разница
Высокая скорость передачи данных не гарантирует плавный видеозвонок или игру. Для интерактивных задач важны также задержка, её колебания — джиттер — и потери пакетов. Эти показатели описывают разные проблемы, поэтому их полезно измерять отдельно.
Три показателя на простом примере
Задержка показывает, сколько времени требуется данным на путь между точками. Команда ping обычно сообщает RTT — время от отправки пробы до получения ответа, то есть путь туда и обратно. Джиттер в практических измерениях означает изменение задержки между последовательными пробами. Если ответы приходят через 20, 21, 90 и 18 мс, среднее значение скрывает один заметный скачок. Потеря пакета означает, что проба или ответ не пришли за отведённое время; иногда это результат перегрузки, а иногда диагностический трафик ограничен намеренно.
Показатели связаны, но не заменяют друг друга. Быстрый канал может иметь редкие большие задержки из-за очередей в маршрутизаторе. При видеозвонке это вызывает паузы, а при загрузке большого файла может почти не ощущаться. Отдельный «плохой» ответ от промежуточного маршрутизатора также не доказывает проблему конечного соединения: важно проверить конечный узел и реальное приложение.
Как проверить качество соединения
Запустите серию проб к одному и тому же адресу, например через проверку ping, и запишите время, сеть, минимальный и максимальный RTT, потери. Затем повторите измерение по кабелю или в другой сети. Проверьте скорость соединения, но не приравнивайте её к задержке. Если Wi-Fi показывает скачки, а Ethernet работает ровно, ищите помехи или перегрузку беспроводной сети прежде, чем обвинять удалённый сервер.
Сравнивайте измерения при одинаковых условиях: тот же сервер, время суток, устройство и метод. Параллельная загрузка файлов может создать очередь на домашнем маршрутизаторе и увеличить RTT. Проверьте отдельно без нагрузки и во время загрузки: разница поможет понять, нужна ли настройка управления очередями или более быстрый исходящий канал.
Как читать результат без ложных выводов
Небольшие колебания неизбежны; универсального порога «хорошего джиттера» для всех приложений нет. Для разговорной связи важны требования конкретной программы и её способность компенсировать задержки буфером. Потери ICMP-проб не всегда совпадают с потерями медиапотока, который может использовать другой протокол и маршрут. Если проблема наблюдается только в одной игре или службе, проверьте её собственную статистику и состояние сервера. Для поиска участка маршрута используйте traceroute, помня, что трассировка тоже не показывает всю причину сбоя.
Технические основы ICMP Echo описаны в RFC 792. Этот документ объясняет механизм пробы, но не задаёт единую оценку качества для всех приложений. Храните несколько результатов с датами: повторяемая тенденция полезнее одного случайного всплеска.