Как выбрать протокол доставки в 2026: дерево решений

Последняя проверка: 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-03 (WHEP, 2026), draft-ietf-moq-transport опубликован 2026-05-01 (текущий рабочий документ рабочей группы), draft-theo-hesp-06 (HESP), draft-sharabayko-srt (SRT), W3C WebRTC Recommendation, RFC 9000 (QUIC) и RFC 9114 (HTTP/3). Где бенчмарк вендора расходится со спецификацией или стандартом, побеждает спецификация – расхождение отмечено в тексте.

Кратко

Выбор delivery-протокола в 2026 – это ответ на семь вопросов, а не на один: целевая задержка, пиковое число одновременных зрителей, охват устройств, интерактивность, монетизация, требования безопасности и возможности команды. Ни один протокол не выигрывает по всем семи, поэтому почти любой реальный продукт отправляет стек из двух-трёх протоколов, разложенных по двум-трём уровням аудитории. Дерево решений в этой статье проведёт вас от «что вы делаете?» до «отправляйте этот стек» за восемь узлов, с разобранными примерами восьми сценариев, которые мы аудируем чаще всего. Используйте дерево вместе с матрицей сравнения протоколов 8 × 12 – она даёт данные снизу, а эта статья – слой принятия решения сверху.

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

Если вы прочитали все статьи Блока 4 этого раздела, вы уже знаете, что делает каждый delivery-протокол, откуда он взялся и как работает. Чего разборы не говорят – это какой выбрать, потому что ответ почти никогда не «один». Цена ошибки не теоретическая. WebRTC для бродкаст-хвоста на миллион зрителей раздувает облачный счёт на порядок. HLS для живого аукциона теряет аукцион. MoQ в продакшене сегодня покупает квартал R&D до того, как первый байт уйдёт зрителю. Эта статья – каноническое дерево решений Фора Софт, то самое, по которому мы проходим каждый новый архитектурный разговор и которое мы публикуем здесь, чтобы продакт-менеджер, фаундер или инженер стриминга мог пройти его без нас. Сочетайте дерево с матрицей сравнения протоколов, статьёй про гибридные стеки и закрытым PDF внизу страницы – и у вас будет всё нужное, чтобы защитить решение по delivery-протоколу перед CTO, CFO и head of product в одной встрече.

Как пользоваться этой статьёй

У статьи четыре части. Первая разбирает семь входов решения и объясняет простыми словами, что каждый из них на самом деле измеряет. Вторая показывает само дерево решений – восьмиузловой проход сверху вниз, который принимает семь входов и возвращает рекомендованный стек. Третья проходит восемь разобранных сценариев из аудитов, которые мы делаем чаще всего: спортивное OTT, лайв-шоппинг, телемедицина, контрибьюшен со стадиона, e-learning бродкаст, корпоративный town hall, стрим многопользовательской игры и низкобитрейтная съёмка с поля. Четвёртая – раздел «частые ошибки» со списком восьми ошибок, которые мы видим почти в каждом архитектурном ревью.

Сначала прочитайте семь входов, потом перейдите к тому сценарию, который ближе всего к тому, что вы делаете. Дерево используйте как переиспользуемый каркас для любого сценария, не покрытого разобранными примерами. Закрытый PDF в конце страницы – это плакатная версия того же дерева, размером под стену комнаты архитектурного ревью.

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

Семь входов

Каждое решение по delivery-протоколу – это ответ на одни и те же семь вопросов, заданных в одном и том же порядке. Порядок важен, потому что каждый следующий вход сужает пространство ответов, которое открыл предыдущий. Пропустите вход – и рекомендация либо переусложнит (вы отправите WebRTC там, где сработал бы LL-HLS), либо недоусложнит (вы отправите HLS там, где аудитория ждала субсекундной реакции). Семь входов, по определению.

Вход 1 – Целевая задержка

Самое важное число. Задержка в стриминге значит glass-to-glass задержка – время между светом, попавшим на матрицу камеры на источнике, и светом, ушедшим с экрана зрителя с тем же кадром. Сюда входят захват, кодирование, контрибьюшен на origin, упаковка, дистрибуция через CDN, буфер плеера, декодирование и рендеринг. Статья про glass-to-glass задержку разбирает арифметику; здесь нужны только диапазоны.

Выбирайте диапазон, а не число. Инженерия под «задержку менее 2 секунд» принципиально отличается от инженерии под «задержку менее 500 миллисекунд» – первая это задача тюнинга на HTTP-стеке, вторая заставляет уйти на UDP. Диапазоны, которые мы используем в дереве:

• Субсекундная (менее 1 секунды) – интерактивные сценарии: живые аукционы, ставки в реальном времени, лайв-шоппинг с двусторонним аудио, телемедицина, видеоконференции. Принуждает к WebRTC или UDP-варианту реального времени.
• Низкая задержка (1–4 секунды) – бродкаст-сценарии, которым нужно ощущаться «живыми», но допустима небольшая задержка: спорт, новости, киберспорт, концерты. Территория LL-HLS и LL-DASH.
• Стандартная задержка (4–15 секунд) – бродкаст, где абсолютная задержка не важна, важно только чтобы поток шёл плавно: 24/7 каналы, повторы, ретрансляции по часовым поясам. Классический HLS или DASH.
• VOD (нет цели по задержке) – файл уже на сервере; вы выбираете только под стоимость и охват устройств. HLS или DASH через CDN с самым дешёвым форматом манифеста, который поддерживает ваш парк устройств.

