Средний пинг 30 мс, а созвон рассыпается: почему джиттер важнее среднего значения

MAATRIX

Мониторинг показывает средний пинг 30 мс до сервера — вроде бы отличный результат. При этом созвон в Zoom или Google Meet раз в минуту превращается в набор роботизированных обрывков, а голос собеседника «зависает» на середине слова. Разгадка почти всегда не в среднем значении задержки, а в том, насколько она скачет от пакета к пакету. Это и есть джиттер, и для любого realtime-трафика — голоса, видео, игр — он важнее, чем красивая цифра в отчёте ping.

Что такое джиттер и почему среднее значение обманывает

Задержка (latency, RTT) — это время одного конкретного пакета туда и обратно. Джиттер (jitter) — это разброс задержки между последовательными пакетами в потоке. Формально это отклонение времени доставки соседних пакетов друг от друга, и именно оно определяет, насколько предсказуемо ведёт себя канал.

Возьмём два канала с одинаковым средним пингом 40 мс:

• Канал А: пакеты идут 39, 41, 40, 38, 42, 40 мс — разброс единицы миллисекунд, джиттер низкий.
• Канал Б: пакеты идут 10, 70, 15, 85, 20, 40 мс — среднее те же 40 мс, но разброс десятки миллисекунд.

Для загрузки страницы или скачивания файла разницы почти нет — TCP переупорядочит и добуферизует пакеты, пользователь потеряет доли секунды. А вот для realtime-потока канал Б практически непригоден, хотя в отчёте мониторинга оба канала выглядят одинаково хорошо, потому что мониторинг чаще всего считает и показывает именно среднее.

Здесь и кроется системная ошибка при диагностике проблем со связью: инженер смотрит на средний ping, видит приемлемую цифру и делает вывод «сеть в порядке», хотя сама сеть непригодна для того типа трафика, ради которого её проверяют. Средний пинг отвечает на вопрос «насколько далеко сервер», джиттер — на вопрос «насколько предсказуемо туда доходят данные». Это разные метрики, и для realtime-приложений вторая почти всегда важнее первой.

Стоит отличать джиттер и от пакетной потери (packet loss) — потеря это когда пакет не дошёл вообще, джиттер — когда дошёл, но не вовремя. Для realtime-приложения разница часто стирается: пакет, пришедший позже окна воспроизведения, для кодека так же бесполезен, как потерянный физически. Поэтому высокий джиттер на практике часто выглядит как «потери», хотя на уровне сети ничего не терялось.

Почему джиттер разрушает realtime-коммуникацию

Голос, видео и игровой трафик устроены так, что каждый пакет несёт кусочек данных, который нужно воспроизвести или применить строго в свою временную позицию. Приложению неинтересна средняя задержка сессии — ему важно, придёт ли конкретный пакет до дедлайна воспроизведения.

При низком и стабильном джиттере поток пакетов приходит почти с равными интервалами, приёмник успевает воспроизводить звук и видео без рывков даже при задержке 100-150 мс — собеседники ощущают это как небольшую, но терпимую паузу перед ответом. При высоком джиттере поток превращается в чередование «пачек» пакетов и пауз: несколько приходят почти одновременно, догоняя друг друга, затем — тишина. Кодек не может воспроизводить звук рывками, поэтому либо вставляет артефакты, либо теряет часть данных как «опоздавшие».

Именно поэтому пользователи описывают проблему джиттера как «рассыпается звук», «голос роботизируется», «видео подвисает и потом ускоряется» — это симптомы не низкой пропускной способности и не высокого среднего пинга, а именно нестабильности интервалов между пакетами.

В играх механизм похож, но нагляднее: клиент прогнозирует движение других игроков между обновлениями от сервера (client-side prediction, interpolation). Пока пакеты от сервера приходят через равные интервалы, прогноз почти не ошибается. Когда джиттер высокий, часть обновлений приходит с опережением, часть — с опозданием, и сервер вынужден резко «доправлять» позицию — отсюда типичный эффект резинки (rubber-banding), телепортация противников и рывки прицела. Средний пинг у такого соединения может быть даже ниже, чем у соседа со стабильным каналом, а играть будет заметно хуже.

Как работает jitter buffer и в чём его компромисс

VoIP-клиенты, видеоконференции и часть игровых движков компенсируют нестабильность сети джиттер-буфером (jitter buffer) — небольшой очередью на приёмной стороне, которая намеренно придерживает ранние пакеты, чтобы дождаться более медленных и воспроизвести поток равномерно.

