Дерево протоколов доставки видео

Опубликовано: 2026-05-21 · Время чтения: 16 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-21 со спецификациями IETF RFC 8216 (HLS), ISO/IEC 23009-1:2022 (DASH), ISO/IEC 23000-19:2024 (CMAF), Apple HLS Authoring Specification ревизия 2025-09, IETF RFC 9000 (QUIC), IETF RFC 9114 (HTTP/3), IETF RFC 9725 (WHIP, март 2025), draft-ietf-wish-whep-04, draft-ietf-moq-transport-17 (январь 2026), W3C WebRTC 1.0 Recommendation (март 2023), Bitmovin Video Developer Report 2025.

TL;DR

Восемь протоколов распространения обеспечивают почти весь трафик прямых трансляций и VOD в публичном интернете 2026 года, и каждый из них представляет собой конкретную комбинацию трёх решений: транспортный протокол (TCP, UDP или QUIC), формат данных на линии (сегмент, чанк или RTP-пакет) и модель доставки (HTTP pull, HTTP push, peer-to-peer). «Семейное дерево» строится на этих трёх осях и объясняет, почему HLS и DASH – родные братья, почему LL-HLS и LL-DASH – двоюродные, почему WebRTC и MoQ находятся на противоположной стороне семейного древа, а RTMP – это прадед, которого больше не приглашают на семейные встречи. Как только вы научитесь определять три ключевых выбора, сделанных каждым протоколом, матрица задержек, масштабируемости, стоимости и поддержки устройств перестаёт казаться случайной – она становится логическим следствием этих решений. После прочтения этой статьи вы услышите любую фразу «мы используем HLS» и сразу зададите три уточняющих вопроса, которые помогут понять, был ли выбор обоснованным.

Почему это важно

Почти любой спор о протоколах стриминга – «дойдём ли до секунды задержки?», «почему растёт счёт за CDN?», «заработает ли это на смарт-ТВ?» – сводится к выбору протокола, а выбор протокола – к одному трёхосному решению, которое команда могла даже не зафиксировать письменно. Менеджер продукта, знающий «семейное дерево» протоколов, смотрит на архитектурную схему, видит гибридный стек и предсказывает структуру счёта без помощи инженеров. Инженер, владеющий этим деревом, объясняет выбор протокола одной фразой – «мы используем LL-HLS, потому что нужна задержка в три секунды на iOS без оплаты за каждого зрителя» – вместо сорокаминутной презентации. Эта статья – карта местности перед тем, как вы начнёте читать глубокие разборы Блока 4. Прочитайте её перед статьями по HLS, DASH, CMAF, WebRTC, WHEP, HESP и MoQ: всё, что там описано, ложится на дерево, которое вы здесь построите.

Три выбора, из которых складывается протокол доставки

Протокол доставки – это набор правил, по которым видеопоток передаётся с сервера (или пира) к плееру через публичный интернет. Этот набор всегда отвечает на три ключевых вопроса, и именно ответы на них определяют, к какой ветви «семейного дерева» относится протокол. Запомните эти три вопроса – и вы сможете определить место любого протокола в этой классификации, даже не изучая его спецификацию.

Первый вопрос: по какому транспортному слою передаются байты. Интернет предлагает три серьёзных варианта. TCP – соединение-ориентированный транспорт, разработанный для передачи файлов; он гарантирует, что каждый байт приходит в правильном порядке, повторно запрашивает потерянные данные и ждёт столько, сколько нужно. Для скачивания ISO это идеально, для прямого эфира – плохо: пятисотмиллисекундная повторная передача означает пятисотмиллисекундную заморозку изображения. UDP – транспорт без установления соединения; он отправляет датаграммы и тут же забывает о них; обнаружение потерь и решение, что с ними делать, – задача приложения. QUIC, опубликованный как RFC 9000 в 2021 году, работает поверх UDP, добавляет зашифрованное рукопожатие, мультиплексируемые независимые потоки и возможность миграции соединения; для стриминга QUIC удобно представлять как «надёжность TCP, когда она нужна, и скорость UDP, когда не нужна – в одном протоколе».

Второй вопрос: какую форму данные принимают на проводе. Две доминирующие формы – сегменты (готовый файл на 2–6 секунд видео, скачиваемый целиком по HTTP) и RTP-пакеты (короткие пакеты реального времени, отправляемые сразу после их создания энкодером – обычно 10–60 мс аудио или один слайс видеокадра). Третья форма – чанки – находится между ними: чанк – это часть сегмента, которую плеер может начать скачивать ещё до завершения кодирования остальной части сегмента. Большинство низколатентной HTTP-доставки в 2026 году – это именно чанки.

