Протоколы стриминга: 8 главных в 2026 году

TL;DR

Протокол стриминга – это набор правил, по которым сжатое видео передаётся от камеры или файла на экран зрителя – вовремя и без обрывов. В природе существует десятки таких протоколов, но в 2026 году подавляющую часть реального видеотрафика обеспечивают всего восемь: HLS, MPEG-DASH, LL-HLS, LL-DASH (CMAF chunked), WebRTC, WHIP/WHEP, SRT и RTMP, плюс два претендента – RIST и MoQ, – которых должен знать по имени каждый, принимающий решения. Выберите правильные два-три – получите дешёвое, надёжное, низколатентное видео на любом устройстве клиента; выберете не те – будете годами бороться со своей инфраструктурой. Эта статья объясняет каждый из восьми простым языком, с цифрами и компромиссами, которые на самом деле определяют ответ.

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

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

Первое – задержка: увидят ли зрители гол раньше или позже соседей. Разница между 30 секундами и 0,5 секунды – это разница между живым и мёртвым продуктом, особенно когда речь идёт об аукционах, ставочных платформах или многопользовательских играх.

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

Третье – охват плееров: если протокол не поддерживается, он просто не запустится в Safari на iPhone или на смарт-телевизоре Samsung, и эта аудитория уходит, даже не дождавшись, пока вы поймёте, в чём дело.

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

Что вообще должен делать протокол стриминга

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

Во-первых, протокол должен донести биты. Кодировщик выдаёт поток сжатых кадров; плеер должен их потребить в правильном порядке. Где-то посередине сеть – публичный Wi-Fi кафе, 5G телефона, оптика домой – обязана переслать байты без слишком больших потерь.

Во-вторых, протокол должен остаться во времени. Видео крайне чувствительно к задержкам: если кадр 7 200 приходит с опозданием на 50 мс, плеер либо замораживает изображение (что замечают зрители), либо пропускает кадр (что тоже замечают), либо отстаёт от реального времени и не может его догнать (что замечают все). Задача протокола – этого не допустить: пакеты передаются с таймкодами, на приёмной стороне они восстанавливаются в правильном порядке, а мелкие потери маскируются различными хитростями.

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

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

В-пятых, протокол должен работать на устройстве. Даже идеально спроектированный протокол бесполезен, если он не функционирует на полумиллиарде активных iPhone или на миллионах смарт-ТВ со старыми браузерами. Поддержка платформ – не опция, а необходимое условие, без которого остальные четыре задачи просто не могут быть решены.

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

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

Важное разделение: вклад против доставки

Самое важное разделение в этой статье – граница между контрибуцией и доставкой. Непонимание этой границы – самая распространённая ошибка в продуктовом планировании.

Контрибуция – это участок пути от камеры до вашей видеоинфраструктуры. Обычно речь идёт об одном потоке, одном источнике, одном операторе и достаточной пропускной способности со стороны камеры. Сеть может быть нестабильной (репортёр на крыше стадиона, хирург в больничной Wi-Fi-сети, стример в кофейне), но аудитория всегда одна – ваш сервер. Контрибуционные протоколы рассчитаны на надёжную работу в условиях плохой сети при небольшом числе источников и высоком качестве. RTMP, SRT, RIST и WHIP – примеры контрибуционных протоколов.

Доставка – это участок пути от вашей видеоинфраструктуры до зрителя. Зрителей может быть один или десять миллионов, и протокол должен обеспечить доставку каждому из них через кэши. Сторона производителя (ваш сервер) – идеальная сеть; сторона потребителя (зритель) – реальная, с её ограничениями. Протоколы доставки оптимизированы для дешёвого масштабирования через CDN на огромные аудитории, даже если у каждого зрителя слабый Wi-Fi. HLS, DASH, LL-HLS, LL-DASH и клиентские части WebRTC и WHEP – всё это протоколы доставки.

Типичный live-продукт использует два протокола: один – для ингеста, другой – для раздачи. Концерт 2026 года обычно строится по схеме SRT → сервер → LL-HLS для зрителей и WebRTC – для режиссёрского монитора на сцене. В отличие от этого, типичная видеоконференция не разделяет потоки и использует единый протокол – WebRTC – для всех задач, поскольку каждый участник одновременно выступает и как источник, и как получатель контента.

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

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

Где живёт задержка и почему числа так разные

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

