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

Опубликовано: 2026-05-20 · Время чтения: 16 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-20 по RFC 3550 (RTP, июль 2003), RFC 8298 (SCReAM, декабрь 2017), RFC 9000 (QUIC, май 2021), Рекомендации ITU-T G.1010 (ноябрь 2001), Apple HLS Authoring Specification revision 2025-09 и отчёту Conviva State of Streaming Q4 2025.

TL;DR

Инженер стриминга каждый день имеет дело с четырьмя сетевыми числами – полосой, пропускной способностью, джиттером и потерями, – и путаница между ними приводит к слитым бюджетам и недовольным зрителям. Полоса (bandwidth) – это размер трубы между двумя точками; пропускная способность (throughput) – сколько на самом деле проходит через трубу в реальных условиях; джиттер – разброс времени прихода последовательных пакетов; потери (packet loss) – доля пакетов, которые вообще не дошли. Статья определяет каждое из четырёх простым языком, проходит арифметику от «хочу 1080p» до «нужно 7,5 Mbps, джиттер до 30 мс и потери ниже 0,5%», и даёт пороги, на которых видео начинает ломаться, – из RFC 3550, ITU-T G.1010 и продакшен-данных Conviva за 2025 год. После прочтения вы прочтёте любой вендорский питч про полосу или любой инцидент-дашборд и поймёте, какое из четырёх чисел реально подводит.

Зачем это нужно

Почти любая жалоба на стриминг, которую слышит продакт-менеджер, – «стрим завис», «качество ужасное», «картинку на пару секунд раскрашивает блоками и отпускает» – это сбой одного из этих четырёх чисел. Если вы не различаете их, вы будете неправильно читать любой QoE-дашборд и подписывать у вендоров не те SLA. Мы писали для умного, не-технического читателя – основателя, который запускает live-shopping, оператора, который читает SLA, человека рядом с инженерами, которому нужно знать, какой вопрос задать. К последнему разделу у вас будет словарь, чтобы говорить с инженерами без блефа, арифметика для расчёта потока, который вы ещё не строили, и пороги, чтобы видеть, когда сеть достаточно здорова для нужного видео.

Четыре числа, определения

Инженерные команды часто говорят «сеть барахлит», смешивая четыре числа в одно. На самом деле это четыре разные вещи с четырьмя разными причинами и четырьмя разными решениями. Определим их один раз чисто, и всё остальное встанет на места.

Полоса (bandwidth) – максимальная скорость, с которой данные могут пройти через сетевой канал, измеряется в bps или, что удобнее для стриминга, в Mbps. Это свойство самого канала – модема, кабеля, радио, выделенного спектра вышки сотовой связи. Определение Cloudflare стоит запомнить: полоса – это размер трубы между двумя точками, потолок, под которым происходит любое реальное движение данных. У 100 Mbps оптики 100 Mbps полосы независимо от того, идёт ли по ней стрим.

Пропускная способность (throughput) – это фактическая скорость передачи, которую вы реально наблюдаете на канале, в тех же bps, почти всегда ниже полосы. Это то, что показывает спид-тест. Это то, что каждые несколько секунд оценивает алгоритм ABR в плеере. Если полоса – это ширина шоссе, пропускная способность – это скорость машины, на которой вы едете прямо сейчас, после пробок, ремонтов и ограничения скорости. Канал на 100 Mbps может реально отдавать 7 Mbps в вечерний пик; полоса не изменилась, throughput изменился.

Джиттер (jitter) – это разброс времени прихода последовательных пакетов, в миллисекундах. Поток идеально тактируемых пакетов, приходящих ровно каждые 20 мс, имеет нулевой джиттер. Поток, в котором пакеты приходят за 20, 23, 18, 26, 19 мс, имеет джиттер порядка нескольких миллисекунд. IETF формально определяет джиттер в RFC 3550 (RTP, июль 2003) как статистическую дисперсию времени межпакетного прихода, вычисляемую сглаживающим фильтром из раздела A.8 этого документа. Формулу приведём в разделе про джиттер ниже.

Потери пакетов (packet loss) – доля пакетов, которые сеть теряет между отправителем и получателем и никогда не доставляет, выражается в процентах. 1% потерь – один пакет из ста не дошёл. RFC 3550 передаёт это число в каждом RTCP Receiver Report в поле «fraction lost» – каноническое место, где протокол реального времени отчитывается о потерях.

