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

Последняя проверка: 2026-05-23 по IETF RFC 8216 (HLS, август 2017), HLS Authoring Specification for Apple Devices от Apple, ревизия 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 (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 для широкого спектра устройств, которые либо плохо поддерживают WebRTC (например, старые Smart TV или set-top box), либо где зрителям с ограниченной пропускной способностью выгоднее более низкая ступень качества, которую может обеспечить сегментированный протокол.

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

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

• Пассивный просмотр – зритель только принимает контент. Протокол может быть односторонним, основную нагрузку берёт на себя CDN, вся архитектура построена на HTTP. Подходят 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 – Модель монетизации

Как поток приносит деньги? От этого зависит, что должен поддерживать ваш протокол доставки.

• Подписка (SVOD) – только платный доступ. Требуется DRM (управление цифровыми правами) на плеере для предотвращения несанкционированного распространения. DRM несовместим с чистым WebRTC-доставкой, поскольку шифрование WebRTC (SRTP) не является DRM. Три основных коммерческих решения – FairPlay, Widevine и PlayReady – работают на основе HLS и DASH с использованием Common Encryption (CENC). Подробнее см. в статье DRM 101.
• Ad-supported (AVOD или FAST) – бесплатный доступ, монетизация за счёт рекламы. Требуется протокол доставки с проверенной поддержкой вставки рекламы. Server-side ad insertion (SSAI) хорошо поддерживается в HLS и DASH; статья про SSAI подробно разбирает спецификацию. WebRTC не имеет встроенной поддержки рекламы: команды, которым нужно монетизировать WebRTC-стримы, обычно запускают параллельную HLS-версию для основного потока и используют WebRTC только для интерактивных элементов.
• Транзакционный (TVOD) – оплата за просмотр. Те же требования к 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 или через аутентифицированную сигнализацию. Подробности – в статье про геоблокировку.
• Требуются криминалистические водяные знаки – например, для платного спорта или контента крупных студий. Такие водяные знаки требуют либо серверной генерации вариантов, либо клиентского оверлея; оба подхода хорошо поддерживаются в HLS и DASH (см. статью про watermarking). Watermarking на WebRTC технически возможен, но не является стандартом де-факто в 2026 году и требует нестандартной операционной настройки.
• HIPAA / регулируемая медицина – телемедицина. Сам протокол не является регулируемым объектом; под контролем находятся запись, передача и хранение данных. WebRTC с DTLS- и SRTP-шифрованием – стандарт для живых консультаций, так как обеспечивает сквозное шифрование на транспортном уровне; записи дополнительно шифруются при хранении ключами KMS клиента. Статья про безопасность WebRTC подробно разбирает механизмы шифрования.

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

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

• Streaming-нативная команда (≥ 3 инженера, 1+ год опыта в стриминге) – кандидат из любого протокола из списка. Выбор делайте по техническим соображениям.
• Общая backend-команда (1–2 инженера, без опыта в стриминге) – HLS или DASH через управляемый CDN. У команды уже есть опыт работы с HTTP, и операционная история связана с ним. WebRTC, MoQ и SRT требуют узкой операционной экспертизы для надёжной эксплуатации.
• Нет инженерной команды (используете полностью управляемую платформу) – используйте протокол вашей платформы. Выбор здесь – это вендор, а не протокол.
• MoQ или HESP в продакшене сегодня – требует отдельной функции streaming-инжиниринга. 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; размер аудитории определяет, использовать single-CDN или multi-CDN стек.
• Стандартная задержка (4–15 секунд) → переходите к Узлу 2 (масштаб). Вы на пути классических HLS / DASH.
• Только VOD → отправляйте HLS + DASH через CDN с CMAF в качестве базовой упаковки. Дерево решений для VOD здесь заканчивается; более глубокий выбор – в статье про упаковку и статье про экономику CDN. Готово.

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

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

• Менее 10 000 → один CDN, однопроходный origin. Используйте LL-HLS для LL-ветки, HLS – для стандартной. Перейти к Узлу 3 (охват устройств).
• От 10 000 до 100 000 → один CDN с origin shielding, одна реплика origin на регион. Те же протоколы. Перейти к Узлу 3.
• Более 100 000 → мульти-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, плюс валидация для каждой крупной ОС.
• Embedded-устройства в скоупе → HLS через HTTP/1.1 как fallback-рендер.

К Узлу 5.

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

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

• Двустороннее аудио/видео → WebRTC с SFU. Выбор SFU – по статье про сравнение SFU. Для ингеста – нативный WebRTC или WHIP по RFC 9725.
• One-to-many трансляция, задержка менее секунды → WebRTC с WHEP для вывода по 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/В-вариантным стримингом.
• HIPAA / регулируемая медицина → WebRTC с DTLS-шифрованием и SRTP для трансляций в реальном времени; записи шифруются при хранении ключами KMS клиента.

К Узлу 7.

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

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

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

К Узлу 8.

Узел 8 – Обеспечение устойчивости к будущему

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

• Пилот 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), пассивный просмотр, поддержка рекламы и подписки, гео-ограничения, команда, ориентированная на стриминг, достаточный бюджет.

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