Различие велико, потому что протоколы добавляют задержку в разных местах. Видео из кодировщика уже содержит встроенную задержку – кодировщик буферизует несколько кадров (около 100 мс у real-time-энкодера, несколько секунд у качественного). Контрибуционный протокол добавляет небольшую задержку на пересылку потерянных пакетов (10–300 мс). Упаковщик, разделяющий поток на сегменты, вводит задержку на сборку (2–10 с у обычного HLS, 200 мс–1 с у chunked CMAF). CDN добавляет ещё немного – 50–500 мс на передачу по сети и прохождение через кэш. В конце плеер добавляет буфер воспроизведения, чтобы не прерывать поток при временных сбоях (1–30 с в зависимости от протокола и настроек плеера). Всё это складывается.

Опубликованная задержка протокола – это сумма всех этапов в типичных условиях. WebRTC обеспечивает задержку 0,5–1 с, потому что агрессивно минимизирует каждый шаг: маленький буфер кодировщика, немедленная отправка, отсутствие упаковки в сегменты, минимальный буфер воспроизведения. Обычный HLS работает с задержкой 15–30 с из-за щедрых запасов на каждом этапе: большие сегменты, мультисегментный буфер плеера, частый опрос манифеста с запасом времени. LL-HLS живёт посередине – на уровне 2–8 с: сохраняет большинство резервов, но уменьшает размер сегментов и задержку опроса манифеста.

Цифры в маркетинговых материалах вендоров – это минимальные значения, полученные в идеальных условиях; реальная задержка в продакшене обычно на 20–50 % выше, поскольку каждый слой каждой системы в реальных условиях работает консервативнее, чем на стенде.

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

HLS – стандарт по умолчанию, на котором держится открытый интернет

HLS – сокращение от HTTP Live Streaming – самый распространённый протокол стриминга в мире. Apple разработала его в 2009 году для воспроизведения видео на iPhone; в 2017 году он был опубликован как RFC 8216. Сегодня на нём работает подавляющее большинство live- и VOD-видео в открытом интернете, включая большую часть мобильного YouTube, почти все стриминговые приложения на iPhone и значительную долю контента на смарт-ТВ. 1 Если бы пришлось выбрать только один протокол на всю карьеру, это был бы HLS.

HLS работает следующим образом: видео разбивается на короткие файлы – сегменты, обычно длительностью 2–10 секунд, и создаётся небольшой текстовый файл – манифест или плейлист с расширением .m3u8, содержащий список сегментов в правильном порядке. Плеер сначала скачивает манифест, затем первые несколько сегментов, начинает воспроизведение и далее периодически проверяет манифест на наличие новых сегментов.

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:1024
#EXTINF:6.000,
segment-1024.m4s
#EXTINF:6.000,
segment-1025.m4s
#EXTINF:6.000,
segment-1026.m4s

Из этого устройства вытекают три вещи, объясняющие победу HLS.

Во-первых, HLS работает поверх обычного HTTP. Каждый веб-сервер, каждый CDN, каждый firewall и каждый прокси в мире уже умеют отдавать HTTP-файлы. Никаких отдельных стриминг-серверов, никаких специальных портов, никакого кастомного согласования протокола; вы кладёте сегментные файлы за CDN, и CDN раздаёт их как любые другие статические объекты. Поэтому HLS масштабируется до десяти миллионов одновременных зрителей по цене счёта за трафик CDN – это дешевле любой другой технологии доставки на одного зрителя с заметным отрывом.

Во-вторых, HLS подстраивается под скорость интернета зрителя. Издатель кодирует одно и то же видео в нескольких уровнях качества – например, 1080p при 5 Мбит/с, 720p при 2,5 Мбит/с, 480p при 1 Мбит/с, 240p при 400 кбит/с – и манифест содержит список всех этих вариантов. Плеер измеряет скорость загрузки сегментов и автоматически переключается между уровнями, когда сеть улучшается или ухудшается. Зритель не видит буферизацию, пока скорость не упадёт ниже самого низкого уровня. Это называется адаптивным битрейт-стримингом, и именно благодаря ему видео в современном интернете работает стабильно.

В-третьих, HLS – единственный протокол, который Safari от Apple воспроизводит нативно без JavaScript-полифилла. Примерно одна пятая часть просмотров в открытом интернете приходится на Safari. Продукт, не поддерживающий HLS, теряет эту аудиторию или вынужден платить инженерную цену за полифилл на каждой странице. Именно этот факт десятилетиями держал HLS на вершине и будет удерживать ещё одно десятилетие.

