Джиттер и VPN: что важно для голосовой связи и игр

MAATRIX

Пинг 40 мс выглядит отлично, а голос в Discord всё равно рассыпается на слоги, а в шутере персонаж телепортируется на полметра назад каждые пару секунд. Дело не в средней задержке — дело в том, что она скачет от пакета к пакету. Это и есть джиттер, и для голосовой связи и игр он вреднее, чем стабильные, но чуть более высокие 80 мс. Разберём, почему так происходит, как измерить джиттер самому и какой протокол VPN держит его ниже остальных.

Джиттер и задержка — не одно и то же

Задержка (latency, RTT) — это время, за которое пакет доходит до сервера и обратно. Джиттер — это разброс этой задержки между последовательными пакетами. Если пять пакетов подряд идут 40, 41, 39, 40, 42 мс — джиттер около 1-2 мс, соединение ровное. Если те же пять пакетов идут 40, 90, 35, 110, 45 мс — средняя задержка формально та же (около 60 мс), но джиттер огромный, и именно он ломает realtime-трафик.

Разница принципиальная для того, как ведут себя приложения:

• Массовая передача данных (загрузка файла, веб-страница) — джиттер почти не важен: TCP буферизует и переупорядочивает пакеты, пользователь просто ждёт на пару миллисекунд дольше.
• Голос и игры работают в реальном времени — пакет, пришедший позже своего "окна", уже бесполезен, даже если не потерялся физически. Приложению всё равно, задержка это или джиттер — с его точки зрения это неотличимо от потери пакета.

Поэтому провайдеры, рекламирующие "средний пинг 35 мс до Москвы", закрывают только половину картины — эту цифру важно видеть не как одно число, а как разброс.

Почему джиттер критичнее для голоса и игр, чем чистая задержка

В голосовой связи (VoIP, звонки в Telegram/WhatsApp/Discord, SIP-телефония) приёмная сторона использует джиттер-буфер (jitter buffer) — небольшую очередь, которая придерживает ранние пакеты и ждёт опоздавшие, чтобы воспроизвести звук ровно. Буфер адаптируется под текущий джиттер: пока разброс низкий, запас минимальный и задержка звонка почти не растёт; когда джиттер скачет, буфер вынужден расширяться, добавляя задержку сверху к сетевой. Если он не успевает адаптироваться, часть пакетов всё равно приходит "после дедлайна" — кодек (обычно Opus в Discord и Telegram-звонках) заменяет их сглаживанием или выдаёт тишину/щелчок. Ключевой момент: нестабильная задержка не просто "иногда режет звук" — она вынуждает приёмник держать более широкий буфер постоянно, увеличивая ощущаемую задержку разговора даже когда сеть в порядке.

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

Итог: для realtime-трафика цельтесь не в "минимальный пинг", а в "минимальный и ровный пинг". Соединение со стабильными 60 мс почти всегда комфортнее, чем соединение, где пинг прыгает между 20 и 100 мс.

Как измерить джиттер до сервера

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

1. Обычный ping с достаточным числом пакетов. Смотрите не на среднее (avg), а на mdev (mean deviation) — это и есть приблизительный джиттер:

ping -c 100 203.0.113.10

В конце вывода на Linux/macOS будет строка вида rtt min/avg/max/mdev = 38.2/41.7/95.3/6.4 ms — mdev = 6.4 мс уже неплохой ориентир разброса, хотя это грубая оценка по всей выборке, а не по последовательным парам пакетов.

2. mtr для разброса по каждому хопу, чтобы понять, на каком участке маршрута джиттер появляется:

mtr --report --report-cycles 200 203.0.113.10

В колонке StDev смотрите не только на итоговый хоп, но и на промежуточные — если джиттер растёт уже на 3-4 хопе у вашего провайдера, дальнейшая настройка VPN эту проблему не решит.

3. iperf3 с UDP-потоком — самый точный способ, потому что джиттер здесь считается протоколом напрямую. На сервере: iperf3 -s. С клиента, имитируя примерно голосовой поток:

iperf3 -u -c 203.0.113.10 -b 128K -t 30

В отчёте будет отдельное поле Jitter в миллисекундах. Точные "хорошие" и "плохие" пороги зависят от кодека и буфера конкретного клиента — универсального числа нет, ориентируйтесь на относительное сравнение "с VPN / без VPN" и "сервер А / сервер Б". Прогоняйте тесты в разное время суток и отдельно по Wi-Fi и по кабелю — джиттер часто рождается не в сети провайдера, а в вашем собственном роутере под нагрузкой.

Какой протокол VPN стабильнее для realtime-трафика

Здесь принципиальна не столько "скорость" протокола, сколько то, как он ведёт себя при потере или задержке отдельного пакета.

