Матрица сравнения протоколов: 8 протоколов стриминга × 12 критериев

Последняя проверка: 2026-05-23 по IETF RFC 8216 (HLS, август 2017), Apple HLS Authoring Specification for Apple Devices ревизия 2025-09 (контролирующий документ для LL-HLS), ISO/IEC 23009-1:2022 (DASH), ISO/IEC 23000-19:2024 (CMAF), IETF RFC 9725 (WHIP, март 2025), последней редакции draft-ietf-wish-whep (WHEP), серии draft-ietf-moq-transport-17 (Media over QUIC, январь 2026), draft-theo-hesp-06 (HESP) и draft-sharabayko-srt (SRT). Где данные вендоров расходятся со спецификацией, побеждает спецификация – расхождения отмечены в тексте.

Кратко

Восемь протоколов покрывают почти весь продакшен лайв-видео сегодня: HLS, LL-HLS, MPEG-DASH, LL-DASH, WebRTC (с WHIP и WHEP как HTTP-интерфейсами), HESP, Media over QUIC и RTMP. Они располагаются на четырёхосном компромиссе – задержка, масштаб, поддержка устройств и операционная стоимость, – и ни один не выигрывает больше чем по двум осям одновременно. Честное сравнение – это матрица, а не рейтинг: пассивная аудитория в миллион зрителей – это LL-HLS через CDN; живой аукцион с двусторонним аудио – это WebRTC или WHEP; контрибьюшен от вещателя – это SRT или RTMPS, даже если оба протокола выглядят «старыми» на бумаге. Эта статья даёт полную матрицу 8 × 12, разбирает каждую тонкость, которую маркетинг обходит стороной, и показывает, как читать ячейки так, как читает их инженер стриминга.

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

Если вы выбираете протокол стриминга в 2026 году, вы выбираете не один протокол – вы выбираете стек, почти всегда с разным протоколом для контрибьюшена и для доставки, а часто и с двумя протоколами доставки для двух уровней аудитории (архитектуру описывает статья про гибридные стеки; эта статья даёт данные за выбором). Маркетинговые страницы вендоров скажут, что их любимый протокол «выигрывает» – но большинство таких сравнений берут один-два критерия и тихо игнорируют восемь-девять, где их выбор посредственен. Эта статья – каноническая справка Фора Софт по реальным цифрам: glass-to-glass задержка на масштабе, поддержка браузеров на май 2026, совместимость с CDN, ограничения кодеков, накладные расходы на упаковку, история с DRM, роль контрибьюшен vs доставка и три формы стоимости. Если утверждение вендора не сходится с ячейками здесь – вендор кратко описал бенчмарк на своей инфраструктуре, а не сам протокол.

Как читать эту матрицу

Каждая ячейка матрицы несёт одну информацию об одном протоколе по одному критерию. Матрица – не рейтинг. Читать её правильно помогают три привычки.

Цифры задержки – это диапазоны, а не точки. Glass-to-glass задержка протокола зависит от энкодера, размера сегмента, сети, политики буфера плеера и стратегии кеширования сегментов на CDN. Когда строка пишет «2–4 секунды», это хорошо настроенный продакшен-диапазон – не лучший лабораторный случай и не худший инцидент. Маркетинговые страницы вендоров часто называют лабораторное число («HLS за 200 мс!») и аккуратно опускают уровень CDN и настройки плеера. Любое заявление об одной точечной задержке должно вызывать подозрение.

Поддержка браузеров – это флаг функции, а не бинар. Строка «Safari: HLS нативно, остальные: через MSE» означает, что каждый крупный браузер играет HLS – но Safari использует HLS-стек операционной системы, а Chrome, Firefox и Edge используют JavaScript-плеер (обычно hls.js), который декодирует через MSE. Эта разница важна в продакшене: нативное воспроизведение не имеет пауз сборки мусора, но MSE-путь позволяет инструментировать каждый байт. Бинарное «да/нет» это скрывает; матрица ниже использует слова.

Стоимость – это всегда минимум три числа. Egress на одного зрителя – то, что цитирует большинство статей («LL-HLS стоит $X за зритель-час»). Это наименьшее из трёх. Инфраструктурная стоимость – origin, упаковщик, SFU, сервер ключей DRM – доминирует на низких масштабах и исчезает на высоких. Инженерная стоимость – команда, которую вы держите, чтобы стек работал, – тихий убийца «дешёвых» протоколов, которым в итоге нужны три инженера на full-time. Матрица разбивает стоимость на все три компонента.

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