Третий вопрос: кто инициирует разговор. HTTP pull: плеер сам запрашивает у сервера следующий фрагмент, когда ему это нужно; сервер пассивен, плеер – инициатор, а всё, что стоит между ними (кеш, CDN, edge), работает как обычный веб-кеш. HTTP push похож, но сервер заранее предлагает или «подталкивает» следующий фрагмент до того, как плеер запросит его. Peer signalling (WebRTC и современные наследники – WHIP, WHEP, MoQ) устроено иначе: сервер и клиент (или два клиента) заранее согласовывают сессию, после чего медиа передаются по постоянно открытому каналу, и промежуточного кеша нет.

Любой протокол, названный в 2026 году, – это конкретная комбинация одного транспорта, одного формата данных и одной модели доставки. Назовите три компонента протокола – и вы предскажете его задержку, масштабируемость и совместимость с устройствами, не открывая ни одной спецификации.

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

Семейное дерево

Картинка ниже – карта. Читайте её сверху вниз: корень делится на HTTP-доставку (левая сторона) и доставку в реальном времени (правая). HTTP-доставка подразделяется на сегментированную (HLS, DASH) и низколатентную чанкованную (LL-HLS, LL-DASH, chunked-HTTP профиль DASH). Доставка в реальном времени делится на UDP (WebRTC, WHEP) и QUIC (MoQ, HESP). RTMP находится сбоку как устаревший протокол контрибуции, который больше не используется для доставки зрителю.

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

Каждая ветка соответствует определённому набору компромиссов.

Ветка 1 – HTTP-сегментированная (HLS, DASH)

Старейшая живая ветка. Apple представил HLS в 2009 году (позже стандартизированный как RFC 8216), MPEG опубликовал первое издание DASH в 2012 году (ныне ISO/IEC 23009-1:2022). Формат данных – сегмент: готовый файл продолжительностью 2–6 секунд, сегодня чаще всего – fragmented MP4. Транспортная среда – TCP, передаваемый через HTTP/1.1 или HTTP/2. Модель доставки – HTTP pull: плеер загружает манифест (.m3u8 для HLS, .mpd для DASH), анализирует, какие сегменты доступны, и запрашивает их по очереди.

Цифры, вытекающие из этой ветки, предсказуемы. Задержка glass-to-glass составляет 15–45 секунд при типичной структуре из шестисекундных сегментов: плееру нужно дождаться завершения записи сегмента, затем его загрузки на CDN и, наконец, начать воспроизведение после буферизации одного–двух сегментов. Экономика масштаба здесь отличная: каждый сегмент – это статический файл, и любой кэш перед ним отдаёт его бесплатно после первого промаха; оплата за CDN идёт только за исходящий трафик, без дополнительных сборов. Поддержка устройств универсальна: каждый браузер, каждый смарт-ТВ, каждый Roku и каждая платформа iOS поддерживают как минимум один из форматов – HLS или DASH – нативно или через небольшой JavaScript-плеер. По данным Bitmovin Video Developer Report 2025 и Conviva 2026 State of Streaming, эта ветка обеспечивает около 80% всех часов прямых эфиров в 2026 году и практически 100% долгоформатного VOD.

Ветка 2 – HTTP-чанковая, низколатентная (LL-HLS, LL-DASH)

Ветка после 2020 года. В 2019 году Apple добавил расширения LL-HLS в спецификацию HLS Authoring, а в 2020 году DASH-IF опубликовал профиль low-latency CMAF для DASH. Форма данных остаётся сегментной, но каждый сегмент делится на чанки длительностью 200–500 мс (в HLS используются части EXT-X-PART, в DASH – chunked transfer encoding CMAF-чанков), и плеер может начать скачивать чанк ещё до завершения кодирования остальной части сегмента. Транспортная основа – TCP поверх HTTP/1.1 или HTTP/2: Apple убрал требование HTTP/2 push из LL-HLS в ревизии спецификации HLS Authoring от сентября 2023 года, поэтому статьи, утверждающие, что HTTP/2 push является обязательным, устарели. Модель доставки – HTTP pull с двумя дополнительными механизмами: блокирующей перезагрузкой плейлиста, preload hints и отчётами о выбранных версиях (rendition reports).

Задержка glass-to-glass снижается до 2–5 секунд. История с CDN остаётся эффективной – чанки по-прежнему являются кешируемыми HTTP-ответами, хотя origin shielding и tiered caching теперь требуют настройки под новый темп запросов. Поддержка устройств стала широкой, но не универсальной: нативный LL-HLS работает на iOS 14+ и tvOS 14+; LL-DASH требует JavaScript-плеера (Shaka, dash.js, DASH-режим в hls.js) в браузерах и на смарт-ТВ. Ветка покрывает около 10% часов прямых эфиров в 2026 году и является стандартным выбором для новых развёртываний, когда нужна задержка ниже десяти секунд при сохранении фиксированной стоимости на зрителя.

