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

Опубликовано: 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 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-шопинг, оператора, читающего SLA, или человека рядом с инженерами, которому важно знать, какой вопрос задать. К концу раздела у вас будет словарь, чтобы уверенно говорить с инженерами, арифметика для расчёта потока, который вы ещё не строили, и пороги, по которым можно понять, достаточно ли сильна сеть для нужного видео.

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

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

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

Пропускная способность (throughput) – это реальная скорость передачи данных, которую вы наблюдаете на канале, измеряемая в битах в секунду (bps). Она почти всегда ниже доступной полосы пропускания. Именно эту величину показывают спид-тесты и оценивают алгоритмы ABR в плеерах каждые несколько секунд. Если представить полосу пропускания как ширину шоссе, то пропускная способность – это скорость, с которой вы реально едете по нему, с учётом пробок, ремонтных работ и ограничений скорости. Канал на 100 Мбит/с может выдавать всего 7 Мбит/с в вечерний пик: полоса осталась прежней, а 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 Мбит/с, а при слабом сигнале она падает до 5–30 Мбит/с. По данным Ookla, медианная полоса пропускания Starlink в США в середине 2025 года составляла около 220 Мбит/с с высокой локальной вариативностью.

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

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

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

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

Округлим до ≈7 Мбит/с полезной пропускной способности для чистого 1080p. Канал «10 Мбит/с», реально дающий 8–9 Мбит/с под нагрузкой, – нормально; канал «10 Мбит/с», просаживающийся до 5 Мбит/с в вечерний пик, – нет. Пропускная способность – маркетинговая цифра, а полезная пропускная способность – то, что видит плеер.

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

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

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

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

Самое прикладное следствие для стримингового продукта: алгоритм ABR в плеере оценивает не пропускную способность канала, а фактическую скорость передачи данных (throughput), выбирая при этом нужную рендицию. Алгоритм на основе throughput в hls.js использует время загрузки последнего сегмента и вычисляет throughput как bytes ÷ seconds. Если у зрителя за 30 секунд скорость упала с 8 до 3 Мбит/с – например, из-за скачивания 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 мс».

Математика проговорённая. Допустим, три пакета приходят в моменты 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 – окна хендоффа между спутниками создают короткие очереди, которые быстро накапливают и резко сбрасывают пакеты.

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

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

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

Почему потери критичны для стриминга: любой современный кодек (H.264, HEVC, AV1) сжимает видео, опираясь на предыдущие кадры. Один потерянный пакет может испортить ключевой кадр (I-кадр – самостоятельный опорный кадр, появляющийся раз в несколько секунд) и заставить декодер отображать мусор до следующего I-кадра. Даже 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. WebRTC поддерживает FEC через RFC 5109 и более современный стандарт FlexFEC.
• Устойчивые кодеки – современные видеокодеки поддерживают слайс-кодирование (потеря одного слайса влияет только на часть кадра) и масштабируемое кодирование (SVC, simulcast), что позволяет плееру отбрасывать отдельные слои, не теряя целостности всего потока.

Эти защиты не бесплатны. ARQ добавляет задержку, FEC – дополнительную полосу пропускания (обычно 10–30% сверх исходного битрейта), а устойчивые кодеки усложняют работу кодера. Статья про выбор протокола ингеста в 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 плеер выдаёт только тем, у кого пропускная способность позволяет.

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

Вот краткий пример. Live-стриминг-мероприятие. Пиковая нагрузка – 50 000 одновременных зрителей. Целевая рендеринг-качество для большинства – 1080p, 30 кадров в секунду, кодек H.264, средний битрейт 4,5 Мбит/с. Трансляция в формате CMAF с сегментами по 2 секунды. CDN доставляет поток через HLS поверх TCP.

Полоса на egress. 50 000 × 4,5 Мбит/с = 225 000 Мбит/с = 225 Гбит/с. Это пиковая исходящая нагрузка, которую должен покрыть контракт с CDN.

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

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

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

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

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

Самая дорогая ошибка в этой теме – объединить четыре числа в одно. Вендор, заявляющий «мы даём 100 Gbps полосы», говорит только о мощности egress – о ширине трубы – и ничего не сообщает о стабильности throughput при перегрузке, поведении джиттера при перестроении маршрутов и уровне потерь на последней миле. «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 Гбит/с до 1 Тбит/с, проектируем WebRTC-пайплайны для телемедицины, способные работать при 4G с 2% всплесков потерь, настраиваем кодеры так, чтобы прямой эфир e-learning транслировался в 1080p на экраны и в 480p на мобильные устройства одновременно. Каждый продукт мы тестируем по параметрам джиттера и потерь в лаборатории до релиза, потому что альтернатива – отладка той же проблемы в продакшене на пике нагрузки.

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

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

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

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