Восемь протоколов

Перед самой матрицей – по одному короткому абзацу о каждом протоколе простыми словами. Если термин кажется новым – статья «Дерево протоколов доставки» подробно разбирает родословную, а статьи-разборы по ссылкам ниже дают полное прохождение спецификации.

HLS – HTTP Live Streaming. HTTP-протокол доставки, появившийся у Apple и теперь стандартизованный как IETF RFC 8216 (август 2017). Маленький текстовый файл-плейлист M3U8 указывает на последовательность сегментов длиной 2–6 секунд, каждый получают по обычному HTTP. HLS играется нативно на каждом устройстве Apple и через JavaScript-плееры (hls.js) в каждом другом браузере. Минимальная задержка стандартного HLS – 6–15 секунд; именно эта планка делает необходимым LL-HLS.

LL-HLS – Low-Latency HTTP Live Streaming. Расширение HLS от Apple 2019 года, которое разбивает каждый сегмент на parts (обычно 200–300-миллисекундные субсегменты) и добавляет preload hints и blocking playlist reloads, чтобы плеер мог запросить следующую часть до того, как энкодер допишет её. Контролирующий документ – HLS Authoring Specification for Apple Devices от Apple, не отдельный IETF RFC. Apple убрала HTTP/2 server push из этой спецификации в редакции сентября 2023 года, что противоречит многим старым статьям, описывающим push как обязательный. Продакшен glass-to-glass задержка: 2–5 секунд.

MPEG-DASH – Dynamic Adaptive Streaming over HTTP. Альтернатива HLS от ISO/IEC, определённая в ISO/IEC 23009-1:2022. Более крупный XML-файл MPD (Media Presentation Description) указывает на сегменты, структурированные в периоды, adaptation sets и representations. DASH по дизайну кодек-агностичен и де-факто формат доставки для не-Apple платформ – но устройства Apple не играют DASH нативно. Стандартная задержка: 6–30 секунд.

LL-DASH – Low-Latency MPEG-DASH. DASH с CMAF chunked-transfer-кодированием плюс availabilityTimeOffset и настройка segmentDuration из low-latency-гайдлайнов DASH Industry Forum. Каждый сегмент отправляется по мере производства, побайтно, по HTTP chunked encoding, а не «дожидаемся завершения». Продакшен glass-to-glass задержка: 2–4 секунды. Часто работает в паре с LL-HLS поверх одного CMAF-источника, чтобы одни и те же упакованные байты обслуживали обе экосистемы.

WebRTC – Web Real-Time Communications. Браузерный peer-to-peer real-time стек, определённый W3C и семейством IETF RFC 8825–8866. Транспорт – UDP через RTP, шифрование – DTLS-SRTP, сигналинг – то, что вы сами разводите (SDP offer/answer, затем кастомный сигнальный канал). WebRTC – единственный протокол в списке с задержкой меньше секунды glass-to-glass на продакшен-масштабе. Цена – нужен SFU (mediasoup, LiveKit, Janus, Jitsi, Pion), чтобы масштабироваться за пределы горстки peer-to-peer соединений; CDN вам не помогает. WHIP (RFC 9725) и WHEP (Internet-Draft) стандартизуют HTTP-интерфейсы для ингеста и эгресса.

HESP – High Efficiency Streaming Protocol. HTTP-протокол от THEO Technologies (ныне Dolby OptiView), оформленный как IETF Internet-Draft draft-theo-hesp. HESP доставляет два параллельных потока – continuation поток для стабильного воспроизведения и initialisation поток с GOP-выровненными точками для подключения и trick play. Продакшен glass-to-glass задержка: 400 мс – 2 с; время переключения каналов до 100 мс. Цена – лицензирование и меньшая экосистема плееров, чем у HLS/DASH; протокол открыт как draft, но коммерческие реализации сосредоточены в HESP Alliance.