Чаще всего мы видим, что команды по привычке ставят субсекундную цель, тогда как реальный сценарий сидит в диапазоне 2–5 секунд. Пассивный спортивный бродкаст не нуждается в субсекунде; зритель не отличит, показан гол через 0,5 или через 3,5 секунды после того, как он забит. Вопрос «что произойдёт со зрителем, если мы добавим ещё одну секунду?» обычно сдвигает цель на 2–3 секунды вверх и разблокирует LL-HLS через CDN как ответ, что сокращает стоимость на зрителя на порядок.

Вход 2 – Пиковое число одновременных зрителей

Число зрителей, одновременно смотрящих один и тот же поток, на пике. Три тонкости.

Во-первых, пик важнее среднего. Лайв-событие со 100 средних зрителей и 100 000 на пике – это архитектура под 100 000, не под 100. Берите инфраструктуру под пик; off-peak оптимизируйте отдельно.

Во-вторых, одновременно на одном потоке важнее общего числа пользователей платформы. Платформа с 10 миллионами пользователей и ни одним событием больше 5 000 одновременных – это архитектура под 5 000 на поток. WebRTC масштабируется до 5 000 при паре хорошо размещённых SFU. Та же платформа с одним прорывным событием на 500 000 одновременных заставляет использовать CDN-стек для этого события.

В-третьих, на поток важно для выбора протокола; совокупно важно для планирования мощностей. Дерево ветвится по пиковым одновременным на поток. Диапазоны:

• Десятки (1–100) – небольшие встречи, узкие трансляции, один-на-один. Работает WebRTC peer-to-peer.
• Сотни (100–1 000) – вебинары, маленькие классы, внутренние town hall. Работает WebRTC с одним SFU; работает и LL-HLS через CDN.
• Тысячи (1 000–10 000) – большие вебинары, средний лайв-шоппинг. WebRTC с каскадированными SFU начинает дорожать; LL-HLS через CDN становится дефолтом по стоимости.
• Десятки тысяч (10 000–100 000) – большие e-learning бродкасты, средние лайв-спортивные события. LL-HLS через CDN – дефолт; WebRTC + WHEP ещё возможен, но SFU доминирует в стоимости.
• Сотни тысяч+ (100 000+) – крупные лайв-спортивные события, прорывные события, национальные бродкасты. LL-HLS или HLS через мульти-CDN – единственная форма протокола, которая не схлопывается.

Вход 3 – Требование к охвату устройств

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

Решётка, которую надо помнить наизусть:

• Устройства Apple (iOS, iPadOS, macOS Safari) – только нативный HLS. DASH не играет нативно. WebRTC играет в Safari, но с особенностями, которые инженеры без шрамов от WebRTC регулярно недооценивают. Если ваша аудитория значимо Apple, HLS или LL-HLS – в стеке.
• Не-Apple браузеры (Chrome, Firefox, Edge, Opera, Brave) – HLS через hls.js, DASH через dash.js или Shaka, WebRTC нативно. Оба протокола – варианты; выбор операционный, не технический.
• Smart TV (Tizen, webOS, Roku, Android TV, Fire TV, Vidaa) – по-разному. Tizen и webOS предпочитают DASH; Roku предпочитает HLS; Android TV делает оба. Подробную матрицу даёт статья про плееры Smart TV. Для охвата Smart TV отправляйте оба HLS и DASH из одного CMAF-источника.
• Embedded-устройства (set-top box, экраны в авто, NVR видеонаблюдения) – зависит от вендора. Валидируйте по устройствам. Безопасный дефолт – HLS через HTTP/1.1, потому что у каждого embedded-плеера, который вообще выходил, где-то в boot ROM есть имплементация HLS-через-HTTP/1.1.
• Нативные мобильные приложения (iOS, Android) – ваш выбор SDK плеера. ExoPlayer на Android делает HLS, DASH и SmoothStreaming; AVPlayer на iOS делает только HLS без сторонней библиотеки. Большинство приложений отправляет HLS на обе платформы ради простоты.

Два практических правила. Первое: если аудитория смешанная – отправляйте HLS – это единственный протокол, играющий везде без второго варианта. LL-HLS это HLS с расширениями, утверждение сохраняется. Второе: если вам нужен WebRTC по какой-либо причине, вам почти наверняка нужен не-WebRTC fallback для длинного хвоста устройств, которые либо плохо поддерживают WebRTC (старые Smart TV, set-top box), либо где зрителям с ограниченной полосой выигрывает более низкая ступенька, которую может отдать сегментированный протокол.

Вход 4 – Модель интерактивности

Нужно ли зрителю что-то отправлять обратно? Ответ бинарный, но последствия большие.