Главная слабость HLS – задержка. Сегменты длятся 2–10 секунд, плеер хранит три сегмента в запасе, манифест обновляется только при появлении новых сегментов; суммарная задержка обычно составляет 15–30 секунд между камерой и экраном. Для фильма или вебинара в записи это не критично, но для прямого эфира футбольного матча – недопустимо. Эту проблему решает LL-HLS, о котором речь пойдёт ниже.

По данным Bitmovin Video Developer Report 2025/26, HLS остаётся доминирующим протоколом доставки в продакшене – его используют почти 90 % опрошенных инженеров, – но достиг плато: «планы использовать его в будущем – на историческом минимуме», поскольку DASH, LL-DASH и унификация через CMAF постепенно вытесняют его в новых развёртываниях. 2 Вывод не в том, что «HLS умирает», а в том, что «HLS зрелый».

MPEG-DASH – открытый стандарт с той же целью

MPEG-DASH – сокращение от Dynamic Adaptive Streaming over HTTP – открытый стандарт ISO/IEC, разработанный в ответ на HLS. Финализирован как ISO/IEC 23009-1 в 2012 году и несколько раз пересматривался. 3 По сути выполняет ту же задачу, что и HLS: разбиение на сегменты, использование манифеста, доставка по HTTP, адаптивный битрейт – но в другом формате файлов и с совершенно иным манифестом.

Различия с HLS в основном косметические и исторические. DASH называет свой манифест MPD – Media Presentation Description – и использует формат XML, в отличие от простого текстового формата HLS. DASH изначально разработан как кодеконезависимый (поддерживает любой кодек), тогда как HLS изначально поддерживал только H.264, а поддержку HEVC и AV1 добавил позже. DASH с самого начала проектировался с учётом патентной чистоты – он развёртывается без роялти; HLS на практике тоже свободен от роялти, но тесно интегрирован с инструментами Apple.

В работе протоколы сошлись. С момента финализации Common Media Application Format, или CMAF, в 2017 году один и тот же набор сегментных файлов может одновременно описываться как HLS-манифестом, так и DASH-манифестом. 4 Издатель кодирует видео один раз, упаковывает один раз и доставляет через оба протокола из одного и того же CDN. В 2026 году это – стандартная схема, и мы к ней ещё вернёмся.

Главное преимущество DASH перед HLS – он не зависит от Apple: это ISO-стандарт, что делает его естественным выбором в тех случаях, где важна вендорная нейтральность (например, вещание, европейские общественные СМИ, корпоративные среды). Главный недостаток – Safari не поддерживает DASH нативно, поэтому использование только DASH означает потерю доступа с каждого iPhone в мире. На практике почти никто не использует исключительно DASH: HLS применяют для устройств Apple, а DASH (часто на основе тех же CMAF-файлов) – для всех остальных платформ.

LL-HLS – низколатентный HLS от Apple

LL-HLS – сокращение от Low-Latency HLS – это ответ Apple на проблему задержек в HLS. Компания представила его на WWDC 2019, интегрировала в основную спецификацию HLS, а в 2020 году убрала требование использования HTTP/2 push, чтобы протокол лучше работал с CDN. 5 К 2026 году он стал зрелым и поддерживается всеми крупными CDN.

LL-HLS добавляет три ключевые особенности к стандартному HLS, чтобы сократить задержку с 15–30 секунд до 2–8 секунд. Во-первых, каждый сегмент делится на более мелкие части – частичные сегменты или parts, обычно длительностью 200–400 мс. Плеер может начать воспроизводить часть (part), как только она загружена, не дожидаясь завершения всего сегмента. Во-вторых, изменяется способ обновления манифеста: вместо периодического запроса «появились новые сегменты?» плеер отправляет запрос «отправь манифест, как только появится сегмент N», и сервер удерживает соединение открытым до тех пор, пока не сможет ответить. Этот механизм называется blocking playlist reload. В-третьих, манифест включает preload hints – прямые URL следующего part, который нужно загрузить, – чтобы плеер мог сразу отправить запрос в момент готовности нового фрагмента.

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-TARGETDURATION:4
#EXT-X-PART-INF:PART-TARGET=0.330
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.0
#EXT-X-MEDIA-SEQUENCE:1024
#EXTINF:4.000,
segment-1024.m4s
#EXT-X-PART:DURATION=0.330,URI="segment-1025.0.m4s"
#EXT-X-PART:DURATION=0.330,URI="segment-1025.1.m4s"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="segment-1025.2.m4s"