MoQ – Media over QUIC. Усилие IETF moq working group по определению единого транспортного протокола, который сочетает профиль задержки WebRTC с кешируемостью и масштабом HLS/DASH. Текущая редакция – draft-ietf-moq-transport-17 (январь 2026), плюс компаньонные draft-ietf-moq-catalog и draft-ietf-moq-streaming-format. MoQ работает поверх QUIC (RFC 9000), наследует мультиплексирование HTTP/3, развёртывается в продакшене в виде ранних пилотов Cloudflare, Meta и Google. Статус на 2026: pre-RFC. Цитируйте как draft до публикации.

RTMP – Real-Time Messaging Protocol. Изначально потоковый протокол Adobe из эпохи Flash; оригинальная спецификация – PDF от Adobe 2009 года. RTMP формально устарел для доставки (ни один современный браузер не поддерживает Flash), но остаётся доминирующим протоколом контрибьюшена – почти каждый энкодер, стриминговая платформа и точка приёма говорят на RTMPS (RTMP-over-TLS). Матрица ниже рассматривает RTMP в 2026 как протокол только контрибьюшена.

«Замечание про SRT. SRT также широко используется для контрибьюшена и заслуживал бы колонку. Мы исключаем его здесь только потому, что эта статья – сравнение для Блока 4 (доставка); SRT подробно разобран в деп-дайве Блока 3. Колонка матрицы для RTMP заодно играет роль «legacy слот для контрибьюшена», чтобы структура из восьми колонок осталась чистой.»

Матрица 8 × 12

Каждая ячейка отвечает на один критерий для одного протокола. Числа актуальны на 2026 год. Читайте каждую ячейку с тремя привычками из предыдущего раздела; проза под каждым критерием объясняет ячейку.

Таблица 1. Матрица протоколов 8 × 12, май 2026.

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

Критерий 1 – Основная роль

Половина протоколов – это доставка, и существуют, чтобы прокачивать байты от медиасервера к зрителю. Другая половина – что-то другое. WebRTC по сути – real-time интерактивный протокол, который с WHIP и WHEP вырастил ингест-ветку (WHIP) и эгресс-ветку (WHEP) и может играть обе роли. RTMP, несмотря на громкость имени, отступил только к контрибьюшен-ветке: ни один современный браузер не играет RTMP, поэтому он не появляется на устройстве зрителя. MoQ задизайнен с первого дня обслуживать обе ветки пайплайна – одна из главных причин, почему за ним так пристально следят.

Практический вывод: выбирайте протокол под роль, которую вы закрываете, а не под бренд с самой громкой маркой. Самая частая архитектурная ошибка в аудитах: команды пытаются использовать WebRTC для broadcast tail (миллионы пассивных зрителей), потому что услышали «WebRTC – самая низкая задержка». Это правда – но его форма стоимости на сессию (Критерий 12) ошибочна для пассивной миллионной аудитории в 10–20 раз.

Критерий 2 – Задержка glass-to-glass

Glass to glass – это время между светом, упавшим в объектив камеры, и светом, ушедшим с экрана зрителя с тем же кадром. Включает захват, кодирование, контрибьюшен в origin, упаковку, доставку на edge CDN, буфер плеера, декодирование и рендеринг. Числа в матрице – это хорошо настроенный продакшен-диапазон, не лабораторный best-case.

Сделаем арифметику на стандартной конфигурации LL-HLS, чтобы было конкретно. Возьмём сегмент 2 с, разбитый на parts по 200 мс.

Задержка энкодера:                     500 мс
Сеть до origin (RTMPS):                200 мс
CMAF chunking + упаковка:              300 мс
Origin → edge (распространение CDN):    400 мс
Запрос parts + буфер декодера плеера:  1 500 мс
Декод + рендер:                        100 мс
ИТОГО:                                 3 000 мс = 3 секунды

Это хорошо настроенный продакшен-стек LL-HLS на ~3 секундах – внутри диапазона матрицы 2–5 с. Самое крупное слагаемое – буфер плеера; плееру нужен запас примерно в одну часть впереди декодера, чтобы поглощать сетевой джиттер без зависаний. Урезать размер part до 100 мс – буфер уменьшится до 750 мс; общая задержка упадёт до примерно 2,3 с. Уменьшать part ниже 100 мс – и большинство CDN захлёбываются по rate запросов.