• Пассивный просмотр – зритель только принимает. Протокол может быть односторонним, основную работу делает CDN, вся архитектура HTTP-based. HLS, LL-HLS, DASH, LL-DASH, HESP и MoQ подходят все.
• Двустороннее аудио/видео – зритель отправляет аудио, видео или то и другое. Протокол должен быть двусторонним и реального времени, то есть WebRTC.
• Только двусторонние данные (чат, реакции, опросы) – видео одностороннее, но взаимодействия зрителя реального времени. Самый частый случай для лайв-шоппинга, лайв-событий с чатом и second-screen опытов. Решение: одностороннее видео по LL-HLS или LL-DASH плюс отдельный канал данных реального времени (WebSocket, WebRTC data channel или low-latency pub-sub). Не берите WebRTC для видео только потому, что чат должен быть в реальном времени – чат не влияет на протокол видео.

Классическая ошибка – считать «чат в реальном времени» причиной отправлять WebRTC для видео. Чат – отдельный канал с отдельной инженерией. Мы видели, как команды раздували облачный счёт на порядок, потому что путали «реальное время» с «реальное время для видео».

Вход 5 – Модель монетизации

Как поток приносит деньги? Это определяет, что должен поддерживать ваш delivery-протокол.

• Подписка (SVOD) – только платный доступ. Нужен DRM (digital rights management) на плеере, чтобы предотвратить несанкционированную пересылку. DRM исключает чистый WebRTC delivery, потому что слой шифрования WebRTC (SRTP) – это не DRM, а три коммерческих DRM (FairPlay, Widevine, PlayReady) построены вокруг HLS и DASH с упаковкой Common Encryption (CENC). См. статью DRM 101.
• Ad-supported (AVOD или FAST) – бесплатно, монетизируется рекламой. Нужен delivery-протокол с сильной историей вставки рекламы. Server-side ad insertion (SSAI) хорошо поддерживается на HLS и DASH; статья про SSAI разбирает спецификацию. WebRTC не имеет нативной истории с рекламой; команды, которым нужно монетизировать WebRTC-стримы рекламой, обычно гонят параллельную HLS-rendition для бродкаст-хвоста и оставляют WebRTC только для интерактивного верхнего уровня.
• Транзакционный (TVOD) – pay per view. Та же история с DRM, что у SVOD. Те же последствия для протокола.
• Бренд / бесплатный (без монетизации) – нет DRM, нет вставки рекламы. Подходит любой протокол.

Сводное правило: если нужен DRM, HLS или DASH – в стеке. Если нужна вставка рекламы, HLS или DASH – в стеке. WebRTC – ответ для интерактивного уровня, почти никогда – для монетизируемого уровня.

Вход 6 – Безопасность и комплаенс

Кто смотрит поток, и что произойдёт, если он утечёт?

• Публичный бродкаст – нет контроля доступа, нет переживаний об утечке. Пропустите этот вход.
• Аутентифицированный доступ – зритель должен войти. Решение: подписанные URL от origin до edge CDN, аутентифицированная сессия в плеере. Работает с каждым протоколом в списке. Статья про аутентификацию по токенам разбирает механику.
• Защищён DRM – см. Вход 5. HLS или DASH с CENC и тремя DRM.
• Гео-ограничение – в одних странах смотреть можно, в других нельзя. CDN-протоколы (HLS, DASH) обрабатывают это на edge через гео-IP базу CDN. WebRTC обрабатывает это на SFU или через аутентифицированную сигнализацию. Подробности – в статье про геоблокировку.
• Нужны криминалистические водяные знаки – дорогой live-спорт, контент крупных студий. Криминалистические водяные знаки требуют либо серверной генерации вариантов, либо клиентского оверлея; оба хорошо поддерживаются на HLS и DASH (см. статью про watermarking). Watermarking на WebRTC технически возможен, но операционно непривычен и не дефолт 2026 года.
• HIPAA / регулируемая медицина – телемедицина. Сам протокол не регулируемый артефакт; регулируются запись, передача и хранение. WebRTC с DTLS-SRTP – дефолт для живых консультаций, потому что шифрование сквозное на транспортном уровне; записи перешифровываются на rest ключами KMS клиента. Статья про безопасность WebRTC разбирает шифрование.

Вход 7 – Возможности команды и операционный бюджет

Самый недообсуждаемый вход в любом архитектурном документе, который мы аудируем, и тот, что чаще всего диктует финальное решение. Протокол, который ваша команда может удержать в проде в 3 утра, важнее протокола, побеждающего на бумаге.

• Streaming-native команда (≥ 3 инженера, 1+ год опыта стриминга) – кандидат любой протокол из списка. Выбирайте по технической стороне.
• Общая backend-команда (1–2 инженера, без streaming-фона) – HLS или DASH через managed CDN. Операционная история – HTTP, ваша команда уже знает HTTP. WebRTC, MoQ и SRT все требуют специфической операционной экспертизы для надёжной эксплуатации.
• Нет инженерной команды (вы используете полностью managed-платформу) – протокол вашей платформы. Выбор – это вендор, а не протокол.
• MoQ или HESP в продакшене сегодня – требует отдельной функции streaming-engineering. MoQ – pre-RFC и ставится с операционными зазорами, которые на первых деплоях закрывают инженеры вендора; HESP требует коммерческого SDK плеера от HESP Alliance. Ни то, ни другое не «перебросить через забор» в 2026 году.