Ветка 3 – UDP в реальном времени (WebRTC delivery, WHEP)

Ветка реального времени справа от дерева. WebRTC, утверждённый как W3C Recommendation в марте 2023 года и основанный на семействе RFC 8825–8866, изначально разрабатывался для звонков один-на-один; однако индустрия адаптировала его для сценариев один-ко-многим, маршрутизируя каждого зрителя через Selective Forwarding Unit (SFU). WHEP – WebRTC-HTTP Egress Protocol, на январь 2026 года это draft-ietf-wish-whep-04 – представляет собой тонкий HTTP-слой сигнализации поверх WebRTC, который делает подключение браузерного зрителя таким же простым, как использование тега <video>.

Форма данных – RTP-пакеты. Транспорт – UDP с шифрованием DTLS- и SRTP (RFC 5764). Модель доставки – peer-to-peer-сигнализация: плеер зрителя и SFU обмениваются SDP-offer/answer, ICE-кандидаты проходят через STUN/TURN, после чего медиа-трафик идёт по постоянно открытому peer-connection. Задержка glass-to-glass составляет 200–500 мс.

История масштабирования противоположна HTTP-доставке: каждый зритель – полноценный WebRTC-пир на стороне SFU, бэкенд оплачивает CPU и трафик для каждого зрителя, и стоимость растёт линейно с числом одновременных зрителей, а не с объёмом переданных данных. Ветка покрывает около 7% часов прямых эфиров в 2026 году, сосредоточенных в интерактивных сценариях – живые аукционы, оверлеи для ставок, двусторонние занятия, телемедицина, киберспорт, видеоконференции, транслируемые в публичную аудиторию.

Ветка 4 – QUIC реального времени (Media over QUIC, HESP)

Новая ветка, ещё в разработке. Media over QUIC (MoQ) – протокол, над которым с 2022 года работает рабочая группа IETF moq. Активная версия документа ожидается в 2026 году – draft-ietf-moq-transport-17 (январь 2026). Данные передаются в виде QUIC-потоков (единица – «объект» MoQ), транспортная основа – QUIC поверх UDP (RFC 9000), модель доставки – publish/subscribe: продюсер публикует контент в реле, подписчики подключаются к этому реле, а реле обеспечивает multicast в рамках одного QUIC-соединения. Cloudflare поддерживает публичное MoQ-реле более чем в 330 городах по состоянию на 2026 год; Meta и Twitch используют собственные внутренние реле; на демо-сессии NAB 2026 одиннадцать независимых реализаций успешно взаимодействовали в одной сети. HESP (семейство draft-theo-hesp) – более узкая, вендорская альтернатива, обеспечивающая задержку менее одной секунды через HTTP/2 и HTTP/3 с использованием двух синхронизированных потоков: «инициализационного» и «инкрементального». Протокол уже используется в продакшене у клиентов THEO Technologies, однако он не совместим с MoQ.

Задержка glass-to-glass на этой ветке составляет от 200 мс до 1 с, и – что уникально – протокол масштабируется как HTTP (реле кешируются, fan-out на реле – многие-ко-многим), но доставляет данные как WebRTC (субсекундная задержка, без сегментов). Поэтому каждая крупная команда стриминга следит за этой веткой. Продовая доля в 2026 году остаётся небольшой (≤ 3% часов прямых эфиров), но рост – самый стремительный среди всех веток.

Изгой – RTMP

RTMP, протокол от Adobe, опубликованный в 2002 году и фактически заброшенный в 2012-м, висит на дереве технологий лишь пунктирной веткой сбоку. RTMP для распространения (сервер → плеер) мёртв: браузеры отказались от Flash в 2020 году, и почти ни один современный плеер больше не поддерживает RTMP. RTMP для ingest (энкодер → сервер) – нерушимый стандарт по умолчанию: OBS, vMix, любая бытовая стриминговая техника, YouTube Live, Twitch, Facebook Live, эндпоинты прямых трансляций всех CDN по-прежнему принимают RTMP, потому что каждый энкодер по-прежнему на нём «говорит». Эту асимметрию мы разбираем в RTMP в 2026: мёртвый протокол, бессмертный дефолт.

Шпаргалка по протоколам

Восемь протоколов, три выбора каждого, пол задержки, форма стоимости, доминирующий сценарий 2026 года. Читайте по строкам, чтобы понять назначение протокола; по столбцам – чтобы сравнить их по одной оси.