Диапазон 100–500 мс WebRTC достижим потому, что он полностью пропускает сегментно-буферный паттерн. Сегментов нет – RTP-поток это непрерывный поток пакетов, и плеер держит jitter buffer в десятках миллисекунд. Цена – нельзя кешировать RTP-пакеты на edge CDN, и протокол не имеет способа размазать стоимость по миллиону зрителей (см. Критерий 12).

400 мс у HESP – впечатляющая цифра на бумаге. В продакшене достижимое число зависит от тех же слагаемых edge-сети и буфера плеера, что у LL-HLS; опубликованный кейс HESP 400 мс предполагает, что continuation stream уже горячий, то есть зритель уже в сессии. Задержка первого подключения – ближе к 1–2 секундам.

Цель MoQ 500 мс – опубликованная цель рабочей группы, не измеренное продакшен-число на крупной зрительской базе. Цитируйте цель working group с этой оговоркой.

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

Критерий 3 – Масштаб аудитории на поток

Масштаб на поток – это размер одновременной аудитории, которую может обслужить одна live-трансляция. HTTP-кешируемые протоколы – HLS, LL-HLS, DASH, LL-DASH, HESP – масштабируются до миллионов зрителей за счёт кеширования сегментов на edge-узлах CDN. Первый зритель в городе платит за подтягивание сегмента с origin; каждый следующий получает его из локального edge-кеша.

WebRTC так не работает. Каждый зритель держит реал-таймовое RTP-соединение с SFU, и SFU пересылает каждый пакет каждому зрителю индивидуально. Один экземпляр SFU комфортно обслуживает 1 000–5 000 зрителей на поток; кластер каскадных SFU (см. Блок 8) – десятки и сотни тысяч. Дальше стоимость зрителе-часа перестаёт быть конкурентоспособной по сравнению с HTTP-доставкой. Архитектура WHEP-over-CDN – попытка 2024–2026 дать WebRTC CDN-фасад: эгресс-соединение остаётся RTP, но CDN обрабатывает WHEP-handshake; в продакшене это пока ранний этап.

Цель MoQ по масштабу – миллионы на поток по дизайну: протокол кеширует QUIC-объекты на QUIC-aware edge-узлах. Архитектура работает в пилотах; продакшен-аудитория в 2026 находится в диапазоне сотен тысяч, не миллионов.

Критерий 4 – Поддержка браузеров

Это единственный критерий, где особый статус Apple в экосистеме становится жёстким ограничением. Нативное воспроизведение HLS в Safari использует медиа-стек ОС – AVPlayer на iOS, эквивалентный слой на macOS. JavaScript на пути воспроизведения не выполняется; браузер обрабатывает сегменты, расшифровку, декодирование и рендер. Цена – нельзя перехватывать байты для observability; Mux, Conviva и им подобные опираются на API MediaPlaybackQuality и VideoEvent, которые открывают меньше, чем MSE-плееры.

Chrome, Firefox и Edge играют HLS через JavaScript-библиотеку – обычно hls.js – которая парсит M3U8, тянет сегменты и кормит ими Media Source Extensions (MSE) для декодирования. Это гибче, но дольше стартует (JS-бандл нужно загрузить) и чуть тяжелее по CPU.

DASH – зеркальная история. Каждый не-Apple браузер играет DASH через dash.js или Shaka Player поверх MSE; в Safari нативной поддержки DASH нет вообще. Поэтому индустриальная норма – отдавать одновременно HLS и DASH из одного источника CMAF: одни и те же байты, разные манифесты.

WebRTC – самая чистая история поддержки браузеров в этой матрице: нативно в Chrome, Firefox, Safari, Edge, Brave и Opera, с одним и тем же API RTCPeerConnection. Различия – в качестве реализации (Safari наименее feature-complete) и списке кодеков (Safari предпочитает H.264; Chrome охотно говорит на VP8, VP9 и AV1).

HESP и MoQ требуют плеер-SDK. Браузеров, играющих их нативно, в 2026 нет. Для HESP справочный плеер – SDK Dolby OptiView; для MoQ – Cloudflare и Meta опубликовали экспериментальные плееры, но ни один крупный вендор браузера не встроил поддержку.

RTMP не играется ни в одном браузере. Точка. Удаление Flash в 2020 году похоронило воспроизведение RTMP в браузере; всё, что вы читаете о «доставке RTMP в браузер», требует серверный RTMP-to-HLS или RTMP-to-WebRTC транскодер перед зрителем.

