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

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

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

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

Самое обсуждаемое свойство протокола – glass-to-glass-задержка, время между событием перед камерой и его появлением на экране зрителя. Числа в этой статье – не выдумка, это типичные реальные задержки в 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. Apple объявила его на 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 платит за неё гораздо большим числом мелких HTTP-запросов; накладные растут обратно пропорционально размеру part. В продакшене LL-HLS добавляет 5–15 % к счёту CDN относительно обычного HLS при том же качестве картинки и примерно столько же на origin. Стоит ли это снижения задержки – зависит от задачи: очевидно стоит для live-спорта, почти никогда – для VOD.

LL-DASH – DASH с CMAF chunked transfer

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

Почему два ответа на одну и ту же задачу? Потому что индустрия рано раскололась на HLS и DASH и так и не сошлась обратно. Apple выпустила 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 подтверждает 2–4 секунды glass-to-glass в продакшене с этим стеком. 6

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

WebRTC – сокращение от Web Real-Time Communication – протокол, на котором стоят видеозвонки, видеоконференцсвязь и live-стриминг там, где любая задержка выше секунды недопустима. Стандартизован 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 % опрошенных broadcast-профессионалов – против 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 – broadcast-grade-альтернатива 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; в network-operations-team-led tier-1-вещании – RIST. Оба – open source, оба вендорно-нейтральны, оба живы и здоровы в 2026 году.

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

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

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

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

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

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

Media over QUIC, сокращённо MoQ – попытка рабочей группы IETF спроектировать один протокол стриминга, делающий работу WebRTC, HLS и SRT одновременно. Транспортный draft (draft-ietf-moq-transport) на начало 2026 года в версии 17, со-редакторы – из Cisco, Google и Meta; стриминг-формат draft (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 года, не лабораторный best case.

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

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

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

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

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

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

Сервер публикует эти parts как LL-HLS и LL-DASH. Edge-узлы CDN тянут их с origin с типичным RTT 80 мс и кэшируют на длительность сегмента. Скачивания плеером добавляют в среднем 100 мс, плюс safety-буфер плеера 1 500 мс – самый маленький запас, который серьёзный live-спорт-продукт держит в продакшене. Кумулятивный бюджет: 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» и «те же chunks становятся LL-HLS или LL-DASH». То, что это правда – CMAF, Common Media Application Format. Строго говоря, CMAF – не протокол, а формат-контейнер, но без него о протоколах стриминга в 2026 году говорить невозможно.

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

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

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

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

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

RTMP-ингест в эпоху LL-HLS. Частая схема – вкладываться в LL-HLS-доставку (целясь в 3-секундную задержку) и при этом продолжать использовать RTMP для ингеста (который сам по себе добавляет 3–5 секунд). End-to-end-задержка тогда определяется ингест-плечом, и инвестиции в 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- и live-стриминг-продукты идут по CMAF + LL-HLS-пайплайну с SRT- или WHIP-контрибуцией с венюшных камер. Наши платформы видеонаблюдения сочетают RTSP и WebRTC для субсекундного live-мониторинга с 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-real-time-протокола.
• LL-HLS vs WebRTC vs CMAF: гид по низкой задержке – глубокое погружение в три субсекундных протокола.