Вопрос бюджета идёт в паре с вопросом команды. WebRTC-стек с каскадированными SFU в трёх регионах стоит на порядок дороже на одного одновременного зрителя, чем LL-HLS-стек на CDN. Если ваш бюджет – «как можно меньше на зрителя», LL-HLS через CDN почти всегда ответ независимо от остальных входов. Если бюджет – «сколько надо, чтобы отгрузить опыт, который описала команда продукта», побеждает протокол, отгружающий опыт.

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

Дерево решений

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

Узел 1 – Какая целевая задержка?

Первый вопрос, потому что он быстрее всех остальных отсекает варианты.

• Субсекундная (менее 1 секунды) → идите к Узлу 4 (модель интерактивности). Вы на WebRTC-пути; вопрос лишь в форме.
• Низкая задержка (1–4 секунды) → идите к Узлу 2 (масштаб аудитории). Вы на пути LL-HLS / LL-DASH; размер аудитории определяет, single-CDN или multi-CDN стек.
• Стандартная задержка (4–15 секунд) → идите к Узлу 2 (масштаб). Вы на пути классических HLS / DASH.
• Только VOD → отправляйте HLS + DASH с CDN, c CMAF как базовой упаковкой. Дерево решений для VOD здесь заканчивается; глубокий выбор – в статье про упаковку и статье про экономику CDN. Готово.

Узел 2 – Сколько одновременных зрителей на поток на пике?

Если вы пришли из Узла 1 по ветке LL-HLS/LL-DASH или HLS/DASH:

• Менее 10 000 → single CDN, single-tier origin. Отправляйте LL-HLS для LL-ветки, HLS для стандартной. Идите к Узлу 3 (охват устройств).
• От 10 000 до 100 000 → single CDN с origin shielding, одна реплика origin на регион. Те же протоколы. К Узлу 3.
• Более 100 000 → multi-CDN с content steering. Те же протоколы. К Узлу 3.

Если пришли по WebRTC-ветке – вы на другом пути; прыгайте к Узлу 4.

Узел 3 – Требование охвата устройств?

Для веток HLS/DASH:

• Только Apple → только HLS или LL-HLS. Пропустите DASH; экономите шаг упаковки на одном пути.
• Только не-Apple браузеры → DASH или LL-DASH (часто дешевле HLS на масштабе, потому что манифест – один XML-файл, а не один M3U8 на ступеньку).
• Смешанный (Apple + не-Apple) → оба HLS и DASH с одного CMAF-источника. Упаковку разбирает статья про CMAF.
• Нужен охват Smart TV → оба HLS и DASH с CMAF плюс TV-валидация на каждую крупную ОС.
• Embedded-устройства в скоупе → HLS через HTTP/1.1 как fallback-rendition.

К Узлу 5.

Узел 4 – Модель интерактивности? (WebRTC-ветка)

Если пришли с субсекундной ветки:

• Двустороннее аудио/видео → WebRTC с SFU. Выбор SFU – из статьи про сравнение SFU. Для ингеста – WebRTC нативно или WHIP по RFC 9725.
• One-to-many бродкаст, субсекунда → WebRTC с WHEP для egress по draft-ietf-wish-whep-03, плюс SFU-меш. Масштабируется до десятков тысяч на поток с мультирегиональным каскадированием SFU.
• One-to-many бродкаст с пассивным хвостом → гибридный стек. WebRTC + WHEP для субсекундного уровня (малая интерактивная аудитория), LL-HLS через CDN для бродкаст-хвоста (большая пассивная аудитория). См. статью про гибридные стеки.
• Только данные (чат, опросы) → вам не нужен WebRTC для видео. Вернитесь к Узлу 1 и выберите LL-HLS-ветку; добавьте отдельный канал данных реального времени для чата.

Узел 5 – Модель монетизации?

Для любой ветки, что пришла сюда:

• Подписка, транзакционный, любое требование DRM → подтвердите HLS или DASH в стеке. Один WebRTC DRM не несёт. Если вы на чисто-WebRTC пути и нужен DRM, переработайте: WebRTC для интерактивного уровня, HLS или DASH для монетизируемого бродкаст-уровня.
• Ad-supported (SSAI или CSAI) → подтвердите HLS или DASH в стеке. Экосистема вставки рекламы сосредоточена на этих протоколах.
• Бренд / бесплатно → подходит любой стек; ограничения нет.

К Узлу 6.

Узел 6 – Безопасность и комплаенс

Для любой ветки:

• Нужно гео-ограничение → только CDN-стек (HLS, DASH, LL-HLS, LL-DASH). WebRTC требует прикладного гео-блока на SFU.
• Криминалистические водяные знаки → HLS или DASH с A/B-вариантным стримингом.
• HIPAA / регулируемая медицина → WebRTC с DTLS-SRTP для live; записи зашифрованы на rest ключами KMS клиента.

К Узлу 7.

Узел 7 – Возможности команды и бюджет

Для любой ветки:

• Streaming-native команда, здоровый бюджет → отгружайте технически лучший стек из Узлов 1–6. Рекомендация дерева – финальный ответ.
• Общая backend-команда → упростите стек. Снимите второй протокол, если можно (например, если планировали и HLS, и DASH – выберите тот, что покрывает 90% аудитории, и отгружайте один). Используйте managed CDN, managed origin и managed transcoder.
• Нет команды (managed-платформа) → стек платформы. Выбор – это платформа; дерево уже дало вам критерии оценки платформы.
• Ограниченный бюджет → уберите самый дорогой компонент. Если WebRTC был в стеке ради субсекундной интерактивности, понизьте до LL-HLS на 2–4 секунды и уберите WebRTC. Экономия большая; цена для UX ограниченная.