Критерий 5 – Совместимость с CDN

Если сегменты протокола чисто укладываются в кеш CDN, операционная стоимость хорошая. Если нет – протокол не может выйти на стоимость egress, которую даёт HTTP-кешируемый протокол.

HLS, LL-HLS, DASH, LL-DASH и HESP все используют HTTP как примитив fetch, поэтому каждая CDN – Cloudflare, Akamai, Fastly, CloudFront, BunnyCDN – обрабатывает их по умолчанию. Нюанс – LL-HLS и LL-DASH сильнее давят на CDN: плеер запрашивает части сегментов чаще обычного HLS-плеера, и каждый запрос – это lookup в кеше. CDN без оптимизированных кеш-иерархий для маленьких объектов (origin shield, tiered cache) могут давать худший hit-ratio на low-latency-доставке. Это одна из тихих переплат при миграции HLS → LL-HLS – может потребоваться апгрейд тарифа CDN или переход на стриминг-специализированную CDN.

У WebRTC совместимости с CDN нет. RTP-over-UDP пакеты session-specific, зашифрованы и не кешируемы. Масштабирование WebRTC – это SFU; единственный способ «положить его на CDN» – обернуть в развивающуюся WHEP-over-CDN-архитектуру, где CDN обрабатывает сигнальный handshake, а медиа всё равно течёт из SFU.

MoQ CDN-дружественен по дизайну, но только на QUIC-aware CDN. Edge-узел должен понимать QUIC-потоки и формат объектов MoQ для кеширования; классические HTTP/1.1-only edge не подойдут. Cloudflare и Akamai отгрузили поддержку QUIC; ряд более мелких CDN – пока нет.

RTMP в собственной категории – он не работает на CDN общего назначения. Точка приёма должна говорить по RTMP, поэтому RTMP-ингест сосредоточен на специализированных origin (Wowza, Cloudflare Stream, Mux, Bitmovin, Ant Media, Flussonic). Внутри origin поток транскодируется в HLS/DASH/CMAF для доставки.

Критерий 6 – Транспорт

Этот слой определяет большую часть истории задержки. TCP-протоколы (HLS, LL-HLS, DASH, LL-DASH, HESP, RTMP) несут handshake-стоимость на каждое соединение, переотправляют потерянные пакеты по порядку и наращивают окно через slow start. Поэтому минимальная задержка у них – 1–2 секунды даже при идеальной настройке: сеть делает правильную вещь для надёжной передачи файла, не для real-time стриминга.

UDP-протоколы (WebRTC) этот пол обходят. RTP идёт поверх UDP; потерянные пакеты либо «скрываются» декодером через packet-loss concealment либо для важных опорных кадров восстанавливаются через FEC. Handshake (DTLS + ICE/STUN/TURN) одноразовый и далее не релевантен. Никакого slow start.

MoQ работает поверх QUIC – UDP-основанного, но с мультиплексированием потоков. QUIC наследует свойство «нет head-of-line blocking» от WebRTC и свойство кешируемости от HTTP – это и есть архитектурный аргумент за то, что MoQ – долгосрочный ответ.

Критерий 7 – Свобода кодеков

Какие кодеки реально проходят через каждый протокол? HLS и LL-HLS ограничены благословлённым списком Apple – H.264, HEVC и (с iOS 17) AV1. Нельзя, например, отдать VP9 через HLS на устройства Apple и ожидать, что оно сыграет. DASH – самый разрешительный: любой кодек, который держит контейнер. У WebRTC другой короткий список (VP8, VP9, H.264, AV1 в 2026), определённый W3C, причём реализация WebRTC в Safari особенно требует H.264.

HESP кодек-агностичен в спеке, но коммерчески развёрнутые реализации сейчас целятся в H.264 и HEVC.

MoQ наследует свободу кодеков от QUIC (нет ограничения на уровне транспорта) и от draft-ietf-moq-streaming-format, который определяется отдельно для видео. В 2026 большинство пилотов отдают H.264 или AV1.

RTMP по сути замкнут на H.264 плюс AAC для видео и аудио – контейнер FLV, по которому идёт RTMP, формально не поддерживает новые кодеки в виде, который массовые энкодеры уважают, хотя в части реализаций сделали HEVC «хаком».