• WireGuard — лучший выбор по умолчанию. Работает только по UDP, заголовок компактный (около 60 байт оверхеда), обработка идёт в ядре Linux — меньше случайных задержек на пакет. Потерянный пакет просто пропадает, приложение (кодек или игровой клиент) само решает, что с этим делать, без лишней логики со стороны туннеля.
• OpenVPN по UDP — тоже жизнеспособный вариант, оверхед выше из-за TLS-обвязки и обработки в user-space; под нагрузкой на CPU сервера джиттер может расти заметнее, чем у WireGuard, потому что шифрование конкурирует за процессорное время с другими процессами.
• OpenVPN по TCP — избегайте для голоса и игр. Это самый частый источник "необъяснимого" джиттера. При потере пакета в TCP-туннеле происходит retransmission на уровне самого TCP-соединения VPN — отдельно от того, что делает с потерей ваше приложение поверх. На практике это называют TCP-in-TCP meltdown: два независимых механизма ретрансмиссии конфликтуют друг с другом, и вместо предсказуемой потери одного пакета вы получаете резкий скачок задержки на весь туннель. Для файлов это незаметно, для звонка — характерный "заикающийся" эффект.
• IKEv2/IPsec — тоже UDP-based, по стабильности джиттера сопоставим с WireGuard, чуть больше накладных расходов на инкапсуляцию. Главное практическое преимущество — MOBIKE, переживает смену сети (Wi-Fi → мобильный интернет) без пересборки туннеля, что полезно для звонков с телефона в дороге, но само по себе не снижает джиттер на стабильной сети.

Более широкий разбор, какой протокол под какой сценарий брать в целом, — в статье какой протокол VPN выбрать: гид по сценариям. Здесь же вывод узкий: для голоса и игр держите VPN на UDP-транспорте — WireGuard или, при необходимости роуминга, IKEv2. OpenVPN/TCP держите как запасной канал для обхода блокировок, но не как основной для звонков.

Настройка VPN и сети для минимизации джиттера

Выбор протокола решает часть задачи, остальное — в конфигурации:

• PersistentKeepalive в WireGuard. Если сервер или клиент за NAT, держите интервал около 25 секунд — это не про джиттер напрямую, но не даёт NAT-мэппингу "остыть" между звонками, из-за чего первые секунды после паузы соединение бывает нестабильным:

PersistentKeepalive = 25

• Подберите MTU без фрагментации. Пакет, который не влез в MTU канала, режется на два, а сборка фрагментов на приёмной стороне — источник дополнительной переменной задержки. Проверка:

ping -M do -s 1392 203.0.113.10

Если проходит без Fragmentation needed — 1392+28=1420 байт можно использовать как MTU туннеля; если нет, снижайте размер шагами по 20-40 байт, пока не пройдёт.

• DSCP-маркировка не всегда переживает VPN. Если у вас настроен QoS на роутере, приоритизирующий голосовой трафик по DSCP-меткам, учтите: VPN шифрует исходный заголовок, и по умолчанию не все реализации копируют DSCP-метку из внутреннего пакета во внешний. У WireGuard это можно настроить через fwmark/маршрутизацию, но по умолчанию сквозной QoS через туннель не гарантирован — приоритизация чаще надёжно работает только до точки входа в VPN.
• Не экономьте на CPU сервера. Шифрование добавляет задержку на каждый пакет; на перегруженном или сильно oversold VPS эта задержка становится неровной именно в пиковую нагрузку от других клиентов. Для голоса и игр важнее гарантированное ядро CPU, чем лишние гигабайты RAM.
• Клиентская сторона тоже источник джиттера. Wi-Fi с соседскими сетями на том же канале, старый роутер без честной приоритизации очередей, фоновая синхронизация облака во время звонка — всё это добавляет джиттер до того, как пакет попадёт в VPN-туннель. Кабель почти всегда стабильнее Wi-Fi по разбросу, даже при одинаковой средней скорости.

Типичные ошибки, которые убивают стабильность связи

• OpenVPN/TCP "для надёжности". Интуитивно кажется, что TCP надёжнее UDP, раз гарантирует доставку — но для realtime-трафика это ловушка: гарантия доставки достигается ценой непредсказуемой задержки при любой потере пакета в туннеле. Держите UDP как основной транспорт для голоса и игр, TCP — только когда нужно обойти блокировку порта.
• VPN поверх VPN (double VPN). Каждый дополнительный слой шифрования и очередей — ещё один источник переменной задержки, вложенный в первый. Цепочка из двух туннелей почти всегда хуже одного, даже если оба по отдельности стабильны.
• Насыщение канала другим трафиком во время звонка. Фоновая загрузка бэкапа, торрент, синхронизация большого файла на том же аплинке — классический bufferbloat: очередь на исходящем канале растёт и добавляет джиттер всем остальным потокам, включая VPN. Средство — SQM/cake на роутере или простое правило не гонять тяжёлый трафик параллельно со звонком.
• Погоня за протоколом при нестабильном маршруте. Если джиттер растёт уже на промежуточных хопах (видно в mtr по колонке StDev), смена протокола VPN не поможет — проблема в конкретном транзитном участке, а не в туннеле. Решает локация сервера и провайдер, через которого он подключён к магистрали — общий ориентир по регионам есть в статье задержка между локациями: таблица ориентиров, но финальное решение всегда за собственным замером до конкретного сервера.
• Сервер выбран без учёта нагрузки под реалтайм. Сервер под игровые и голосовые сценарии — это не только близкая локация, но и гарантированные ресурсы CPU; подробнее в статье VPS для геймера и низкого пинга: что выбрать и как настроить.

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