Цена низкой задержки – эффективность трафика. LL-HLS (LL-HLS) платит за это гораздо большим числом мелких HTTP-запросов: накладные расходы растут обратно пропорционально размеру части. В продакшене LL-HLS добавляет 5–15 % к счёту CDN по сравнению с обычным HLS при том же качестве изображения и примерно столько же – на origin. Стоит ли это снижения задержки – зависит от задачи: очевидно стоит для трансляций спорта, почти никогда – для VOD.

LL-DASH – DASH с CMAF и передачей по частям

LL-DASH, иногда называемый CMAF Low Latency – параллельный ответ из мира DASH на ту же задачу. Использует тот же приём – разрезание сегмента на доли секунды и отправку по мере готовности, – но через HTTP chunked transfer encoding, а не отдельные файлы для каждого фрагмента. 6 Реальные развёртывания достигают задержки от экрана до экрана в 2–5 секунд, сопоставимой с LL-HLS.

Почему на одну и ту же задачу два разных ответа? Потому что индустрия рано разделилась на HLS и DASH и так и не смогла объединиться. Apple представила LL-HLS (LL-HLS), чтобы сохранить контроль над своей экосистемой, а DASH Industry Forum – LL-DASH для всех остальных. Если поток упакован с использованием правильного CMAF, одни и те же файлы можно использовать как для LL-HLS, так и для LL-DASH – конвергенция снова происходит на уровне формата файла, а не протокола.

Прагматичное развёртывание 2026 года использует CMAF с chunked encoding, чтобы получить единый набор файлов, и выставляет их как LL-HLS для Apple и LL-DASH для других платформ, применяя один и тот же конфигурационный файл CDN edge для обоих протоколов. Отчёт DASH-IF CR-Low-Latency-Live подтверждает задержку glass-to-glass на уровне 2–4 секунды в продакшене при использовании этого стека. 6

WebRTC – протокол, работающий в реальном времени

WebRTC – сокращение от Web Real-Time Communication – это протокол, лежащий в основе видеозвонков, видеоконференцсвязи и прямых трансляций, где любая задержка более одной секунды недопустима. Он стандартизован W3C и IETF как набор API для браузеров и сопутствующих транспортных протоколов; каждый современный браузер, операционная система и мобильная платформа поставляют WebRTC-стек «из коробки». 7

Протокол принципиально отличается от HLS и DASH: здесь нет сегментов и манифестов. Используется прямое соединение peer-to-peer (или peer-to-server) по UDP – User Datagram Protocol, базовому интернет-протоколу «выстрелил и забыл» – и непрерывный поток медиа. Потерянные пакеты не запрашиваются повторно – их компенсирует кодек, настроенный на устойчивость к потерям. Кодировщик работает в режиме минимальной задержки, плеер поддерживает буфер из одного–двух кадров, и изображение появляется на экране через 200–800 мс после съёмки.

Это делает WebRTC единственным протоколом из списка, способным к двусторонней интеракции: видеозвонки, удалённое переключение режиссёра, аукционы со ставками в реальном времени, чат зрителей в игре, телемедицинские консультации. Это также единственный массовый протокол, не требующий сегментации и CDN: вместо этого он использует сеть SFU – Selective Forwarding Unit – которая копирует один входящий поток на множество исходящих без перекодирования.

Цена – операционная сложность. WebRTC-пайплайн требует сигнального сервера для согласования соединения, STUN-сервера для определения публичного IP каждого пира, а часто и TURN-сервера для ретрансляции через firewall, а также SFU-решения для масштабирования свыше нескольких участников. Стоимость одной зрительской минуты в разы выше, чем у HLS при том же качестве. WebRTC – правильный выбор для десяти тысяч одновременных участников интерактивного аукциона; но не подходит для десяти миллионов односторонних зрителей концерта, где HLS или LL-HLS значительно дешевле в расчёте на пользователя.

Где WebRTC реально приносит деньги в 2026 году: видеоконференцсвязь (Zoom, Google Meet, Microsoft Teams), live-шопинг (Whatnot, TikTok Shop), интерактивные аукционы (Sotheby’s live bidding), онлайн-образование (платформы с двусторонней связью между учителем и учеником), телемедицина и самые требовательные live-спортивные ставки.