Критерий 8 – История с DRM

DRM (digital rights management) определяет, можете ли вы доставлять премиум-контент (фильмы уровня Netflix, права на live-спорт, платное SVOD) через протокол. Владельцы премиум-контента требуют три DRM-системы – FairPlay для Apple, Widevine для Android и Chromebook, PlayReady для Windows и Smart TV, – и байты на проводе должны быть зашифрованы так, чтобы все три системы могли расшифровать.

Стандарт для этого – Common Encryption (CENC), определённый в ISO/IEC 23001-7. CENC шифрует видеопоток один раз одним ключом, а каждая DRM-система оборачивает этот ключ в свой формат лицензии. HLS, LL-HLS, DASH, LL-DASH и HESP поддерживают CENC, поэтому можно отдавать одни и те же зашифрованные сегменты во все три экосистемы. Архитектуру разбирает статья DRM 101.

У WebRTC эквивалента CENC нет. Протокол шифрует медиа на транспортном уровне через DTLS-SRTP – каждый WebRTC-поток зашифрован по дизайну, – но шифрование session-specific и не несёт конверт лицензии для трёх систем. Можно положить свою DRM-схему сверху, но ни один владелец премиум-контента сегодня не выдаст лицензию на доставку через WebRTC. Это уже дисквалифицирует WebRTC для многих OTT-кейсов.

RTMP не задизайнен для DRM. RTMPS даёт TLS-шифрование транспорта, но сам контент не защищён контентным ключом после выхода из соединения – внутри origin он в открытом виде.

История DRM у MoQ – до стандартизации. Рабочая группа обсуждала, как наложить CENC на QUIC-объекты, но финального дизайна нет. TBD.

Критерий 9 – Формат упаковки

Что на проводе? HLS изначально отдавал MPEG-TS, контейнер бродкаст-эпохи; современный HLS (с 2016) поддерживает fragmented MP4 (fMP4) и CMAF, а LL-HLS требует fMP4 в CMAF-профиле. DASH с первого дня задизайнен вокруг fMP4 / WebM. WebRTC отправляет RTP-пакеты – контейнера нет, только RTP-заголовки вокруг закодированного медиа.

Почему это важно: если HLS и DASH отдают одни и те же CMAF-байты, кодировать и хранить нужно один набор файлов. Это и есть архитектура package-once-deliver-many, которая последние пять лет определяет индустрию. Формат подробно разбирает статья про CMAF.

HESP упаковывается в CMAF. MoQ упаковывается как поток QUIC-объектов с опубликованным draft-профилем для видео.

Критерий 10 – Контролирующая спецификация

Какой документ – источник истины, когда реализации расходятся? По правилу §4.3.2 промпта спецификация выигрывает каждый раз. Точный документ для каждого протокола:

• HLS: IETF RFC 8216 – https://www.rfc-editor.org/rfc/rfc8216. Базовая спецификация HLS.
• LL-HLS: Apple HLS Authoring Specification for Apple Devices, ревизия 2025-09. Apple владеет расширениями LL-HLS; отдельного IETF-документа нет. Важно: Apple убрала HTTP/2 server push в ревизии сентября 2023 – многие старые статьи всё ещё описывают push как обязательный, они устарели.
• DASH: ISO/IEC 23009-1:2022 (paywall) плюс DASH Industry Forum Implementation Guidelines (бесплатные, близко зеркалят нормативный текст).
• LL-DASH: ISO/IEC 23009-1:2022 + low-latency-гайдлайны DASH-IF поверх.
• WebRTC: W3C WebRTC 1.0 Recommendation + семейство IETF RFC 8825–8866. W3C-документ покрывает JavaScript-API; RFC покрывают транспорт, сигналинг и модель безопасности.
• HESP: draft-theo-hesp-06 (IETF Internet-Draft). Может меняться до публикации как RFC.
• MoQ: draft-ietf-moq-transport-17 (январь 2026) + компаньонные drafts. Может меняться; не цитируйте как финальный RFC.
• RTMP: PDF Adobe 2009 года, архивный. Поддерживаемого преемника нет.

Цитируйте номер документа, версию и раздел каждый раз. Если процитируете блог вендора вместо спеки – на ревью SEO/редактор найдёт и вернёт статью на доработку.