Численный пример, делающий стоимость конкретной: представим 100 000 одновременных зрителей потока 1080p со скоростью 4 Мбит/с. При использовании HLS исходящий трафик через CDN составит 100 000 × 4 Мбит/с = 400 Гбит/с; при цене $0,005 за ГБ на таком масштабе это примерно 100 000 × 4 / 8 × 3600 ГБ/час × $0,005 = $900 в час. При доставке через WebRTC с SFU, где на один vCPU приходится двадцать зрителей, для той же аудитории потребуется 5000 vCPU SFU плюс те же 400 Гбит/с трафика, что добавляет $300–600 в час на вычислительные ресурсы поверх той же платы за трафик – премия в 30–60% за субсекундную задержку. При использовании MoQ через кешируемое реле стоимость трафика остаётся такой же, как у HLS, а вычислительные затраты реле – примерно одна десятая от SFU на зрителя; общая стоимость снова приближается к уровню HLS, при этом сохраняя субсекундную задержку. Именно эта сходимость и объясняет, почему индустрия так внимательно следит за развитием технологии.

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

Распространённая ошибка: «мы взяли HLS»

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

Типичный OTT-продукт для трансляций событий 2026 года использует LL-HLS для зрителей на iOS и Apple TV, LL-DASH – для всех остальных, плюс небольшую WebRTC-накладку для возвратного монитора ведущего и интерактивного бэкчат-канала модератора – три протокола, один продукт.

Типичный продукт видеоконференций 2026 года работает с WebRTC для интерактивных участников и LL-HLS для зрителей в режиме просмотра, подключающихся по публичной ссылке – два протокола, один продукт.

Типичный продукт видеонаблюдения 2026 года использует WebRTC для прямого эфира оператора и HLS для воспроизведения записей – два протокола, один продукт.

Вопрос «какой протокол вы используете?» даёт ответ неправильной формы. Правильная формулировка: «Какой протокол использует каждый класс зрителей, каков бюджет задержки для каждого класса и где происходит переключение протокола?» Архитектуры рассмотрены в статье Реальность переключения протоколов: гибридные стеки.

Парная ошибка – это матрица решений «один протокол на всех», которую иногда демонстрируют в презентациях вендоров: один столбец «наша рекомендация», указывающий на HLS или WebRTC для каждой строки. Настоящие рекомендации носят матричный характер. Подробности – в статье Выбор протокола доставки в 2026: дерево решений.

Где работает Фора Софт

С 2005 года Фора Софт выпустила продукты по каждой ветви этого семейного дерева – HLS- и DASH-бэкбоны для OTT и телемедицины, LL-HLS для онлайн-обучения, WebRTC SFU для видеоконференций и AR/VR-коллаборации, MoQ-реле для ранних пилотов интерактивного вещания. Наши команды доставки поддерживают эталонные архитектуры для каждой ветви и playbook гибридного стека, который их объединяет, и регулярно помогают клиентам перейти с одно- на двух- или трёхпротокольный стек, когда требования к задержкам различаются между классами зрителей. Ветка, на которой сегодня живёт проект, редко остаётся той же после первых ста тысяч одновременных зрителей.

Главное

• Протокол доставки – это один транспорт, одна форма данных и одна модель доставки. Три независимых выбора.
• Восемь именованных протоколов обеспечивают почти весь трафик интернет-видео в 2026 году, объединённые в четыре связанные ветки одного дерева.
• HTTP-сегментированная (HLS, DASH) – дёшево, но с высокой задержкой; HTTP-чанкованная (LL-HLS, LL-DASH) – средняя задержка при небольшой дополнительной стоимости.
• WebRTC обеспечивает субсекундную доставку, но требует вычислительных ресурсов на каждого зрителя; MoQ – первый субсекундный протокол, способный масштабироваться так же, как HLS.
• Реальные продукты используют два-три протокола, а не один – фраза «мы взяли HLS» редко является полным ответом.
• RTMP для распространения мёртв; RTMP для приёма сигнала (ingest) до сих пор присутствует в каждом энкодере.

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

• HLS подробный разбор: m3u8, сегменты, мультивариантные плейлисты – детальное рассмотрение сегментированной ветки.
• LL-HLS подробный разбор: parts, preload hints, blocking reload, rendition reports – детальное рассмотрение чанкованной ветки.
• Media over QUIC (MoQ) подробно: поворотный момент 2026 года – новая ветка.

Что сделать дальше

• Поговорить с инженером по стримингу – подготовьте целевую задержку, разбивку по классам зрителей и счёт за CDN. За 30 минут мы интегрируем ваш продукт в «семейное дерево» протоколов.
• Посмотреть наши кейсы – OTT, телемедицина, AR/VR, видеоконференции, видеонаблюдение, онлайн-обучение. По одному примеру на каждую ветвь.
• Скачать Шпаргалку по семейному дереву протоколов доставки (PDF) – одна страница, восемь протоколов, три выбора каждого, пол задержки и форма стоимости – идеально для печати на стену.