WHIP и WHEP – стандарты ингеста и эгресса WebRTC

Большую часть своей истории WebRTC в продакшене страдал от отсутствия стандартного способа отправить один однонаправленный поток на сервер или с него без необходимости писать весь SFU- и сигнальный код с нуля. Каждый вендор придумывал свой сигнальный протокол, а каждый производитель камер или энкодеров интегрировал каждую стриминговую платформу отдельно. В 2025–2026 годах это наконец изменилось.

WHIP – сокращение от WebRTC-HTTP Ingestion Protocol – это IETF-стандарт, позволяющий энкодеру отправить один WebRTC-поток на стриминговый сервер с помощью одного HTTP POST. Опубликован как RFC 9725 в марте 2025 года. 8 WHEP – WebRTC-HTTP Egress Protocol – параллельный стандарт, предназначенный для получения WebRTC-потока с сервера через один HTTP GET. На начало 2026 года находится в статусе draft-ietf-wish-whep-03 и движется к публикации в виде RFC. 9

Главное, что делают WHIP и WHEP – заставляют WebRTC с точки зрения оператора вести себя как RTMP: один URL, один поток, один POST. Энкодер больше не нуждается в реализации кастомного сигналинга; серверу не требуется поддерживать кастомный сигналинг под каждого производителя камер. WHIP уже нативно поддерживаются OBS Studio (доминирующим открытым инструментом для live-стримов), FFmpeg, большинством профессиональных аппаратных энкодеров и каждой крупной стриминговой платформой. Связка WHIP для ингеста и LL-HLS/LL-DASH для доставки – самый чистый стек «низкая задержка, широкий охват», который новый продукт может выбрать в 2026 году.

Цифры Bitmovin Video Developer Report 2025/26 это подтверждают: впервые за девятилетнюю историю отчёта SRT и WebRTC-ингест класса WHIP вместе превысили RTMP по использованию в live-контрибуции в развёртываниях респондентов. 2 Десятилетняя эра доминирования RTMP в ингесте стриминга подходит к концу.

SRT – рабочая лошадка стриминга, пришедшая на смену RTMP

SRT – сокращение от Secure Reliable Transport – открытый контрибуционный протокол, ставший стандартом де-факто для передачи видео в стриминговый пайплайн. Компания Haivision разработала его в 2013 году, чтобы решить задачу «доставить видео broadcast-качества по публичному интернету без использования спутниковой связи», а в 2017 году открыла исходный код. Сегодня это самый распространённый видеоконтрибуционный протокол в вещательной индустрии: по данным 2026 года, им пользуются 78 % опрошенных специалистов в области вещания – против 47 % в 2020 году. 10

SRT работает поверх UDP – как и WebRTC, – но добавляет агрессивный слой повторной передачи и коррекции ошибок, ориентированный на «небольшое число высокобитрейтных потоков в нестабильной сети». Типичная SRT-сессия выдерживает до 12 % устойчивых потерь и при этом обеспечивает доставку изображения без искажений с задержкой end-to-end от 120 до 300 мс. 11 Поддерживает шифрование AES-128 и AES-256 «из коробки», а начиная с версии SRT 1.5 включает функцию connection bonding – распределение одного потока по нескольким сетевым каналам (например, оптика + сотовая связь) для обеспечения отказоустойчивости.

Основной кейс SRT – broadcast-контрибуция: репортёр на крыше стадиона, удалённая режиссёрская машина, подключённая по сотовой связи, ведущий корпоративного вебинара на ненадёжном Wi-Fi площадки. Схема всегда одна и та же: SRT доставляет поток от камеры или энкодера в облако, где медиасервер транскодирует его в HLS, DASH, LL-HLS и другие форматы, нужные аудитории. SRT не передаёт контент зрителям напрямую – так он не масштабируется, – но фактически заменил RTMP как профессиональный протокол ингеста по умолчанию.

RIST – альтернатива SRT уровня вещания

RIST – сокращение от Reliable Internet Stream Transport – открытый стандарт, призванный решить ту же задачу, что и SRT. Разработан Video Services Forum как вендорно-нейтральная альтернатива SRT и стандартизован в трёх профилях (Simple, Main, Advanced) в 2018–2021 годах. 12 Функционально он почти полностью соответствует SRT: использует UDP-транспорт, обеспечивает быстрый переспрос, поддерживает шифрование, низкую задержку и передачу в контрибуционном качестве.