Критерий 11 – Зрелость

Зрелость – это ответ на вопрос насколько рискованно отгружать этот протокол в 2026? HLS, LL-HLS, DASH, LL-DASH и WebRTC – твёрдо стабильны: каждый минимум пять лет в продакшене на интернет-масштабе, есть крупный пул инженеров, которые их разворачивали. HESP стабилен, но ограничен экосистемой HESP Alliance – протокол работает, пул инженеров и тулинг уже, чем у HLS/DASH. MoQ – захватывающий и экспериментальный: запустить клиентский продукт на MoQ в 2026 – это поставить архитектуру на pre-RFC-стандарт.

RTMP зрел для контрибьюшена и не для доставки – протоколу два десятка лет, каждый энкодер на нём говорит, но каждый браузер отказался от него в 2020.

Критерий 12 – Форма операционной стоимости

У стоимости три компонента: egress на одного зрителя, инфраструктура и инженеры. Ячейка «форма стоимости» в матрице называет доминирующий компонент для каждого протокола.

HLS, LL-HLS, DASH, LL-DASH, HESP – все имеют CDN-доминирующую форму стоимости: стоимость на зрителя – это сколько CDN берёт за гигабайт исходящего трафика, умноженное на средние зритель-часы. Инфраструктура (origin, упаковщик, сервер ключей DRM) размазана по аудитории – маленькое слагаемое на масштабе. Инженерная стоимость – команда из 1–2 человек на установившийся продакшен HLS/DASH.

Прикидка: 1 час LL-HLS на 5 Мбит/с для 100 000 одновременных зрителей на CDN-тарифе $0.005/ГБ – около $1 125 за час трансляции только в bandwidth CDN. Та же трансляция в стандартном HLS (тоже 5 Мбит/с) стоит столько же – битрейт тот же. Уровень задержки на стоимость не влияет; влияет только лестница битрейтов.

WebRTC – посессионная форма стоимости. Каждый зритель держит сессию с SFU; у SFU есть исходящий трафик, CPU и память на сессию. Прикидка: хорошо настроенный узел SFU обслуживает 1 000–2 000 зрителей на 1–2 Мбит/с. Та же трансляция на 100 000 зрителей: 50–100 SFU-узлов плюс TURN-тир плюс сигналинг. Стоимость зрителе-часа в 5–20× выше CDN-доставляемого HLS. Инженерная стоимость тоже выше: WebRTC на масштабе нужен in-house команды, понимающая jitter buffer, bandwidth estimation и эксплуатацию SFU.

MoQ задизайнен сводить две формы стоимости вместе. Пилоты показывают стоимость на зрителя сопоставимую с HLS/DASH на масштабе; апфронт R&D-стоимость значительная – вы интегрируете draft.

RTMP имеет форму стоимости только для контрибьюшена – одно соединение на поток – и поэтому в одной сравнительной таблице со стоимостью доставки не стоит.

Где здесь Фора Софт

Мы отгружаем видеопродукты с 2005 года: видеоконференции (WebRTC-стеки на mediasoup, LiveKit и Pion), OTT и Internet TV (HLS, LL-HLS, DASH, LL-DASH через multi-CDN), видеонаблюдение (low-latency WebRTC + RTSP на edge камеры), e-learning (гибрид LL-HLS broadcast с WebRTC-модераторскими наложениями), телемедицина (WebRTC end-to-end с consent-based записью в HLS), AR/VR-стриминг. В каждом из этих проектов ответ на вопрос «какой протокол?» был разным – поэтому мы и написали матричную статью. Если команда делает build-vs-buy и нужные ячейки неясны, поговорите с инженером стриминга – нет замены 30-минутному скоупинг-разговору с тем, кто отгружал этот протокол в вашей вертикали.

Частые ошибки при чтении матрицы

Несколько неверных прочтений всплывают в каждом протокольно-выборочном разговоре. Избегайте их.

Воспринимать задержку как единственный критерий. Задержка – ячейка, на которой чаще всего якорятся читатели, потому что маркетинг приучил рынок думать «меньше задержка = лучше протокол». Это одна из двенадцати ячеек. Пассивная аудитория в стиле YouTube не выигрывает от sub-second задержки и от формы стоимости, которая её обеспечивает. Правильный вопрос – какой уровень задержки нужен (sub-second, 2–5 с, 10–30 с) и какой протокол попадает в этот уровень на нужном масштабе.