Четыре числа сочетаются: стриминг здоров, когда полоса достаточно большая, throughput стабильно близок к полосе, джиттер мал, а потери близки к нулю. Почти каждый продакшен-сбой – это проблема как минимум с одним из четырёх. Остальная статья разбирает каждое по очереди, а затем показывает, как они взаимодействуют внутри протоколов, которые вы реально шипите.

Нажмите, чтобы увеличить

Полоса: размер трубы

Полоса – самое простое число и самое часто переиначиваемое. Это максимум – теоретический потолок, под который должно поместиться всё остальное. Домашний тариф «1 Gbps» продаёт 1 гигабит в секунду полосы в одну сторону. Мобильное 5G в поле обычно показывает 100–300 Mbps полосы в зоне сильного сигнала и падает до 5–30 Mbps на слабом сигнале. По данным Ookla, медианная полоса Starlink в США в середине 2025 года была около 220 Mbps, с большой локальной вариативностью.

Для стриминга полоса на канале зрителя задаёт потолок самой высокой ренди­ции (умное слово для «варианта качества»), которую плеер может запросить с адаптивной лестницы. Если на канале зрителя 6 Mbps полосы, никакое умное кодирование не даст ему 25 Mbps вариант 4K – полосы просто нет. Apple HLS Authoring Specification (revision 2025-09) делает это явным: каждый вариант в master-плейлисте несёт атрибут BANDWIDTH, по которому плеер отсекает то, что текущий канал не вытянет.

Цифра, которую стоит запомнить. Спецификация Apple требует, чтобы измеренный пик-битрейт сегмента укладывался в 25% от объявленного значения BANDWIDTH (для live), а средний битрейт по длинному окну – в 10% от AVERAGE-BANDWIDTH. Запас 25% существует именно потому, что полоса между отправителем и получателем никогда идеально не стабильна – даже на здоровом канале нужен буфер.

Математика проговорённая, первый раз. Стандартное 1080p 30 fps H.264 идёт со средним битрейтом около 5 Mbps и пиками до 10 Mbps. Чтобы зритель смотрел этот вариант чисто, ему нужно:

• 5 Mbps × 1.25 (запас 25% от Apple) = 6,25 Mbps стабильного throughput;
• плюс аудио, обычно 128 kbps = 0,13 Mbps;
• плюс любой другой трафик браузера на том же канале.

Округлим до ≈7 Mbps usable throughput для чистого 1080p. Канал «10 Mbps», который реально даёт 8–9 Mbps под нагрузкой, – нормально; канал «10 Mbps», который проседает до 5 Mbps в вечерний пик, – нет. Полоса – маркетинговое число, throughput – то, что видит плеер.

Пропускная способность: что реально проходит

Throughput – это реальная родственница полосы. Это скорость, которую плеер реально может стабильно держать после того, как все несовершенства возьмут свою долю. Throughput ниже полосы по трём причинам:

• Расстояние и RTT. Даже толстая оптика между Лондоном и Сиднеем даёт меньше throughput, чем та же оптика между Лондоном и Парижем, потому что время подтверждения пакета ограничивает количество данных, которое одновременно «в полёте». Окно TCP и congestion control QUIC (RFC 9000, май 2021) ограничивают объём байт в полёте примерно произведением полосы на RTT – это так называемое произведение полоса × задержка (bandwidth-delay product).
• Потери и переотправки. Каждый дропнутый пакет нужно отправить ещё раз. На канале 100 Mbps с 2% потерь отправитель фактически переделывает 2% работы, а алгоритмы восстановления TCP (CUBIC, BBR) ещё и режут темп отправки, считая потерю сигналом перегрузки. Throughput при 2% потерь редко превышает 60% от полосы на дальнем TCP-соединении.
• Конкуренция. Канал делят другие устройства, другие приложения, другие квартиры. Семейный тариф «100 Mbps», на котором четыре человека одновременно смотрят три разных шоу, делится на четыре.

Cloudflare в исследованиях по качеству домашнего интернета формулирует это удачно: качество соединения – низкий bufferbloat, низкий джиттер, стабильный throughput под нагрузкой – важнее голой полосы, как только вы выше минимального порога. Стабильные 50 Mbps бьют дёрганые 500 Mbps для стриминга всегда.

