Jitter

Jitter – это характеристика сетевого пути второго порядка. RTT показывает среднее значение задержки, а jitter отражает, насколько эта задержка «дрожит» вокруг среднего. В RFC 3550 (RTP, июль 2003) jitter формально определён как сглаженная оценка дисперсии интервалов между пакетами. В HTTP-стриминге jitter проявляется в виде вариаций времени загрузки сегментов и компенсируется буфером плеера. В WebRTC и других протоколах реального времени jitter поглощается гораздо меньшим буфером (обычно 20–200 мс), и при его избытке возникают заикания аудио и видео.

Два главных источника джиттера – очереди в сетевых устройствах (bufferbloat) и конкурирующие потоки на одном и том же канале. Wi-Fi и сотовая связь обычно демонстрируют значительно больший джиттер, чем проводной Ethernet, из-за повторных передач на уровне MAC и общего использования эфирного канала. Современные умные роутеры и механизмы AQM (Active Queue Management – CoDel, fq_codel) стараются держать джиттер в допустимых пределах, отбрасывая пакеты заранее, а не позволяя буферам переполняться. Однако большинство потребительских сетей при нагрузке всё равно страдают от заметного джиттера.

В стриминговом дизайне jitter задаёт нижнюю границу jitter-буфера. WebRTC-стеки обычно используют адаптивный jitter-буфер размером 60–200 мс: меньше – появляются заикания, больше – растёт задержка. HLS- и DASH-плееры маскируют jitter, удерживая несколько сегментов – для VOD это не проблема, а для low-latency live становится серьёзным ограничением. Телеметрия должна включать jitter наряду с RTT: сеть может иметь стабильный средний RTT, но при этом ощущаться плохо из-за «дрожащего хвоста».