Читать «поддерживает CENC» как «поддерживает премиум-контент». Поддержка CENC необходима для премиума, но не достаточна. Также нужны правильные DRM-лицензионные отношения, плеер должен реализовать правильный EME, манифест – задекларировать правильные content key ID. Матрица показывает спека-уровневую возможность; готовность к продакшену требует больше.

Путать «стабильный» со «развёрнутым на нужном вам масштабе». WebRTC стабилен как спека. Может ли ваша команда крутить WebRTC на 50 000 одновременных зрителей на поток – отдельный вопрос; на таком масштабе нужна экспертиза SFU, которую с 2020 трудно нанимать. То же про HESP: протокол стабилен, но пул инженеров, отгружавших его в продакшен, маленький.

Выбирать по проценту браузеров без учёта доли устройств. «Нативно в 95% браузеров» прячет 5%, которые могут быть 60% вашей выручки. Если это срез iOS Safari в iPhone-тяжёлом приложении, матрица говорит: DASH неправильный, даже несмотря на хорошие баллы по другим критериям.

Верить маркетинговому числу задержки. Вендорские бенчмарки меряют задержку протокола на своей инфраструктуре, на своих хорошо настроенных энкодерах и плеерах, часто внутри одного дата-центра. Glass-to-glass в продакшене имеет ещё 4 слагаемых (распространение CDN, last mile, декод на устройстве зрителя, рендер на устройстве) и обычно в 2–3× выше бенчмарка. Диапазоны матрицы – это хорошо настроенный продакшен-диапазон.

Как использовать матрицу в реальном решении

Матрица – слой данных. Слой решения – дерево выбора протокола доставки, которое проводит вас от «что вы строите?» к «отгружайте такой стек». Для большинства команд в 2026 ответ попадает в одну из трёх дорожек:

• Broadcast tail миллионов, уровень задержки 2–5 секунд: LL-HLS + LL-DASH из одного CMAF-источника. Те же закодированные сегменты, два манифеста, один тариф CDN. Стоимость доминирована egress; инженерная команда может быть маленькой.
• Интерактивный тир (хост, гости, аудитория до 100k), уровень задержки sub-second: WebRTC, фасадно через WHIP/WHEP, масштабируется на SFU-кластере. Выше стоимость на зрителя, но это единственный протокол, попадающий в sub-second.
• Гибрид (live-шопинг, town hall, спорт с контролем из аппаратной): комбинация двух – WebRTC/WHEP для интерактивного кольца + LL-HLS для broadcast tail, из общего CMAF-источника. См. статью про гибридные стеки – там четыре канонических паттерна.

MoQ и HESP попадают в нишевые кейсы сегодня (быстрое переключение каналов, pre-RFC-пилоты). Большинство продакшен-команд в 2026 должны всё ещё отгружать HLS-или-DASH + WebRTC.

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

• Ни один протокол не выигрывает больше чем по двум из четырёх осей – задержка, масштаб, охват устройств, операционная стоимость.
• Матрица 8 × 12 – это данные; дерево решений – это решение.
• Отгружайте HLS и DASH из одного CMAF-источника; накладные расходы пренебрежимы.
• WebRTC – единственный sub-second протокол с нативной поддержкой браузеров; ничто другое не близко.
• MoQ – долгосрочный ответ; HESP и LL-HLS/LL-DASH – реальность 2026.
• Цитируйте спеку, не блог вендора – когда источники расходятся, спека всегда побеждает.

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

• Реальность переключения протоколов: гибридные стеки – архитектура, объединяющая протоколы матрицы.
• Выбор протокола доставки в 2026: дерево решений – BOFU-статья, ранжирующаяся по «лучший протокол стриминга».
• Дерево протоколов доставки – родословная и история восьми протоколов.

CTA-блок

• Поговорите с инженером стриминга – забронируйте 30-минутный скоупинг-колл и пройдём матрицу по вашему продукту.
• Посмотрите наши кейсы – портфолио видеостриминга Фора Софт.
• Скачайте матрицу одним PDF – Карточка матрицы сравнения протоколов (PDF).