Самое прикладное следствие для стримингового продукта: алгоритм ABR в плеере оценивает throughput, а не полосу, когда выбирает рендицию. Алгоритм на базе throughput в hls.js берёт время скачивания недавнего сегмента и считает throughput как bytes ÷ seconds. Если у зрителя throughput за 30 секунд упал с 8 Mbps до 3 Mbps – потому что сосед запустил скачивание 4K – плеер переключается на нижний вариант за один цикл выборки сегмента, до того как буфер опустеет. Этот механизм и делает адаптивный стриминг рабочим в реальном грязном интернете; он же объясняет, почему QoE-дашборд считает throughput на стороне плеера, а не полосу на канале.

Нажмите, чтобы увеличить

Джиттер: разброс, убивающий live

Джиттер – термин, который чаще всего сбивает с толку не-технического читателя. Слово интуитивно – что-то «джиттерит», когда движется неровно, – но инженерное определение точное. Джиттер – это разброс времени прихода последовательных пакетов, а не сама задержка. Канал со стабильными 200 мс задержки и нулевым джиттером – нормальный для стриминга. Канал со стабильной задержкой 50 мс, которая иногда скачет до 250 мс, – высокоджиттерный и враждебный.

RFC 3550 (RTP, июль 2003) – каноническая ссылка. §6.4.1 определяет поле interarrival jitter, которое идёт в каждом RTCP Receiver Report; Приложение A.8 даёт формулу. По-русски: получатель считает для каждой пары последовательных пакетов разницу между ожидаемым межпакетным интервалом и реальным, а затем прогоняет эту разницу через сглаживающий низкочастотный фильтр. Точный текст из RFC 3550, A.8:

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1)) / 16

J(i) – оценка джиттера после i-го пакета. D(i-1, i) – разница между ожидаемым и реальным временем прихода предыдущего и текущего пакетов. Делитель 16 – сглаживающий коэффициент; RFC выбирает его сознательно, чтобы «дать хорошее подавление шума при разумной скорости сходимости». То, что выдаёт формула, – это значение, которое любой RTP-монитор показывает как «jitter = 12 ms».

Математика проговорённая. Допустим, три пакета приходят в моменты 100, 122 и 138 мс относительно опорного часа, а отправитель идеально разносил их на 20 мс. Ожидаемые интервалы – оба 20 мс. Реальные – 22 мс и 16 мс. Тогда |D(1,2)| = |20 − 22| = 2, |D(2,3)| = |20 − 16| = 4. Применяем фильтр дважды, начиная с J(0) = 0:

J(1) = 0 + (2 - 0) / 16        = 0,125 мс
J(2) = 0,125 + (4 - 0,125)/16  ≈ 0,37 мс

Понятно, что числа маленькие – трёх пакетов мало для сходимости. Важен механизм: фильтр слабо вешает на свежие отсчёты, чтобы единичный выброс не разнёс оценку, но за несколько секунд сходится к устойчивой дисперсии.

Почему джиттер критичен именно для live-видео: real-time протоколы вроде WebRTC и SRT проигрывают пакеты по тактируемому клоку. Если пакет приходит позже своего play-out дедлайна, протокол либо дропает его (WebRTC), либо стопит часы на несколько миллисекунд (SRT). И там, и там зритель видит глитч. Для сегментного стриминга (HLS, DASH) джиттер куда менее критичен: плеер буферизует секунды контента вперёд, и миллисекундный разброс растворяется в буфере.

Инженерные пороги, выжатые из ITU-T G.1010 (ноябрь 2001), опубликованных Cisco таргетов для голоса/видео и реальных деплойментов:

• До 30 мс – нормально для любого видео, включая конференции.
• 30–50 мс – нормально для буферизованного стриминга, граница для real-time.
• 50–100 мс – сегментный стриминг ещё работает; WebRTC и SRT начинают видимо глитчить.
• Больше 100 мс – даже буферизованный стриминг начинает заикаться, если сегменты не длинные.

Bufferbloat – это когда очередь роутера держит пакеты слишком долго в перегрузке – самая частая причина джиттер-всплесков на домашних каналах. Метрика AIM Score у Cloudflare, тесты bufferbloat у Waveform и DSLReports, CIRR (Connection-Induced Rebuffering Ratio) у Conviva существуют ровно потому, что обычный спид-тест не вытаскивает эту проблему. Starlink, например, в 2025 году рекламирует крепкие медианы по полосе и стабильно получает D–F на тестах bufferbloat – окна хендофа между спутниками краткими очередями держат и резко отпускают пакеты.