К Узлу 8.

Узел 8 – Future-proofing

Опциональный финальный узел. Для любой ветки:

• Пилот MoQ в скоупе → запустите MoQ параллельно с продакшен-стеком на 6–12 месяцев оценки. Не заменяйте продакшен-стек на MoQ в 2026; статья про Media over QUIC объясняет, почему pre-RFC технология в продакшене – это поквартальный риск. Майский 2026 драфт draft-ietf-moq-transport – текущий рабочий документ; ожидайте ещё 1–2 драфта до выхода RFC. У Cloudflare, Meta и Google есть ранние продакшен-деплои; их публичные комментарии – лучший бенчмарк надёжности протокола.
• Оценка HESP в скоупе → лицензируйте SDK плеера у HESP Alliance, сравните с тем же LL-HLS стеком, оцените выигрыш 100–400 мс задержки против стоимости лицензии SDK.
• Слой future-proofing не нужен → отгружайте стек из Узла 7. Запланируйте пересмотр через 12 месяцев.

Дерево закончилось. Путь, который вы прошли от Узла 1 до Узла 8, – это рекомендованный стек.

Восемь разобранных сценариев

Дерево – каркас. Разобранные примеры – то, как вы его усваиваете. Вот восемь сценариев, которые мы аудируем чаще всего, с пройденным путём и итоговым стеком.

Сценарий A – Live sports OTT, 500 000 на пике

Входы: задержка 3–5 секунд (низкая, но не субсекундная – зритель не отличит, был ли гол 1 или 3 секунды назад), 500 000 одновременных на пике, смешанный охват (Apple + не-Apple браузеры + Smart TV), пассивный просмотр, ad-supported + подписочный уровни, гео-ограничение, streaming-native команда, здоровый бюджет.

Путь: Узел 1 → низкая задержка. Узел 2 → более 100 000, multi-CDN. Узел 3 → смешанный, HLS + DASH с CMAF плюс валидация Smart TV. Узел 5 → DRM (подписка), SSAI (реклама) – подтверждаем HLS + DASH. Узел 6 → гео на edge CDN. Узел 7 → streaming-native, отгружаем технический стек. Узел 8 → пока без пилота MoQ в проде; пересмотр через 12 месяцев.

Стек: LL-HLS + LL-DASH с общего CMAF-источника, через multi-CDN с content steering, FairPlay (Apple) + Widevine + PlayReady, SSAI для вставки рекламы, гео-IP на edge CDN. Origin: кластеризованный с origin shielding и региональными репликами.

Почему не WebRTC: для пассивного спортивного зрителя UX-разница между 3 секундами и субсекундой нулевая; инфраструктурная стоимость WebRTC на таком масштабе в 10–20 раз выше. Арифметика – в статье про экономику стриминга.

Сценарий B – Лайв-шоппинг с двусторонним аудио, 5 000 на пике

Входы: субсекундная задержка для интерактивных коллов от ведущего (зритель говорит «покажи заднюю часть сумки» и ждёт реальной реакции), 5 000 одновременных на бродкасте, смешанный охват, двустороннее аудио (зритель иногда вступает в зов), ad-supported (спонсорские товары в бродкасте), без DRM, публичный бродкаст, streaming-native команда.

Путь: Узел 1 → смешанный – субсекунда для интерактивного, низкая задержка для бродкаст-хвоста. Канонический случай гибридного стека. Узел 4 → one-to-many с непассивным хвостом. Узел 5 → без DRM, реклама на LL-HLS хвосте ОК. Узел 7 → отгружаем технический стек.

Стек: WebRTC + WHEP для интерактивного уровня (ведущий + малое множество зрителей в коле), LL-HLS через CDN для бродкаст-хвоста (5 000 пассивных зрителей), плюс отдельный WebSocket-канал для чата. Кросс-уровневая синхронизация: LL-HLS-поток отстаёт от WebRTC на ~2 секунды, поэтому чат показывает комментарий, который ведущий сделал 2 секунды назад. Приемлемо для лайв-шоппинга. См. статью про гибридные стеки.

Почему не WebRTC на весь хвост: 5 000 одновременных WebRTC стоят примерно в 10× раз дороже, чем 5 000 LL-HLS на CDN. Зритель, который не на колле, не отличит, что один уровень на 200 мс, а другой на 2 секунды.

Сценарий C – Телемедицина, 1-на-1 или малая группа

Входы: субсекундная задержка (врач и пациент разговаривают), 2–6 одновременных участников, смешанный охват, двустороннее аудио + видео, без монетизации на колл (оплата через отдельный поток), HIPAA-комплаенс, запись для архива, streaming-native команда у вендора платформы.

Путь: Узел 1 → субсекунда, WebRTC-ветка. Узел 4 → двустороннее аудио/видео. Узел 6 → HIPAA. Узел 7 → команда вендора платформы; клиент интегрирует хостинговый сервис.