Логика простая: вместо того чтобы проигрывать каждый пакет сразу по прибытии (что при скачущей задержке звучит рвано), приёмник добавляет искусственную задержку в несколько десятков миллисекунд и проигрывает пакеты по расписанию из этого буфера. Пакеты, которые не успели прийти до момента воспроизведения, считаются потерянными и либо пропускаются, либо восстанавливаются predictive-алгоритмом кодека (packet loss concealment).

Компромисс здесь прямой и неизбежный:

• Маленький буфер — минимальная добавочная задержка разговора, но при малейшем скачке джиттера начинаются потери и артефакты, потому что буфер не успевает дождаться опоздавших пакетов.
• Большой буфер — почти все пакеты успевают прийти вовремя, потери исчезают, но разговор ощущается с заметной задержкой ответа — при буфере в 150-200 мс сверху на реальную сетевую задержку общаться становится неудобно, собеседники начинают перебивать друг друга.

Современные VoIP-стеки (например, реализации на Opus в Zoom, Discord, Telegram-звонках) используют адаптивный джиттер-буфер: он растёт, когда джиттер повышается, и сжимается обратно, когда сеть стабилизируется. Это снижает среднюю задержку по сравнению с фиксированным буфером, но не отменяет физику — при устойчиво высоком джиттере буфер вынужден держаться расширенным постоянно, и разговор ощущается с задержкой даже тогда, когда потерь пакетов формально нет. Отсюда вывод: снижать джиттер на уровне сети всегда полезнее, чем полагаться на то, что буфер всё скомпенсирует — он решает проблему потерь ценой задержки, а не устраняет её причину.

Откуда берётся джиттер: разбор причин

Джиттер — это, по сути, симптом того, что пакеты одного потока идут по сети неравномерно. Причин у этого несколько, и они редко действуют по отдельности.

Перегруженные каналы и очереди на маршрутизаторах. Когда канал близок к заполнению, пакеты скапливаются в буферах маршрутизаторов и ждут своей очереди на отправку. Пока буфер почти пуст, пакет проходит быстро; в пиковую нагрузку — стоит в очереди лишние миллисекунды или десятки миллисекунд. Именно колебание длины этой очереди и создаёт джиттер — как на стороне провайдера в час пик, так и на собственном аплинке сервера, если рядом с realtime-трафиком гоняется тяжёлый фоновый трафик: бэкапы, синхронизация, массовая загрузка.

Отсутствие или неправильная настройка QoS-очередей на промежуточных узлах. Без приоритизации трафика (QoS) все пакеты в очереди маршрутизатора равны — голосовой пакет ждёт своей очереди наравне с торрент-трафиком или бэкап-джобой. С включённым QoS realtime-трафик (маркированный DSCP-метками EF — Expedited Forwarding) обслуживается вне очереди, и его задержка становится стабильнее. Проблема в том, что такие метки чаще всего работают только в границах одной сети — как только пакет уходит в чужую автономную систему через пиринг или транзит, приоритизация обнуляется. Подробно о том, как устроены эти связи между сетями, разобрано в статье про пиринг и транзит простыми словами.

Wi-Fi против проводного подключения. Wi-Fi по своей природе вносит джиттер, которого нет в кабеле: радиоканал делится между всеми устройствами в зоне действия точки доступа, соседние сети на том же канале создают взаимные помехи, а протокол CSMA/CA заставляет устройство ждать освобождения эфира перед каждой передачей. В плотной жилой застройке с десятками соседских точек доступа на тех же каналах 2.4 ГГц джиттер на клиентской стороне может стать основной причиной проблем — даже если сама сеть сервера работает идеально. Проводное подключение (Ethernet) исключает эту переменную почти полностью.

Traffic shaping и throttling у провайдера. Часть операторов, особенно мобильных, применяет шейпинг отдельных типов трафика — намеренно придерживает пакеты, чтобы выровнять полосу под тарифный план или снизить нагрузку в час пик. В отличие от органической перегрузки, шейпинг может добавлять джиттер даже при формально свободном канале — токен-бакет алгоритмы часто пропускают трафик пачками, а не равномерным потоком. Косвенный признак именно шейпинга — джиттер, который не коррелирует с загрузкой канала, то есть проявляется, даже когда кроме звонка ничего не передаётся.

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

Как измерить джиттер: инструменты и методика

Прежде чем что-то чинить, джиттер нужно увидеть и оцифровать — «созвон рассыпается» не диагноз, а симптом.

mtr (My Traceroute). Базовый и самый доступный инструмент: показывает не только маршрут, но и статистику по каждому хопу — среднюю задержку, лучший и худший результат (Best/Wrst), и, что важнее всего для джиттера, стандартное отклонение (StDev). Хоп с высоким StDev — это хоп, где вносится основной разброс.