Технические различия реальны, но незначительны. RIST в некоторых тестах выдерживает значительно большие потери – до 55 % стабильных потерь в лабораторных условиях против типичных 12 % у SRT – и поддерживает DTLS-аутентификацию по сертификатам, которой нет в SRT с его моделью предустановленных ключей (pre-shared key). 13 С другой стороны, у SRT более широкая база установок, лучшая поддержка программного обеспечения и проще операционная модель.

Прагматичное чтение 2026 года: SRT – стандартный выбор для prosumer- и broadcast-adjacent-контента; RIST – стандарт в tier-1-вещании, где аутентификация на основе DTLS-сертификатов и абсолютная устойчивость к потерям пакетов являются обязательными. В большинстве новых стриминговых продуктов используется SRT; в tier-1-вещании, управляемом network-operations-командами, – RIST. Оба протокола – open source, вендорно-нейтральны и активно развиваются в 2026 году.

RTMP – протокол, который не собирается умирать

RTMP – сокращение от Real-Time Messaging Protocol – был разработан компанией Macromedia для Adobe Flash в 2002 году и стандартизован в 2012 году после публикации спецификации Adobe. 14 Около десяти лет он оставался единственным практичным способом передачи видеопотока в реальном времени через публичный интернет, и на его основе была построена вся индустрия прямого эфирного вещания.

Затем в 2020 году Flash ушёл в историю, браузеры перестали поддерживать RTMP для воспроизведения, и плеерная роль протокола исчезла за одну ночь. Но каждый энкодер, каждая камера, каждая конфигурация OBS Studio, каждый рабочий процесс, каждый ингест-URL YouTube Live и каждый прямой эфирный URL Twitch по-прежнему использовали RTMP. Поэтому вместо исчезновения протокол перешёл в новую роль – стал универсальным ингест-протоколом, а экосистема научилась транскодировать RTMP-вход в HLS-выход на стороне сервера. Через шесть лет после «похорон» Flash большинство малых и средних продуктов для прямых трансляций в 2026 году по-прежнему работают на основе RTMP.

С возрастом RTMP лучше не стал. Он работает поверх TCP (а не UDP) – из-за этого потеря даже одного пакета замедляет поток до его повторной передачи; встроенного шифрования нет (можно использовать TLS – тогда получится RTMPS, но это ad hoc-обёртка); конечная задержка обычно составляет 2–5 секунд, что подходит почти для всего, кроме трансляций спортивных событий; современные кодеки он не поддерживает нативно (только H.264 с AAC; HEVC и AV1 требуют нестандартных расширений, отличающихся у каждого вендора). В 2026 году это устаревший протокол, удерживаемый инерцией существующих решений.

Путь миграции ясен: новые ингест-развёртывания принимают SRT или WHIP, а устаревший RTMP продолжает работать до замены парка энкодеров. К 2028–2029 году RTMP станет курьёзом. В 2026 году он всё ещё остаётся самым распространённым ингест-протоколом в открытом интернете.

MoQ – протокол, способный заменить половину этого списка

Media over QUIC, сокращённо MoQ – попытка рабочей группы IETF разработать единый протокол стриминга, способный заменить WebRTC, HLS и SRT. На начало 2026 года транспортный черновик (draft-ietf-moq-transport) находится в версии 17, его соавторами являются специалисты из Cisco, Google и Meta; черновик формата стриминга (draft-ietf-moq-msf) – в версии 00. 15

Тезис MoQ в том, что индустрия создала три класса протоколов (real-time, low-latency HTTP, сегментированный HTTP), потому что нас вынудил TCP. QUIC – современный транспорт на базе UDP, на котором построен HTTP/3, – снимает большую часть ограничений TCP: мультиплексирует множество потоков в одном соединении без head-of-line blocking, обрабатывает потерю пакетов без остановки всего соединения и проходит через любой firewall, пропускающий HTTP/3. На QUIC можно построить единый протокол, обеспечивающий субсекундную задержку, как у WebRTC, масштабируемый через CDN, как HLS, и устойчивый к плохим сетям, как SRT – не выбирая при этом лишь два из трёх.