Стек: WebRTC с DTLS-SRTP, SFU LiveKit или mediasoup, TURN-серверы для прохода NAT, записи в зашифрованный на rest object storage с ключами KMS клиента. Без HLS/DASH уровня.

Почему нет бродкаст-уровня: нет бродкаста – это консультация 1-на-1 или малая группа. Архитектура чисто WebRTC.

Сценарий D – Контрибьюшен со стадиона на бродкаст-вышку

Входы: это контрибьюшен, не delivery – но дерево спрашивают постоянно. Субсекундная задержка (вещателю нужен сигнал в live), 1 зритель (ингест вещателя), сеть устойчивая к потере пакетов (4G/5G со стадиона), требуется шифрование.

Путь: дерево – для delivery. Для контрибьюшена – статья про дерево выбора ингест-протокола. Короткий ответ: SRT для сотовой ветки, RIST как broadcast-grade альтернатива. RTMPS только если камера не говорит на SRT.

Здесь упомянут только потому, что вопрос приходит через delivery-дерево минимум раз в квартал. Два дерева составляются: сигнал со стадиона через SRT, транскод на origin, доставка через LL-HLS зрителям.

Сценарий E – E-learning бродкаст, 30 000 студентов, класс + запись

Входы: задержка 2–4 секунды (студентам нужна синхронность лекции с чатом; субсекунда излишня), 30 000 на пике в exam-week, смешанный охват (ноутбуки + телефоны + иногда Smart TV), пассивный просмотр для бродкаста, чат для интерактивного уровня, без монетизации на поток (институциональная подписка), аутентифицированный доступ, запись в VOD-библиотеку после live-бродкаста, общая backend-команда (университетская IT-команда не streaming-native).

Путь: Узел 1 → низкая задержка. Узел 2 → 30 000, single CDN с origin shielding. Узел 3 → смешанный охват, HLS + DASH с CMAF. Узел 4 → только данные для чата – видео остаётся односторонним. Узел 5 → нет монетизации на поток. Узел 6 → аутентифицированный доступ через подписанные URL. Узел 7 → общая backend-команда, упростите. Снимите DASH, если 90% студентов на Apple + Chrome-устройствах, которые хорошо играют HLS. Используйте managed CDN и managed transcoder. Узел 8 → без future-proofing.

Стек: только LL-HLS (снимаем DASH ради простоты), через managed CDN с origin shielding, signed-URL аутентификация, отдельный real-time чат-канал через WebSocket, пост-бродкаст VOD-запись, упакованная как классический HLS для библиотеки.

Почему не полный HLS + DASH стек: общая backend-команда будет страдать, поддерживая два формата в синхронизации; операционная цена дебага «DASH-плеер на Smart TV отстаёт от HLS-плеера на iPhone на одну ступеньку в 3 утра» – реальная. Выберите один формат и хорошо покройте 90% аудитории.

Сценарий F – Корпоративный town hall, 8 000 сотрудников, внутренняя сеть

Входы: задержка 5–10 секунд (CEO говорит; никому не нужна субсекунда), 8 000 на пике в корпоративной WAN + удалённые сотрудники, смешанный охват (в основном Windows + Chrome), пассивный просмотр с Q&A через чат, без монетизации, только аутентифицированный доступ, общая backend-команда IT.

Путь: Узел 1 → стандартная задержка. Узел 2 → менее 10 000, single CDN или внутренний eCDN. Узел 3 → много Chrome, DASH работает хорошо. Узел 5 → нет монетизации. Узел 6 → только аутентифицированный. Узел 7 → общая backend, упростите.

Стек: классический DASH через managed eCDN (enterprise CDN – peer-assisted delivery для корпоративных сетей), SSO-аутентификация через корпоративный IdP, WebSocket-чат для Q&A. Без LL-HLS; стандартной задержки достаточно. Без WebRTC; Q&A – текст.

Почему не HLS: проникновение Apple на корпоративный парк низкое; DASH хорошо покрывает Chrome/Edge и более общий энтерпрайз-дефолт. eCDN сокращает WAN-полосу на 70–90% для больших внутренних бродкастов; математику разбирает статья про CDN.

Сценарий G – Стрим многопользовательской игры с интерактивным оверлеем, 50 000 на пике

Входы: субсекундная задержка для игроков интерактивного уровня, 1–4 секунды для зрителей, 50 000 зрителей на пике (иногда прорывное событие), смешанный охват, двусторонние данные для игроков (зрители могут голосовать по событиям), без DRM, ad-supported на уровне зрителей, streaming-native команда, здоровый бюджет.

Путь: Узел 1 → смешанный: субсекунда для игроков, низкая задержка для зрителей. Гибридный стек. Узел 4 → one-to-many с субсекундным верхом. Узел 5 → ad-supported, подтверждаем HLS или DASH для зрителей. Узел 7 → streaming-native, отгружаем технический стек. Узел 8 → пилот MoQ для зрителей – кандидат.

Стек: WebRTC + WHEP для игроков (субсекунда), LL-HLS для зрителей (1–4 секунды), SSAI на уровне зрителей, real-time канал данных (WebSocket или WebRTC data channel) для голосования. Опциональный MoQ-пилот для зрителей, параллельно с LL-HLS на 6–12 месяцев.