mtr -rwc 200 example.com

Флаг -r выводит отчёт в текстовом виде вместо интерактивного, -w включает широкий формат с полными именами хостов, -c 200 задаёт 200 циклов опроса — этого обычно достаточно для статистически значимой картины, а не единичного выброса. Смотреть нужно не только на последнюю строку (сам сервер), но и на промежуточные хопы — иногда сервер отвечает идеально ровно, а джиттер добавляется на одном из транзитных узлов задолго до цели.

ping с интервалом и последующим анализом разброса. Классический ping тоже годится, если не полагаться на итоговое среднее, а смотреть на сырые значения:

ping -i 0.2 -c 100 example.com | tee ping_log.txt

Интервал -i 0.2 (200 мс между пакетами) даёт более частую выборку, приближенную к частоте пакетов в голосовом потоке (обычно 20-50 мс на пакет, но чаще ping без root-прав не пускает). Дальше разброс можно посчитать вручную по столбцу time= или взять готовую цифру: сама утилита в конце выводит mdev (mean deviation) в строке rtt min/avg/max/mdev — грубый, но рабочий индикатор именно джиттера, а не только средней задержки.

Специализированные инструменты. Для более точной картины, особенно если нужно измерить джиттер именно так, как его видит VoIP-приложение (по протоколу RTP), есть отдельные утилиты:

• iperf3 с UDP-режимом (iperf3 -u -c host -b 1M) — выводит джиттер напрямую в отчёте, рассчитанный по методике RFC 3550 (той же, что использует RTP), что делает его ближе всего к реальному поведению VoIP-потока.
• smokeping — если нужен джиттер не разово, а в виде графика за дни и недели; полезен, когда проблема возникает не постоянно, а в определённые часы.
• Встроенная статистика самого клиента — Zoom, Google Meet и многие SIP-телефоны показывают в диагностическом окне текущий джиттер в миллисекундах, и это самый прямой способ увидеть именно то значение, которое влияет на качество звонка здесь и сейчас.

Общее правило методики: одного замера недостаточно — нужна серия за разумный промежуток времени и сравнение показателя в разное время суток, потому что джиттер от перегрузки канала почти всегда завязан на пиковую нагрузку сети.

Что реально можно сделать на стороне сервера и сети

Часть причин джиттера (домашний Wi-Fi клиента, шейпинг у его мобильного оператора) вне вашего контроля. Но на стороне сервера и выбора инфраструктуры есть рычаги, которые снижают джиттер системно, а не разово.

Приоритизация трафика на своей стороне. Если сервер сам генерирует смешанный трафик — отдаёт realtime-поток (голос, видео, игровой сервер) и одновременно гоняет бэкапы или синхронизацию — стоит явно приоритизировать интерактивный трафик через tc (traffic control) в Linux, выделив ему отдельный класс или ограничив фоновые задачи по полосе в часы пиковой нагрузки. Даже простое tc qdisc с приоритетной очередью для UDP-портов голосового сервиса снимает джиттер, вызванный собственной перегрузкой канала сервера, а не внешней сетью.

Выбор дата-центра ближе к аудитории. Меньшее число промежуточных сетей и хопов на пути — меньше точек, где может накопиться очередь и джиттер. Это не всегда совпадает с географической близостью: иногда более далёкий дата-центр с прямым пирингом до магистральных сетей аудитории даёт более стабильный путь, чем формально ближний, но подключённый через несколько транзитных провайдеров — разбор именно такого случая в статье Франкфурт быстрее Москвы для москвичей. Если несколько локаций дают близкий результат по задержке, джиттер стоит держать как дополнительный критерий выбора.

Избегание перегруженных транзитных маршрутов. Маршрут пакета определяется не только физической географией, но и договорами между сетями — почему так происходит, разобрано в статье почему маршрут не совпадает с географией. Если mtr показывает стабильный разброс на конкретном транзитном узле, а не у себя и не у цели, стоит проверить, есть ли у провайдера альтернативный аплинк — иногда переезд на другую площадку того же провайдера, но с иным пирингом, снимает проблему без смены хостинга.

Проводное подключение на клиентской стороне. Это не серверная мера, но проверить её стоит в первую очередь — перевод клиента с Wi-Fi на Ethernet часто снимает большую часть жалоб на «рассыпающийся» звонок без единой правки на стороне сервера.

Ни один из этих шагов не устраняет джиттер полностью — сеть общего пользования всегда будет вносить какой-то разброс. Цель — снизить его до уровня, который адаптивный jitter buffer компенсирует без ощутимой добавочной задержки, а не добиться нуля.

Частые вопросы