Состояние MoQ в 2026 году – «реальный, но ранний». Cloudflare развернула глобальную сеть MoQ-реле в более чем 330 городах и открыла её для общего доступа. 16 OBS Studio, FFmpeg и несколько крупных стриминговых платформ поддерживают MoQ в экспериментальном режиме. nanocosmos представила коммерческую поддержку MoQ на IBC 2025. 17 Однако стандарт ещё не завершён, реализация поддержки в браузерах идёт по отдельности, а ни один крупный стриминговый сервис пока не перевёл основной трафик на MoQ как основной протокол.

Разумная ставка продуктовой команды 2026 года – не делать MoQ основным протоколом сегодня, но спроектировать пайплайн так, чтобы внедрение MoQ в 2028 году стало сменой упаковки, а не перестройкой. Если вы уже используете CMAF – половина дела уже сделана: MoQ наследует ту же chunk-структуру, что и CMAF.

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

Сравнение бок о бок

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

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

Реальный числовой пример: бюджетирование задержки live-события

Разберём пример, чтобы закрепить сравнение. Представьте: вы планируете стриминг концерта для 100 000 зрителей. Артист выступает на сцене в Берлине, аудитория – в гостиных по всей Европе. Цель – минимальная возможная задержка при минимальных затратах. Бюджет задержки распределяется следующим образом.

Камера на сцене снимает со скоростью 50 кадров в секунду, один кадр захватывается за 20 мс. Энкодер – аппаратный, кодирует в формате H.265 в режиме низкой задержки; его сквозная задержка в пайплайне составляет 100 мс.

Энкодер передаёт поток по волоконно-оптической линии через SRT на медиасервер в дата-центре Франкфурта. SRT-соединение настроено с окном повторной передачи 200 мс – этого достаточно для компенсации типичных сбоев в оптике. Сетевая задержка между Берлином и Франкфуртом составляет 12 мс; буфер SRT добавляет 200 мс; обработка в ингест-пайплайне сервера – 30 мс. Итого на данный момент: 12 + 200 + 30 = 242 мс.

Медиасервер транскодирует H.265-поток в лестницу CMAF-чанков на трёх уровнях: 1080p при 5 Мбит/с, 720p при 2,5 Мбит/с и 480p при 1 Мбит/с. Транскодер настроен на chunked CMAF с длительностью части 333 мс. Первый part нового сегмента становится доступен через 333 мс после начала сегмента плюс 50 мс задержки пайплайна. Итого: 333 + 50 = 383 мс – время готовности первого part. Следующий part появится ещё через 333 мс, то есть через 716 мс от начала сегмента.

Сервер публикует эти части как LL-HLS и LL-DASH. Узел CDN на границе сети (edge) загружает их с origin-сервера с типичным RTT 80 мс и кэширует на длительность сегмента. Загрузка плеером добавляет в среднем 100 мс, плюс safety-буфер плеера – 1 500 мс, что является минимальным запасом, который серьёзный продукт для трансляций спорта поддерживает в продакшене. Кумулятивный бюджет: 725 + 80 + 100 + 1 500 = 2 405 мс.

Реалистичная задержка glass-to-glass для этого события и данного стека в 2026 году составляет примерно 2,4 секунды. Это типичное развертывание LL-HLS, и оно укладывается в опубликованный диапазон – 2–8 с.

Если бизнес требует задержки менее секунды – например, во время концерта проходит real-time-аукцион – вы заменяете LL-HLS на WHEP для зрителей, участвующих в торгах, принимаете более высокую стоимость на одного зрителя и запускаете два потока: LL-HLS для 100 000 основных зрителей и WHEP для 1 000 участников аукциона. Это стандартная схема в продакшене 2026 года для любого события со смешанными требованиями к задержке.

CMAF – формат файла, объединяющий большую часть этого

Мы повторяем: «одни и те же файлы используются HLS и DASH» и «те же чанки становятся LL-HLS или LL-DASH». И это правда – CMAF, Common Media Application Format. Строго говоря, CMAF – не протокол, а формат-обёртка, но без него в 2026 году невозможно говорить о современных протоколах стриминга.

CMAF был утверждён в 2017 году отраслевым комитетом как стандарт ISO/IEC 23000-19 при участии Apple, Microsoft, Netflix, Akamai и других компаний. 4 Он определяет фрагментированную MP4-структуру – fMP4, описанную в нашей статье о контейнерах, – которую поддерживают как HLS-, так и DASH-плееры на основе одного и того же файла. До появления CMAF стриминговые сервисы вынуждены были кодировать и хранить два параллельных набора сегментов: один в формате MPEG-TS для HLS, другой – в fMP4 для DASH. С внедрением CMAF оба манифеста ссылаются на одни и те же файлы.