Путь: Узел 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, возможность записи для архива, у поставщика платформы – команда, ориентированная на стриминг.

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

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

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

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

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

Путь: дерево – для доставки. Для участия – статья про дерево выбора ингест-протокола. Короткий ответ: SRT – для сотовой ветки, RIST – как альтернатива broadcast-качественного уровня. 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 – ради простоты; используем управляемый CDN с origin shielding, аутентификацию по подписанным URL, отдельный канал реального времени для чата через 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 через управляемый eCDN (enterprise CDN – доставка с участием пиров для корпоративных сетей), аутентификация по SSO через корпоративный IdP, WebSocket-чат для вопросов и ответов. LL-HLS не используется; стандартной задержки вполне достаточно. WebRTC не применяется; общение в Q&A – текстовое.

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

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

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

Путь: Узел 1 → смешанный: субсекундная задержка для игроков, низкая задержка для зрителей. Гибридный стек. Узел 4 → one-to-many с субсекундной задержкой. Узел 5 → с поддержкой рекламы, подтверждаем HLS или DASH для зрителей. Узел 7 → нативный стриминг, передаём технический стек. Узел 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), управляемый CDN, аутентификация по подписанным URL.

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

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

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

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

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

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

Почему это неправильно: стоимость WebRTC на одну сессию в основном определяется работой SFU и алгоритмом оценки пропускной способности для каждого соединения. При 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 ради будущей устойчивости».

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

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

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

Симптом: команда выбирает WebRTC для видео, потому что продукту нужен чат в реальном времени.

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

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

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

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

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

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

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

Симптом: команда внедряет WebRTC для доставки контента, а спустя шесть месяцев понимает, что студии требуют поддержку DRM – Widevine или FairPlay.

Почему неправильно: WebRTC не поддерживает три коммерческих DRM. Они реализованы на базе HLS и DASH с использованием упаковки CENC.

Перед принятием окончательного решения по протоколу уточните у команды монетизации требования к DRM на Узле 5 дерева.

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

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

Почему это неправильно: использование одного 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 млн в облачных счетах без какой-либо пользы для пользовательского опыта.

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

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

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

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

• Выбирайте стек протоколов, а не один протокол – почти любая продакшн-система использует два-три протокола, распределённых по двум-трём уровням аудитории.
• Проходите семь входов по порядку: задержка, масштаб, охват устройств, интерактивность, монетизация, безопасность, возможности команды. Пропуск любого из них либо усложняет, либо упрощает стек чрезмерно.
• Субсекундная задержка требует 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 критериев – слой данных под этим деревом решений.
• Гибридные стеки – почему почти любой продакшн-стек использует два протокола, а не один.
• Экономика стриминг-продукта: рабочая модель – подробная арифметика на одного зрителя.