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

Опубликовано: 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-CMAF профиль 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 года. Apple добавил расширения LL-HLS в HLS Authoring Specification в 2019 году, DASH-IF опубликовал low-latency CMAF профиль DASH в 2020 году. Форма данных – всё ещё сегмент, но каждый сегмент режется на чанки по 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 Specification от сентября 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 signalling: плеер зрителя и 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) – протокол, который IETF-группа moq проектирует с 2022 года. Активный документ в 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 Mbps. На HLS исходящий с CDN – 100 000 × 4 Mbps = 400 Gbps; при $0,005 за GB на масштабе это примерно 100 000 × 4 / 8 × 3600 GB/час × $0,005 = $900 в час. На WebRTC-доставке через SFU при двадцати зрителях на vCPU SFU той же аудитории нужно 5000 vCPU SFU плюс те же 400 Gbps, добавляя $300–600 в час compute сверху того же счёта за трафик – премия в 30–60% за суб-секундную задержку. На MoQ через кешируемое реле счёт за трафик такой же, как у HLS, а compute реле – примерно одна десятая 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-реле для ранних пилотов интерактивного broadcast. Наши команды доставки поддерживают эталонные архитектуры под каждую ветку и playbook гибридного стека, который их соединяет, и регулярно переводим клиентов с одно-протокольного стека на двух- или трёх-протокольный, когда требования к задержке расходятся между классами зрителей. Ветка, на которой живёт проект сегодня, редко остаётся той же после первых ста тысяч одновременных зрителей.

Главное

• Протокол доставки – это один транспорт плюс одна форма данных плюс одна модель доставки. Три независимых выбора.
• Восемь именованных протоколов везут практически весь интернет-видео-трафик 2026 года на четырёх связных ветках одного дерева.
• HTTP-сегментированная (HLS, DASH) – дёшево и высокая задержка; HTTP-чанкованная (LL-HLS, LL-DASH) – средняя задержка за небольшую премию.
• WebRTC-доставка суб-секундная, но платит compute за каждого зрителя; 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) – одна страница, восемь протоколов, три выбора каждого, пол задержки и форма стоимости – печатается на стену.