Потери пакетов: то, что не дошло

Потери – самое простое к измерению и самое разрушительное число. Когда роутер на пути перегружен, самое простое, что он может сделать, – дропнуть следующий пакет. Когда беспроводное радио потеряло сигнал на десятую долю секунды, все летящие в этот момент пакеты пропали. На стороне получателя это сразу видно как rate потерь.

Потери передаются в том же RTCP Receiver Report, что и джиттер. Поле fraction-lost – 8-битное число с фиксированной точкой: оно выражает потери с прошлого отчёта как долю от ожидавшихся. Значение 26 – это 26/256, около 10% потерь. Любой RTP-монитор – каждый WebRTC stats dashboard, каждый SRT-получатель – читает именно это поле.

Почему потери критичны для стриминга: любой современный кодек (H.264, HEVC, AV1) сжимает видео, ссылаясь на предыдущие кадры. Один пропавший пакет может испортить ключевой кадр (I-frame, самостоятельный якорь раз в пару секунд) и заставить декодер рисовать мусор до следующего I-frame. Даже 1% потерь, если они «попадают» в неправильные пакеты, может давать видимые артефакты каждые несколько секунд.

Пороги 2026 года, из ITU-T G.1010 и гайдов Cisco по голосу/видео:

Стриминговые протоколы защищаются от потерь тремя способами:

• Переотправки (ARQ) – TCP, SRT и QUIC просят отправителя переслать пакет, который не дошёл. ARQ восстанавливает данные, но стоит задержки: каждая переотправка добавляет один RTT. SRT (Internet-Draft draft-sharabayko-srt-NN) построен вокруг настраиваемого ARQ для контрибуции.
• Forward error correction (FEC) – отправитель шлёт избыточные данные, чтобы получатель восстановил потери, ничего не запрашивая. RIST (SMPTE TR-06) использует FEC для broadcast-grade надёжности. WebRTC поддерживает FEC через RFC 5109 и более современный FlexFEC.
• Устойчивые кодеки – современные видеокодеки умеют слайс-кодирование (один потерянный слайс портит только часть кадра) и масштабируемое кодирование (SVC, simulcast), позволяя плееру дропнуть слой, не теряя весь стрим.

Эти защиты не бесплатны. ARQ добавляет задержку; FEC добавляет полосу (обычно 10–30% сверх исходного rate); устойчивые кодеки добавляют сложности кодеру. Статья про выбор протокола ингеста в 2026 показывает, какой протокол использует какую защиту.

Нажмите, чтобы увеличить

Сколько полосы реально нужно?

Этот вопрос продакт-менеджер задаёт первым, а инженеры не любят отвечать одним числом. Честный ответ: зависит от разрешения, частоты кадров, кодека, нужного запаса на пики и от количества параллельных стримов в доме. Числа на 2026 ниже – из Apple HLS Authoring Specification (revision 2025-09), опубликованных битрейтов Netflix по рендициям и рекомендованных настроек загрузки YouTube.

Несколько замечаний по таблице. Средние – реалистичные цифры 2026 года для live и near-live; для VOD можно ещё снять 10–30% за счёт per-title кодирования. Колонка «1,25× пик» – минимальный throughput, который нужен зрителю, чтобы смотреть этот вариант без стопов, прямо из правила Apple про пик-битрейт. Колонки кодеков показывают рост эффективности HEVC и AV1 относительно H.264 – переход Netflix на AV1 в 2024 году срезал 4K-полосу с 25 Mbps до примерно 15 Mbps без видимой потери качества.

Частая ошибка: не считайте бюджет от верхней рендиции. Считайте от рендиции, которую реально получит большинство зрителей. Если 80% аудитории – мобайл, 720p – это рендиция, формирующая бюджет полосы; 1080p плеер выдаёт только тем, у кого throughput тянет.

Где четыре числа сходятся: пример

Чтобы свести всё в одно, маленький пример. Live-shopping ивент. Пиковая нагрузка: 50 000 одновременных зрителей. Целевая рендиция большинства: 1080p 30 fps H.264, средний 4,5 Mbps. Стрим в CMAF c 2-секундными сегментами. CDN отдаёт HLS поверх TCP.

Полоса на egress. 50 000 × 4,5 Mbps = 225 000 Mbps = 225 Gbps. Это пик исходящего, который должен закрыть контракт с CDN.