Почему MoQ-пилот: зрительские аудитории игровых стримов – чистейший фит для обещания MoQ «низкая задержка на HLS-масштабе». Риск 2026 – pre-RFC статус протокола; гоните пилотом, а не единственным каналом до зрителя.

Сценарий H – Низкобитрейтная съёмка с поля + локальный просмотр

Входы: задержка 2–4 секунды для зрителей, 200 одновременных в регионе репортёра, мобильно-тяжёлый охват, пассивный просмотр, бренд / без монетизации, только аутентифицированный просмотр, общая backend-команда.

Путь: сторона контрибьюшена – снова на дереве ингеста; ответ там – SRT или WHIP через сотовую. Для delivery: Узел 1 → низкая задержка. Узел 2 → менее 10 000, single CDN. Узел 3 → смешанная мобильная. Узел 5 → без монетизации. Узел 7 → общая backend, упростите.

Стек: только LL-HLS, mobile-оптимизированная битрейт-лестница (5 ступенек от 240p до 720p), managed CDN, signed-URL аутентификация.

Почему не WebRTC: цель – 2–4 секунды, интерактивности нет. WebRTC добавляет операционную стоимость без UX-выгоды.

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

Восемь частых ошибок

Каждое архитектурное ревью вытаскивает одни и те же восемь ошибок. В большинстве архитектурных документов их минимум две. Шаблон – это распознать ошибку быстро, чтобы перенаправить команду до того, как она написала квартал кода под не тот протокол.

Ошибка 1 – WebRTC для пассивного бродкаста

Симптом: архитектурный документ говорит «мы взяли WebRTC ради низкой задержки». Сценарий – пассивный спортивный бродкаст на 100 000+ одновременных.

Почему неправильно: per-session стоимость WebRTC доминируется SFU и логикой bandwidth estimation для каждого соединения. На 100 000 одновременных стоимость в 10–20× выше CDN-кешированного LL-HLS стека. Зритель не отличит 300 мс от 3 секунд на пассивном бродкасте.

Перенаправление: прогоните калькулятор экономики стриминга на оба стека на реальном пиковом числе. Покажите команде разрыв.

Ошибка 2 – HLS для субсекундной интерактивности

Симптом: команда берёт HLS или LL-HLS для живого аукциона или ставок в реальном времени, потому что «всё остальное в компании на HLS».

Почему неправильно: нижний предел задержки HLS – около 2 секунд. Аукцион или ставка, пришедшая на 2 секунды позже, проиграла аукцион. Даже нижний предел LL-HLS в 1–2 секунды слишком высок для по-настоящему интерактивных сценариев.

Перенаправление: явно измерьте бюджет задержки. Если у сценария deadline 500 мс или меньше на round-trip, WebRTC – единственный фит.

Ошибка 3 – MoQ в продакшене сегодня

Симптом: архитектура говорит «мы взяли MoQ ради future-proofing».

Почему неправильно: MoQ – pre-RFC. Текущий драфт (draft-ietf-moq-transport от 2026-05-01) – рабочий документ группы, но он подвержен изменениям до публикации как RFC. SDK вендоров ранние. Операционный тулинг скуден. Поддержка CDN ограничена QUIC-aware CDN.

Перенаправление: гоните MoQ как параллельный пилот рядом с продакшен-стеком LL-HLS или WebRTC. Не позволяйте MoQ быть единственным путём к зрителю в 2026.

Ошибка 4 – Путаница chat-real-time и video-real-time

Симптом: команда берёт WebRTC для видео, потому что продукту нужен real-time чат.

Почему неправильно: чат и видео – отдельные каналы с отдельной инженерией. Real-time чат – это WebSocket или WebRTC data channel; он не требует WebRTC для видео.

Перенаправление: разделите каналы. Выбирайте видео-протокол по его собственным критериям; выбирайте чат-протокол по его собственным. Две модели стоимости складываются, а не перемножаются.

Ошибка 5 – Игнорирование матрицы охвата устройств

Симптом: архитектура берёт только DASH, потом через два месяца обнаруживает, что Safari на iPhone не играет поток.

Почему неправильно: Apple-устройства играют HLS нативно, не DASH. DASH-only стек исключает всю Apple-экосистему на стороне браузера.

Перенаправление: валидируйте матрицу охвата устройств до выбора протокола. Если Apple в аудитории – HLS или LL-HLS в стеке.

Ошибка 6 – Забыли про DRM при выборе протокола

Симптом: команда берёт WebRTC для delivery, потом через 6 месяцев осознаёт, что студии требуют Widevine или FairPlay DRM.

Почему неправильно: WebRTC не несёт трёх коммерческих DRM. Они построены вокруг HLS и DASH с упаковкой CENC.

Перенаправление: спросите команду монетизации про требования DRM на Узле 5 дерева, до того как решение по протоколу финализировано.

Ошибка 7 – Недооценка multi-CDN на масштабе

Симптом: команда отгружает single-CDN на 100 000+ одновременных, потом случается региональный сбой и они теряют 30% аудитории на час.

Почему неправильно: single-CDN на шестизначных одновременных – это риск доступности. Multi-CDN с content steering – стандартный ответ для любой аудитории выше порога 50 000 одновременных.

Перенаправление: на Узле 2 дерева всё, что выше 100 000, – территория multi-CDN по умолчанию. Стоимость на 10–20% выше single-CDN; выигрыш в доступности большой.

