Jitter

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

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

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