Throughput каждого зрителя. 4,5 Mbps × 1.25 = 5,625 Mbps стабильно, плюс аудио. Округлим до 6 Mbps. Зритель, чей канал не держит 6 Mbps, переключится на 720p; это нормально – ваш egress падает вместе с ним.

Бюджет джиттера. HLS-плеер буферизует 6–30 секунд контента. Джиттер в десятки миллисекунд невидим; всплески в одну-две секунды начинают давать ребуферинг, если буфер мелкий. Держите минимальный буфер плеера ≥ 3 секунд – и вы поглотите практически любой домашний джиттер.

Бюджет потерь. TCP сам переотправляет всё, что не дошло, так что при потерях ниже 1% throughput слегка проседает, но стрим идёт. Выше 3% throughput скатывается до сотен kbps, зрители каскадом падают по лестнице битрейтов и в итоге ребуферят. Поставьте на QoE-дашборде алёрт на 2% потерь у выборки edge-мониторов – увидите проблему раньше зрителей.

Старший инженер ужмёт каждое из этих чисел под конкретную топологию, кодек и аудиторию. Пример нужен, чтобы показать, как четыре числа складываются в одно sizing-упражнение; калькулятор битрейтной лестницы в разделе Tools автоматизирует ту же арифметику для любой аудитории.

Частые ошибки

Самая дорогая ошибка в этой теме – слить четыре числа в одно. Вендор, заявляющий «мы даём 100 Gbps полосы», говорит про мощность egress – про ширину трубы – и ничего не говорит про стабильность throughput под перегрузкой, поведение джиттера при перестроениях маршрута и rate потерь на последней миле. «10 Mbps канал» зрителя может реально давать 9 Mbps в чистый вечер и 2 Mbps в загруженное воскресенье. У той же семьи может быть 5 мс джиттера, когда стримит одно устройство, и 200 мс, когда стримят три.

Вторая ошибка – считать бюджет полосы от верхней рендиции. Как показано в примере, бюджет формирует та рендиция, которую реально получает большинство, взвешенная по качеству соединения. Считая на 4K, когда 80% аудитории на мобайле, вы раздуваете контракт с CDN в три-пять раз без выигрыша по QoE.

Третья ошибка – лёгкая и болезненная – читать throughput с плеера как полосу канала. Плеер измеряет throughput по сегменту, который только что скачал. Если плеер скачал низкий вариант быстро, отчёт по throughput искусственно ограничен битрейтом этого сегмента. Плеер не сообщает вам полосу канала; он сообщает, как быстро он только что подвинул известный объём данных. Оба числа важны, но это разные числа, и QoE-дашборд должен подписывать, какое именно показывает.

Где Фора Софт встраивается

Мы шипим стриминг и real-time медиа с 2005 года – в видеоконференциях, OTT, телемедицине, e-learning, видеонаблюдении и AR/VR. По всем этим вертикалям четыре числа из этой статьи – ежедневная диета: рассчитываем CDN-контракты для OTT-клиентов в диапазоне 1 Gbps – 1 Tbps, проектируем WebRTC-пайплайны телемедицины, которые держат 4G с 2% всплесков потерь, тюним лестницы кодера так, чтобы live-класс e-learning отдавал 1080p оптике и 480p мобайлу в одной трансляции. Каждый продукт мы тестируем по бюджетам джиттера и потерь в лаборатории до релиза, потому что альтернатива – дебаг той же проблемы в живом проде на пике.

Ключевые выводы

• Полоса – потолок трубы; throughput – то, что реально через неё проходит.
• Джиттер – дисперсия времени прихода пакетов; формулу даёт RFC 3550.
• Потери выше 1% бьют сегментный стриминг, выше 3% – real-time.
• Считайте egress CDN от рендиции большинства, а не от верхней.
• Буферизованные протоколы поглощают джиттер и потери лучше real-time.
• Стабильные 50 Mbps бьют дёрганые 500 Mbps для стриминга всегда.

Что почитать дальше

• Что такое доставка видео и почему это сложнее, чем отдать JPEG – пилларная статья, задающая рамку для каждого термина здесь.
• Задержка, glass-to-glass, end-to-end: что именно означают эти секунды – компаньон по сетевой реальности, со стороны секунд.
• TCP, UDP и выбор, который делает каждый протокол стриминга – следующий шаг вниз по стеку; throughput, джиттер и потери здесь становятся переменными, между которыми протоколы выбирают.