Когда CMAF используется совместно с chunked transfer encoding – то есть с делением сегментов на доли секунды – вы получаете режим низкой задержки как для HLS, так и для DASH с одного и того же потока кодирования. Поэтому к 2026 году каждый современный packager (AWS Elemental MediaPackage, Shaka Packager, Unified Streaming, Bitmovin Live) по умолчанию будет выпускать CMAF. 18 Переход на CMAF – это наиболее выгодное решение в стриминг-инфраструктуре: один энкодер, один уровень хранения, один origin-сервер, поддержка двух протоколов доставки и низкая задержка – всё это бесплатно.

Типичные ошибки

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

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

RTMP-ингест в эпоху LL-HLS. Типичная схема – инвестировать в доставку по LL-HLS (цель – задержка 3 секунды), но при этом продолжать использовать RTMP для ингеста, который сам по себе добавляет 3–5 секунд. В итоге конечная задержка определяется именно ингест-каналом, и все усилия по оптимизации доставки LL-HLS остаются незамеченными зрителем. Если доставка работает с низкой задержкой – и ингест должен быть таким же; переходите на SRT или WHIP в первую очередь.

Забывать про Safari. Примерно одна из пяти минут просмотра в открытом интернете приходится на Safari. Safari поддерживает HLS нативно, но не воспроизводит DASH без JavaScript-полифилла. Продукт, использующий только DASH – даже с полифиллом – сталкивается с более длительным временем загрузки, большим потреблением CPU и большим количеством обращений в поддержку на устройствах Apple. Всегда отдавайте HLS для Apple и DASH (на основе тех же CMAF-файлов) как дополнение для остальных платформ.

Считать MoQ готовым для продакшена. Это интересно и реально, но пока не стандартизировано. Ставьте roadmap на CMAF + LL-HLS + LL-DASH + WebRTC сегодня – возвращайтесь к MoQ в 2028 году.

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

Фора Софт выпускает видеопродукты на каждом протоколе из этого списка с 2005 года, и у команды есть шрамы, чтобы знать, когда каждый из них – правильный выбор. Наши решения для видеоконференций и телемедицины работают на WebRTC end-to-end с кастомным сигналингом и SFU-масштабированием. OTT- и прямые трансляции строятся по пайплайну CMAF + LL-HLS с контрибуцией через SRT или WHIP с IP-камер. Платформы видеонаблюдения комбинируют RTSP и WebRTC для субсекундного прямого эфира и HLS – для хранения архивов. Правильный выбор протокола редко бывает однозначным – это два-три протокола, каждый из которых лучше всех справляется со своей задачей, интегрированные программным обеспечением, отвечающим за failover, транскодирование и адаптивную доставку. Именно эту часть большинство готовых решений делает плохо, а мы проектируем её под реальные требования продукта.

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

• Восемь протоколов формируют основную часть стримингового трафика в 2026 году: HLS, DASH, LL-HLS, LL-DASH, WebRTC, WHIP/WHEP, SRT, RTMP. На горизонте – RIST и MoQ.
• Задержки различаются на два порядка – от 0,5 с (WebRTC) до 30 с (обычный HLS); реальное значение зависит от продукта, а не от протокола.
• Контрибуцию (камера → сервер) и доставку (сервер → зритель) всегда разделяйте. Большинство решений используют два протокола одновременно.
• CMAF + LL-HLS + LL-DASH на основе одного энкода – самый экономичный стек 2026 года для низколатентной доставки в массовом масштабе.
• SRT и WHIP фактически вытеснили RTMP в новых ингест-решениях; RTMP сохраняется только благодаря инерции устаревших энкодеров.
• MoQ существует, работает, но пока не готов к использованию в продакшене как основной протокол – проектируйте архитектуру так, чтобы MoQ можно было интегрировать в будущем.

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

• Контейнеры: MP4, fMP4, MKV, WebM, MOV, MPEG-TS – форматы файлов, в которых хранятся сегменты этих протоколов.
• WebRTC в глубину: SDP, ICE, STUN/TURN, SFU vs MCU – подробности работы единственного end-to-end-протокола реального времени.
• LL-HLS vs WebRTC vs CMAF: гид по низкой задержке – подробное сравнение трёх протоколов с задержкой менее секунды.