Ошибка 8 – Выбор протокола, который нравится команде, а не которого требует сценарий

Симптом: в команде есть WebRTC-инженеры, поэтому каждый архитектурный документ включает WebRTC.

Почему неправильно: протокол, с которым команда комфортнее, редко правильный для сценария. WebRTC-инженеры будут проектировать WebRTC-стеки; HLS-инженеры – HLS-стеки. Сценарий должен драйвить протокол, а не наоборот.

Перенаправление: пройдите дерево вслепую относительно возможностей команды на Узлах 1–6. Возможности команды добавляйте только на Узле 7. Сделайте их ограничением на упрощение, а не драйвером выбора протокола.

Числовой пример – стоимость на зрителя на масштабе

Самое недомоделированное число в любом архитектурном решении – стоимость на зрителя на пике. Посчитаем для одного канонического сценария: 100 000 одновременных на спортивном OTT, средний битрейт 4 Мбит/с (1080p H.264), бродкаст 2 часа.

Полоса на один зритель-час:

Битрейт × секунд-в-часе ÷ бит-на-байт
4 000 000 бит/с × 3 600 с/ч ÷ 8 бит/байт
= 1 800 000 000 байт/час
= 1,8 ГБ/час на зрителя

Общая полоса для двухчасового бродкаста:

100 000 зрителей × 1,8 ГБ/ч × 2 часа
= 360 000 ГБ
= 360 ТБ

Стоимость на зрителя на LL-HLS-через-CDN стеке при типичной для 2026 ставке CDN $0,012 за ГБ на тиере 500 ТБ месячного коммита:

360 ТБ × 1000 ГБ/ТБ × $0,012/ГБ
= $4 320 за бродкаст
÷ 100 000 зрителей
= $0,043 на зрителя за двухчасовой бродкаст

Стоимость на зрителя на WebRTC-через-SFU стеке при типичной для 2026 цене $0,40 в час на одного одновременного участника managed-SFU (LiveKit Cloud, Mux Real-Time, Daily и т.п.):

100 000 зрителей × $0,40/ч × 2 часа
= $80 000 за бродкаст
÷ 100 000 зрителей
= $0,80 на зрителя за двухчасовой бродкаст

Соотношение: $0,80 ÷ $0,043 ≈ в 19 раз дороже на зрителя на WebRTC. Арифметика жестокая на масштабе. Для пассивного спортивного бродкаста, где зритель не воспринимает разницу между 300 мс и 3 секундами, WebRTC-стек тратит впустую $76 000 за бродкаст. За сезон из 30 бродкастов это $2,3 млн в облачных счетах без UX-выгоды.

Это математика за каждой рекомендацией «стоп, не отгружайте WebRTC для бродкаст-уровня», которую мы делаем в аудитах. Узел 1 → ветка низкой задержки существует ровно для того, чтобы эта ошибка не случалась.

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

Мы отгружаем стриминг, WebRTC, OTT, конференции, телемедицину, e-learning и видеонаблюдение с 2005 года, 239+ проектов. Дерево решений в этой статье – то же, по которому мы проходим каждый новый архитектурный разговор: для лайв-шоппинг платформ на 5 000 одновременных, для телемедицинских провайдеров под HIPAA, для e-learning бродкастеров на пиках exam-week, для OTT-операторов на шестизначных одновременных бродкастах. Мы аудировали стеки, выбравшие WebRTC для бродкаст-хвоста (и помогли мигрировать на LL-HLS, сократив облачный расход на порядок). Мы аудировали HLS-only стеки для живых аукционов (и помогли мигрировать на гибрид WebRTC + LL-HLS, отыграв окно задержки аукциона). Шаблон в обоих аудитах один: либо протокол подходит сценарию, либо облачный счёт или UX в итоге требуют переработки. Дерево существует, чтобы переработки избежать.

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

• Выбирайте протоколный стек, а не один протокол – почти любая прод-система отправляет два-три протокола, разложенных по двум-трём уровням аудитории.
• Проходите семь входов по порядку: задержка, масштаб, охват устройств, интерактивность, монетизация, безопасность, возможности команды. Пропуск входов переусложняет или недоусложняет стек.
• Субсекундная задержка принуждает к WebRTC; 1–4 секунды – LL-HLS / LL-DASH; 4–15 секунд – HLS / DASH; VOD – HLS + DASH через CDN.
• Аудитория выше 100 000 одновременных принуждает к multi-CDN; WebRTC на этом масштабе в 10–20 раз дороже LL-HLS для пассивных зрителей.
• DRM и вставка рекламы требуют HLS или DASH в стеке – один WebRTC их не несёт.
• Гоните MoQ как параллельный пилот в 2026, никогда как единственный путь к зрителю; протокол pre-RFC и операционный тулинг скуден.
• Протокол, с которым команде комфортно, редко правильный – делайте возможности команды ограничением на Узле 7, а не драйвером на Узле 1.

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

• Матрица сравнения протоколов: 8 протоколов × 12 критериев – слой данных под этим деревом решений.
• Гибридные стеки – почему почти любой прод-стек отправляет два протокола, не один.
• Экономика стриминг-продукта: рабочая модель – арифметика на зрителя подробно.