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

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

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

Цифры задержки – это диапазоны, а не точки. Задержка «стекло-к-стеклу» зависит от энкодера, размера сегмента, сетевых условий, политики буферизации плеера и стратегии кэширования сегментов на 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 – доминируют при низких нагрузках, но становятся незначительными при масштабировании. Инженерные затраты – команда, поддерживающая работу стека, – настоящий «тихий убийца» так называемых «дешёвых» протоколов, которым в итоге требуется три штатных инженера. Матрица разбивает стоимость на все три компонента.

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

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

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

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, а не отдельный RFC от IETF. В редакции сентября 2023 года Apple убрала поддержку HTTP/2 server push из спецификации, что опровергает утверждения многих старых статей, где push описывался как обязательный элемент. Продакшен-задержка «от стекла до стекла» составляет 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, рекомендованными в гайдлайнах DASH Industry Forum по низколатентной доставке. Каждый сегмент передаётся сразу после создания – побайтно через HTTP chunked encoding, без ожидания завершения. Задержка от источника до потребителя в продакшене составляет 2–4 секунды. Часто используется вместе с LL-HLS на основе одного CMAF-источника, чтобы одни и те же упакованные данные обслуживали обе платформы.

WebRTC – Web Real-Time Communications. Браузерный peer-to-peer стек для реального времени, стандартизированный W3C и описанный в серии RFC IETF 8825–8866. Транспортная часть – UDP через RTP, шифрование – DTLS- и SRTP, а сигнализация реализуется самостоятельно (через SDP offer/answer и последующий кастомный сигнальный канал). WebRTC – единственный протокол в списке, обеспечивающий задержку менее секунды от экрана до экрана в продакшен-условиях. Однако для масштабирования за пределы нескольких peer-to-peer соединений требуется SFU (mediasoup, LiveKit, Janus, Jitsi, Pion) – 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. Задержка «стекло-к-стеклу» в продакшене – от 400 мс до 2 с; время переключения каналов – до 100 мс. Минусы – необходимость лицензирования и меньшая экосистема плееров по сравнению с HLS и DASH. Протокол опубликован в виде черновика (draft), однако коммерческие реализации сосредоточены в рамках HESP Alliance.

MoQ – Media over QUIC. Работа группы IETF по разработке единого транспортного протокола, сочетающего низкую задержку 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 поверх TLS). Матрица ниже рассматривает RTMP в 2026 году как протокол исключительно для контрибьюшена.

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

Матрица 8 × 12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критерий 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-рукопожатие; в продакшене это пока находится на ранней стадии.

Цель MoQ по масштабу – миллионы на поток по дизайну: протокол кеширует QUIC-объекты на edge-узлах, поддерживающих QUIC. Архитектура работает в пилотных проектах; аудитория в продакшене в 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-бандл) и немного нагружает процессор.

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

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

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

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

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

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

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

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

MoQ по замыслу CDN-дружествен, но только на CDN, поддерживающих QUIC. Edge-узел должен понимать QUIC-потоки и формат объектов MoQ для кэширования; классические edge-узлы, работающие только с HTTP/1.1, не подойдут. 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) несут накладные расходы на установление соединения, переотправляют потерянные пакеты в правильном порядке и постепенно увеличивают размер окна передачи через механизм slow start. Поэтому даже при идеальных условиях минимальная задержка у них составляет 1–2 секунды: сеть оптимизирована для надёжной передачи данных, а не для реального времени.

UDP-протоколы, такие как WebRTC, обходят эту проблему. RTP работает поверх UDP: потерянные пакеты либо маскируются декодером с помощью packet-loss concealment, либо, в случае важных опорных кадров, восстанавливаются с использованием FEC. Процедура установления соединения (DTLS + ICE/STUN/TURN) выполняется один раз и далее не требуется. Отсутствует механизм slow start.

MoQ работает поверх QUIC – протокола на основе UDP с мультиплексированием потоков. QUIC унаследовал от 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-поток зашифрован по замыслу, – однако это шифрование специфично для сессии и не обеспечивает совместимость лицензий между тремя основными системами. Можно реализовать собственную 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. Расширения LL-HLS принадлежат Apple; отдельного документа IETF не существует. Важно: в ревизии от сентября 2023 года Apple убрала поддержку HTTP/2 server push – многие старые статьи до сих пор описывают push как обязательный, хотя это уже устарело.
• DASH: ISO/IEC 23009-1:2022 (платный доступ) плюс Implementation Guidelines от DASH Industry Forum (бесплатные, близки по содержанию к нормативному тексту).
• LL-DASH: ISO/IEC 23009-1:2022 + гайдлайны по низкой задержке от DASH-IF.
• WebRTC: Рекомендация W3C WebRTC 1.0 + семейство IETF RFC 8825–8866. Документ W3C описывает JavaScript API, а RFC – транспорт, сигнализацию и модель безопасности.
• HESP: draft-theo-hesp-06 (Internet-черновик IETF). Может измениться до публикации в виде RFC.
• MoQ: draft-ietf-moq-transport-17 (январь 2026) + сопутствующие черновики. Может измениться; не цитируйте как окончательный 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 за час трансляции только на трафике 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 требует собственной команды, владеющей настройкой jitter buffer, оценкой пропускной способности и эксплуатацией SFU.

MoQ разработан для объединения двух форм представления стоимости. Пилотные проекты демонстрируют, что стоимость для зрителя сопоставима с HLS или DASH на крупномасштабных системах; однако первоначальные затраты на исследования и разработки значительны – вы интегрируете черновик.

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 трансляций с WebRTC-наложениями модератора), телемедицина (WebRTC end-to-end с записью по согласию в HLS), AR/VR-стриминг. В каждом из этих направлений выбор протокола был разным – поэтому мы и написали эту матричную статью. Если команда стоит перед выбором «разработать самому или купить» и не может чётко определить нужные параметры, поговорите с инженером стриминга – ничто не заменит 30-минутный разговор по скоупу с тем, кто уже внедрял этот протокол в вашей отрасли.

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

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

Воспринимать задержку как единственный критерий. Задержка – это одна из двенадцати ячеек, на которой чаще всего фокусируются читатели, потому что маркетинг приучил рынок думать: «меньше задержка – лучше протокол». Пассивная аудитория в стиле YouTube не выигрывает от задержки менее секунды и от формы стоимости, которую она обеспечивает. Правильный вопрос – какой уровень задержки нужен (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) в продакшене задержка складывается ещё из четырёх компонентов: распространение через CDN, последний километр, декодирование на устройстве зрителя и рендеринг на устройстве – и обычно в 2–3 раза превышает бенчмарк. Диапазоны матрицы соответствуют хорошо настроенному продакшен-диапазону.

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

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

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

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

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

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

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

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

CTA-блок

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