Push и pull, contribution и distribution: две стороны одного потока

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

Последняя сверка: 2026-05-20 со спецификациями RFC 9725 (WHIP, март 2025), draft-ietf-wish-whep-03 (WHEP, январь 2026), RFC 8216 (HLS, август 2017), Apple HLS Authoring Specification, ревизия 2025-09, ISO/IEC 23009-1:2022 (DASH), ISO/IEC 23000-19:2024 (CMAF), draft-sharabayko-srt-01 (SRT), SMPTE TR-06-1/2/3 (RIST), Adobe RTMP Specification 1.0 (2012) и draft-ietf-moq-transport-17 (Media over QUIC, январь 2026).

TL;DR

Любой видеопоток на пути от камеры до зрителя проходит через два принципиально разных этапа, и индустрия стриминга рассматривает их как две отдельные задачи, решаемые с помощью разных семейств протоколов. Первый этап – contribution или ингест – передаёт поток от одного источника через нестабильную публичную сеть в облако и использует push-протоколы: RTMP, SRT, RIST, WHIP. Второй этап – distribution или доставка – передаёт тот же поток из облака к тысячам или миллионам зрителей и опирается на pull-протоколы: HLS, DASH, CMAF, LL-HLS, WHEP, HESP, Media over QUIC. Push-методы оптимизированы под надёжность передачи по одному ненадёжному каналу с жёсткими требованиями к задержке, а pull-методы – под кэшируемость, поддержку в браузерах и масштабируемость. Поэтому практически любой реальный стриминговый workflow использует минимум два протокола – по одному для каждой стороны облака.

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

Стриминг кажется единой технологией, но на самом деле это две технологии, соединённые в облаке. Основатель, продакт-менеджер или инженер по эксплуатации, не замечающий этого соединения, будет ошибаться при каждом выборе протокола. Самая распространённая ошибка при проектировании – считать, что один протокол (обычно тот, что поставляется производителем кодера по умолчанию) решает обе задачи. На самом деле contribution и distribution выполняют разные функции – и тогда весь набор протоколов стриминга перестаёт выглядеть случайным: у каждого есть своя роль и причина находиться именно там. Прочитав статью, вы сможете посмотреть на любую архитектурную схему и сразу определить, какие протоколы отвечают за contribution-часть, какие – за distribution, и почему выбран именно такой дуэт.

Шов, который делит конвейер пополам

Камера в студии, на стадионе или в гостиной создаёт один поток. Зритель дома, на телефоне или у Smart TV потребляет этот же поток – вместе с сотнями, тысячами или миллионами других зрителей. Между этими двумя точками находится облако, и это облако – шов, разделяющий конвейер на две половины с принципиально разными требованиями.

На стороне contribution облако – пункт назначения. Соединение одно: от кодера на площадке до первого сервера в облаке, – и вся задача инженера сводится к поддержанию этого единственного соединения в сети, которой он не управляет. На стороне distribution облако – источник. Соединений миллионы – от облака до каждого устройства зрителя, – и вся задача инженера – масштабировать этот fan-out без роста расходов и задержек.

Эти две задачи толкают дизайн протоколов в противоположные стороны. Протокол, хорошо работающий на одном хрупком канале – с тяжёлыми буферами для ретрансмиссии, выделенными портами и кастомным контролем перегрузки, – будет плохо кэшироваться 600 edge-точками по всему миру. Протокол, отлично подходящий для кэширования – с короткими HTTP-сегментами, текстовыми манифестами и обычным TCP, – окажется неэффективным при восстановлении после 800 мс простоя 4G-хотспота. Поэтому индустрия разработала два семейства протоколов – по одному для каждой стороны этого разлома, – и стандартная архитектура любого нетривиального стримингового продукта использует по одному протоколу из каждого семейства в рамках одного workflow.

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

Что на самом деле означают «push» и «pull»

Слова «push» и «pull» описывают, кто инициирует соединение, по которому передаётся медиа. На слух это различие может показаться академическим – на деле же оно определяет почти все ключевые свойства протокола.

Push-протокол – это способ передачи данных, при котором источник (кодер на площадке) сам устанавливает соединение с облаком и отправляет пакеты по мере их готовности. Темп передачи задаёт кодер: как только пакет готов, он сразу отправляется в канал – без ожидания запроса от облака. RTMP, SRT, RIST и WHIP – все они являются push-протоколами. Кодер «отправляет» поток в сторону облака.

Pull-протокол – это когда потребитель (например, плеер зрителя) устанавливает соединение с сервером и поочерёдно запрашивает фрагменты контента. Темп передачи задаёт именно плеер. На сервере весь поток уже сохранён на диске или находится в кэше, и он отправляет только те фрагменты, которые плеер явно запросил. HLS, DASH, LL-HLS, LL-DASH, CMAF, WHEP, HESP, Media over QUIC – все эти протоколы являются pull-протоколами. Плеер «подтягивает» поток из облака.

Полезная аналогия: push-протокол – это курьерская доставка, которая привозит посылку от склада прямо к двери клиента, независимо от того, дома он или нет. Pull-протокол – это когда клиент сам приходит на склад и просит выдать посылку: ничего не отправляется со склада, пока клиент не обратится с запросом.

Из одного этого различия следуют два архитектурных вывода. Первый: push-протоколы нельзя кэшировать никому, кроме получателя – кэшировать нечего, потому что байты существуют только на проводе, пока их пушат. Pull-протоколы кэшируются тривиально: сегменты лежат на диске и ждут, когда любой плеер их попросит, и CDN может хранить копию каждого сегмента на каждом edge-POP. Второй: push-протоколы могут подстраиваться под живой источник – пушат ровно то, что произвёл кодер, в реальном времени. Pull-протоколам нужен буфер уже опубликованных сегментов, прежде чем плеер сможет стартовать, – отсюда и многосекундная задержка у HTTP-стриминга.

Вся промышленная терминология сосредоточена в этом разделе. «Contribution» и «ingest» – синонимы push-части конвейера. «Distribution», «delivery» и «egress» – синонимы pull-части. Когда документация Mux, Cloudflare или AWS упоминает «ingest endpoint», речь идёт о push-эндпоинте, принимающем RTMP, SRT или WHIP. А когда говорится о «delivery endpoint» или «playback URL», имеется в виду pull-эндпоинт, отдающий HLS, DASH или WHEP.

Семейство contribution: протоколы, которые «пушат»

Contribution-leg – самый рискованный участок конвейера, потому что сеть между площадкой и облаком почти всегда является самым плохо подготовленным каналом в цепочке. Один домашний uplink, 4G-хотспот, перегруженный Wi-Fi на стадионе, удалённый спутниковый канал – путь contribution состоит из одного кабеля, одной радиолинии, одного peering-линка, и любой из них может в любой момент деградировать или прерваться. Протокол, по которому передаётся закодированный поток по этому участку, должен обеспечивать защиту от джиттера, потерь пакетов и периодических обрывов канала – при допустимой задержке от сотен миллисекунд до нескольких секунд.

В 2026 году ландшафт вкладов формируют четыре протокола.

RTMP (Real-Time Messaging Protocol). Легаси-стандарт по умолчанию. Протокол был определён Adobe в конце 1990-х годов, работает поверх TCP, использует порт 1935 и входит в комплект любого кодера – от OBS Studio до профессионального оборудования уровня broadcast от Elemental. Adobe официально отказался от него много лет назад, а Adobe Flash прекратил существование в 2020 году, однако каждый кодер и каждый сервер приёма до сих пор поддерживают RTMP, потому что на нём говорит всё. Протокол работает, но имеет ряд недостатков, которые два следующих протокола призваны устранить: отсутствует полноценный контроль перегрузки сверх того, что обеспечивает TCP; нет нативной поддержки UDP; возникает блокировка из-за потери TCP-сегментов (head-of-line blocking); жёсткие ограничения на кодеки – формально поддерживаются только H.264 и AAC (производители добавили H.265 и AV1 через нестандартные расширения, но совместимость остаётся проблематичной). Полный разбор RTMP в 2026 году – в нашей статье про статус RTMP.

SRT (Secure Reliable Transport) – профессиональный стандарт для передачи данных в публичном интернете. Разработан компанией Haivision, открыт в 2017 году и сейчас проходит формальную стандартизацию в IETF как draft-sharabayko-srt-01 (на январь 2026 года – активный Internet-черновик, официальный RFC ожидается в ближайшее время). Протокол построен на базе UDP, поддерживает настраиваемое упредительное исправление ошибок (FEC) и конфигурируемый буфер ретрансмиссии (обычно 4× RTT), совместим с любыми кодеками и лучше проходит через файрволы, чем RTMP. Именно на SRT сегодня работают почти все broadcast-ремоуты.

SRT обеспечивает устойчивость к потерям пакетов в contribution-канале за счёт настраиваемого буфера задержки – типичные значения составляют от 1 до 4 секунд. Полный перечень параметров и настроек доступен в подробном описании SRT.

RIST (Reliable Internet Stream Transport) – альтернативный SRT протокол для вещания, стандартизированный SMPTE в трёх технических рекомендациях: TR-06-1 (2020), TR-06-2 (2022), TR-06-3 (2024). У RIST три профиля – Simple, Main, Advanced – с постепенно расширяющимся набором функций: шифрование, аутентификация, мультиплексирование, GRE-туннелирование. RIST выбирают, когда вещателю нужна интероперабельность с существующей студийной инфраструктурой на уровне SMPTE-стандарта. Подробнее – в RIST: альтернатива broadcast-уровня.

WHIP (WebRTC-HTTP Ingestion Protocol). Современный стандарт. IETF RFC 9725, опубликован в марте 2025 года. WHIP – это тонкий HTTP-слой сигнализации поверх WebRTC для ингеста: POST от кодера с SDP-offer, ответ 201 Created с SDP-answer, после чего кодер передаёт RTP/SRTP-медиа напрямую в согласованное WebRTC-подключение. Задержка end-to-end составляет менее секунды, обеспечивается нативный обход файрволов через ICE/STUN/TURN, поддерживается H.264, H.265, VP8, VP9 и AV1 – и реализована во всех современных кодерах, начиная с OBS 30. WHIP – стандарт по умолчанию для любого нового конвейера в 2026 году, если нет веской причины его не использовать. См. WHIP – WebRTC-ингест (RFC 9725).

Картину дополняют две нишевые стандартные технологии. Zixi – проприетарная broadcast-grade альтернатива, объединяющая транспорт и управление контентом, лицензируется поштучно. NDI (Network Device Interface) и SMPTE ST 2110 применяются внутри студии: NDI – для передачи IP-видео по контролируемому гигабитному LAN; ST 2110 – для жёстко тактированного студийного IP-транспорта, который в большинстве современных broadcast-объектов уже заменил SDI. Ни одна из этих технологий не выходит за пределы здания. См. Zixi, NDI, ST 2110.

Что общего у всех contribution-протоколов: один источник, одно соединение, инициатива отправителя. Технические решения различаются – TCP против UDP, набор кодеков, управление перегрузкой, глубина буфера – но их роль в конвейере одна. Все они отвечают на один и тот же вопрос: как передать один хрупкий поток через ненадёжную сеть в облако, потеряв не больше, чем допустимо для конкретного use case?

Семейство distribution: протоколы, которые «пуллят»

Distribution-leg – обратная задача. Поток уже находится в облаке. У облака – фактически бесконечное хранилище, предсказуемая пропускная способность и CDN с сотнями edge-POP, готовых отдавать кэшированные копии. Проблема не в надёжности передачи по враждебному каналу, а в fan-out: как раздать один и тот же поток миллиону зрителей, не перегружая облако и не отправляя миллиард избыточных байт по интернету.

Протоколы, решающие эту задачу, обладают двумя ключевыми чертами. Во-первых, все они работают поверх HTTP (или, в случае WebRTC-egress, поверх соединения WebRTC peer connection, которое масштабируется гораздо проще, чем конференц-сервер, для которого его изначально проектировали). Во-вторых, все они разбивают поток на небольшие самодостаточные фрагменты – сегменты, чанки, части, кадры, – которые можно независимо кэшировать, передавать и отбрасывать. Обе эти особенности направлены на то, чтобы сделать поток максимально похожим на обычный веб-трафик, поскольку именно с таким трафиком интернет научился эффективно работать в масштабах за последние тридцать лет.

Ландшафт дистрибуции в 2026 году:

HLS (HTTP Live Streaming) – доминирующий протокол потоковой передачи. Разработан Apple в 2009 году, стандартизован как RFC 8216 в 2017 году и сейчас обновляется в рамках draft-pantos-hls-rfc8216bis в IETF. HLS публикует текстовый манифест (.m3u8), в котором перечислены медиа-сегменты (.ts или .m4s, продолжительностью 2–6 секунд каждый); плеер сначала загружает манифест, а затем последовательно скачивает каждый сегмент по HTTPS. Протокол отлично кэшируется, работает во всех браузерах, нативно поддерживается на iOS, в Safari и на любом Smart TV. Наш подробный разбор HLS охватывает всю спецификацию.

LL-HLS (Low-Latency HLS). Расширение Apple для протокола HLS, обеспечивающее задержку менее 5 секунд. Определено в спецификации Apple HLS Authoring Specification (актуальная ревизия – 2025-09 на момент написания). LL-HLS разбивает каждый сегмент на 200-миллисекундные «части», которые плеер может загружать сразу по мере их появления; снижает буфер плеера с трёх сегментов до примерно 1,5 и использует HTTP/2 с блокирующими запросами к плейлистам, чтобы плеер узнавал о новых частях в момент их публикации. Подробности – в LL-HLS подробно.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) – альтернатива HLS от ISO/IEC, определённая в стандарте ISO/IEC 23009-1:2022. DASH использует XML-манифест Media Presentation Description (.mpd), а по структуре напоминает HLS: сегменты передаются по HTTP, адаптивное битрейт-управление (ABR) реализуется на стороне плеера. DASH доминирует в OTT-экосистемах на Android, Smart TV и в любых рабочих процессах, где гибкость DRM (PlayReady, Widevine) важнее нативной поддержки iOS. Подробное описание модели манифеста – в DASH подробно.

LL-DASH (Low-Latency DASH) и CMAF chunked encoding. Ответ DASH-IF на LL-HLS. Используются CMAF (ISO/IEC 23000-19:2024) чанки длительностью 100–500 мс внутри 2-секундных сегментов, передаваемые через HTTP/1.1 с использованием chunked transfer encoding, чтобы плеер получал чанки сразу по мере их создания. Целевая задержка – 2–5 секунд glass-to-glass. Подробнее – в LL-DASH и low-latency CMAF.

CMAF (Common Media Application Format). Строго говоря, CMAF – это формат упаковки, а не протокол доставки: фрагментированный MP4 (fMP4) контейнер, определённый в стандарте ISO/IEC 23000-19, благодаря которому один и тот же физический сегмент может использоваться как в HLS, так и в DASH. Именно CMAF делает возможной единую историю с низкой задержкой. Подробный разбор брендов и профилей – в CMAF подробно.

WHEP (WebRTC-HTTP Egress Protocol). Egress-альтернатива WHIP, на январь 2026 – draft-ietf-wish-whep-03. WHEP предоставляет плееру HTTP-эндпоинт, на который плеер отправляет SDP-offer; сервер отвечает SDP-answer и транслирует медиа в WebRTC-подключение, которое потребляет плеер. Задержка составляет менее 500 мс для небольшой и средней аудитории, при этом WebRTC масштабируется иначе, чем HTTP – подробности архитектуры см. в WebRTC-доставка в масштабе.

HESP (High-Efficiency Streaming Protocol). 400-миллисекундная доставка на основе HTTP от THEO Technologies, сейчас draft-theo-hesp-04. Поток делится на continuation playlist и initialisation playlist, что позволяет мгновенно подключаться из любой точки без ожидания границы сегмента. Ниша, но интересна – см. HESP объяснён.

Media over QUIC (MoQ). Самый свежий участник – сейчас draft-ietf-moq-transport-17 (январь 2026, подлежит правкам до публикации как RFC). MoQ – это модель publish/subscribe поверх QUIC, сочетающая низкую задержку и удобство кэширования в одном протоколе и тем самым преодолевающая традиционное разделение между push и pull. MoQ Transport определяет формат передачи данных; параллельные драфты задают прикладные профили для стриминга, конференцсвязи и чата. Это одна из главных ставок второй половины десятилетия. Подробный разбор – в Media over QUIC.

Общий паттерн всего семейства distribution: один источник в облаке, множество зрителей, инициатива на стороне потребителя (pull). Каждый протокол из этого семейства спроектирован под одно ключевое ограничение – CDN должна уметь кэшировать и реплицировать байты, не понимая их смысла, – и протоколы конкурируют между собой по тому, насколько эффективно они скрывают плату за это ограничение в виде задержки.

Пары: какой протокол вклада с каким протоколом распределения

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

Пять типичных пар в 2026 году:

Стоит отдельно выделить два паттерна. Первый – самая агрессивная low-latency-пара (WHIP → WHEP) полностью отказывается от HTTP-кэш-иерархии. Вся суть CDN – один запрос к origin на регион, обслуживающий тысячи попаданий в edge-кэш, – теряется, когда каждый зритель поддерживает открытое WebRTC-соединение. Масштабирование WHEP за пределы нескольких сотен зрителей на поток требует mesh из SFU (selective forwarding unit), каскадирующих соединения, – а это уже принципиально иная архитектура, не CDN. См. WebRTC при масштабировании.

Второй – гибридные стеки нормальны, а не исключение. Типичный крупный OTT-продукт принимает RTMP от партнёров с устаревшей инфраструктурой, SRT – от премиальных вещательных партнёров и WHIP – от всех, кто подключается в 2026 году; на стороне дистрибуции тот же продукт публикует HLS для Apple и Smart TV, DASH – для Android и рынков с поддержкой PlayReady-DRM, а всё чаще – LL-HLS или LL-DASH для latency-чувствительной части каталога. Внутри облака транскодер генерирует один набор CMAF-медиафайлов, который используется и для HLS-, и для DASH-манифестов – поэтому стоимость хранения оплачивается всего один раз. Подробности архитектуры см. в Гибридные стеки протоколов.

Математика: почему contribution-канал требует большего запаса

Конкретное число, которое стоит держать в голове: на contribution-канале закладывайте минимум 1,5× битрейта верхнего рендера как устойчивую полосу uplink.

Для потока 1080p, закодированного со скоростью 5 Мбит/с, это:

• 5 Mbps × 1,5 = 7,5 Mbps устойчивого uplink.
• Из них около 0,5 Mbps расходуется на накладные расходы протоколов (заголовки, ACK, FEC).
• Примерно 1,0 Mbps уходит на компенсацию периодических пиков keyframe при GOP 2 секунды – keyframe в 5–10 раз больше среднего P-кадра, поэтому средние 5 Mbps превращаются в пики 10–25 Mbps каждые 2 секунды.
• Примерно 1,0 Mbps уходит на ретрансмиссию и FEC при использовании SRT или WHIP на реальном loss-prone канале.

Тот же 5-мегабитный поток на стороне дистрибуции, напротив, почти не требует запаса на стороне origin – CDN гасит пиковые нагрузки, а каждый зритель получает ровно столько, сколько позволяет его последний участок сети. Запас на стороне дистрибуции оплачивается единожды на CDN-краю и распределяется между всеми зрителями.

Эта асимметрия – самый ценный инсайт при запуске нового стримингового продукта. Contribution – это один источник, трафик идёт по узкой и хрупкой линии uplink, объём рассчитывается под худшую минуту вещания. Distribution – это агрегированный исходящий трафик, тарифицируется по терабайтам через CDN, объём подстраивается под худший день. Смешивать эти два бюджета – значит ломать модели ценообразования.

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

Как две стороны на самом деле соединяются внутри облака

Облако – не магия, а шов между contribution и distribution – это конкретный кластер серверов (обычно называемый «транскодером» или «медиапроцессором»), который принимает contribution-поток, преобразует его в формат, пригодный для distribution, и отправляет в origin. Пять задач, выполняемых на этом шве:

Первая – демуксинг contribution-потока. Если кодер отправляет RTMP с H.264 + AAC, транскодер распаковывает RTMP-контейнер, извлекает элементарные потоки видео и аудио и передаёт их дальше. Если кодер отправляет WHIP, WHIP-сервер завершает WebRTC-соединение, извлекает RTP-пакеты и восстанавливает исходные кадры.

Вторая – транскодирование в битрейт-лестницу. Один contribution-канал на 5 Мбит/с превращается в лестницу из пяти рендеров – 1080p, 720p, 480p, 360p, 240p – с постепенно снижающимися битрейтами. Каждый рендер кодируется транскодером в реальном времени – на GPU или специализированной ASIC. Именно форма этой лестницы обеспечивает работу ABR-стриминга на стороне дистрибуции. Подробности проектирования лестницы – в Построение битрейт-лестницы.

Третья – упаковка. Транскодированные рендеры оборачиваются в CMAF-сегменты (ISO/IEC 23000-19), обычно продолжительностью 2–6 секунд, с внутренними чанками по 200 миллисекунд – это необходимо для профилей с низкой задержкой. Манифест – .m3u8 для HLS, .mpd для DASH – содержит перечень сегментов и рендеров. Благодаря CMAF один и тот же набор медиафайлов может обслуживать как HLS-, так и DASH-плееры. Подробности – в CMAF: формат упаковки, объединивший HLS и DASH.

Четвёртая – публикация в origin. Упакованный манифест и сегменты размещаются на HTTP-оригинальном сервере (обычно AWS S3, Google Cloud Storage или self-hosted Nginx), который поддерживает скользящее окно живого потока и отдаёт манифест и сегменты по любому запросу.

Пятая – распространение по CDN. Слой origin-щит на CDN загружает манифест и сегменты с origin; mid-tier-кэши в каждом регионе получают их с shield; edge-POP в каждом городе подтягивают данные с mid-tier. К моменту, когда первый зритель в регионе запрашивает воспроизведение, сегменты уже находятся на ближайшем edge и готовы к отдаче. Кэш-иерархия описана в Origin shielding и многоуровневое кэширование.

Все пять задач выполняются непрерывно, в реальном времени, с end-to-end задержкой от момента, когда кодер сгенерировал кадр, до момента, когда сегмент первого зрителя закэширован на edge, – от одной до десяти секунд, в зависимости от конфигурации. Граница между push и pull концептуально чёткая – здесь заканчиваются push-протоколы и начинаются pull-протоколы, – однако реализация остаётся самой сложной операционной частью стримингового продукта.

Почему Media over QUIC важен: протокол, который сшивает шов

Самый чистый сигнал того, что индустрия воспринимает разделение push/pull как артефакт 2010-х, а не как вечный закон стриминга, – это явный курс на создание протокола, который одинаково хорошо справляется и с тем, и с другим. Media over QUIC (MoQ) – именно такой протокол.

MoQ Transport (draft-ietf-moq-transport-17, январь 2026) определяет модель publish/subscribe поверх QUIC. Издатель – кодер на площадке или релэй в облаке – анонсирует именованные треки медиаобъектов. Подписчик – релэй или плеер – подписывается на трек и получает объекты по мере их публикации с надёжностью на уровне потока QUIC и без блокировки из-за head-of-line. Модель представляет собой push с точки зрения издателя и pull с точки зрения подписчика, при этом релэи между ними могут кэшировать объекты, устранять дублирование подписок и обеспечивать распределение fan-out на большое число подписчиков.

Что это даёт стриминговым продуктам: задержку передачи контента (менее секунды, сопоставимую с WHIP) и масштабируемое распределение (кеширование на каждом реле, без нагрузки на CPU для каждого зрителя в облаке). Первые коммерческие внедрения начались в 2025 году; рабочая группа IETF MoQ продолжает дорабатывать черновик транспортного протокола и несколько прикладных профилей. К концу десятилетия MoQ становится наиболее реалистичным кандидатом на замену комбинации HLS/DASH и WHIP/WHEP единым протоколом, способным решить обе задачи.

Это пока что работа в перспективе, а не стандарт по умолчанию – draft-ietf-moq-transport-17 подлежит доработке до публикации в виде RFC, а развернутые реализации (например, MoQ proof of concept от Meta и демо от Cloudflare для Twitch) находятся на ранней стадии. Подробный разбор того, что уже стандартизировано, что находится в разработке и на что стоит обратить внимание, – в Media over QUIC подробно.

Типичные ошибки и подводные камни

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

Первая – один протокол на обе стороны. Классический пример: команда выбирает RTMP, потому что кодер его поддерживает, и передаёт RTMP до плеера через какой-то кастомный WebSocket-мост, после чего обнаруживает, что у неё нет кэш-иерархии, и платит за CDN-уровень egress за то, что могло бы быть набором CDN-сегментов. Аналогично – команда, выбравшая WebRTC end-to-end для OTT-стриминга в реальном времени, платит за SFU-вычисления для каждого зрителя, тогда как HLS-конвейер обошёлся бы только CDN-egress.

Вторая – несовместимые кодеки. RTMP формально поддерживает только H.264 и AAC; если сторона дистрибуции использует HEVC или AV1 ради экономии полосы пропускания, стороне контрибуции придётся либо перекодировать поток, либо передавать его другим протоколом ингеста. WHIP и SRT поддерживают современные кодеки – это один из практических аргументов в пользу перехода от RTMP в новых проектах.

Третья – сайзинг contribution-канала по средней полосе. У contribution-стороны есть проблема пиков против среднего из-за keyframe’ов, которой нет у distribution: каждый keyframe в 5–10 раз больше среднего P-кадра. Поток 5 Mbps выдаёт на выходе кодера пики по 25 Mbps каждые 2 секунды. Contribution-канал нужно сайзить под пик, а не под среднее.

Четвёртая – уверенность, что CDN решает всё. CDN находится между origin и зрителем на стороне распространения; на стороне приёма она ничего не делает. Проблему задержки на стороне приёма нельзя решить увеличением ёмкости CDN. Сначала правильно определите, на какой стороне проблемы лежит корень.

Пятая – забыть, что гибрид – это норма. Большинство нетривиальных стриминговых продуктов используют несколько contribution-протоколов (RTMP для легаси-партнёров, SRT или WHIP для новых) и несколько distribution-протоколов (HLS для Apple, DASH для Android и DRM, LL-HLS для премиум-стримов). Проектировать систему под один протокол на сторону, а потом «доклеивать» второй – неправильный подход.

Где применяется Фора Софт

Мы строим contribution- и distribution-стеки с 2005 года – в видеоконференциях, OTT и Internet TV, телемедицине, e-learning, видеонаблюдении и AR/VR. Типичный проект Фора Софт охватывает обе стороны: WHIP- или SRT-ингест от клиентского кодера в облачный кластер, собранный нами, и distribution-слой с упаковкой CMAF, обеспечивающий работу HLS- и DASH-плееров на браузерах, iOS, Android и Smart TV. Разделение между contribution и distribution – первое архитектурное решение, которое мы рисуем на доске при разработке нового стримингового продукта, потому что все последующие решения – выбор кодека, масштабирование CDN, бюджет задержки, матрица плееров – вырастают из правильно сделанного этого разделения.

Главное

• В любом стриминговом конвейере есть два этапа – приём контента (contribution) и его распространение (distribution), которые сходятся в облаке.
• Протоколы приёмной стороны передают один поток через ненадёжную сеть: RTMP, SRT, RIST, WHIP.
• Протоколы дистрибуции извлекают множество копий из кэшированного хранилища: HLS, DASH, LL-HLS, WHEP, HESP, MoQ.
• Приёмная часть оптимизируется под надёжность, а дистрибуция – под кэшируемость и масштабируемость.
• Гибридные стеки – один протокол на сторону, иногда больше – являются нормой в продакшене, а не исключением.
• Media over QUIC – первая реальная попытка объединить обе задачи в одном протоколе.

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

• Что такое ингест и почему это самый рискованный участок конвейера – contribution-столп на один уровень глубже этой статьи.
• Семейное древо delivery-протоколов – distribution-столп, все протоколы на одной странице.
• Конвейер стриминга от начала до конца – девятиэтапная карта, которую эта статья делит пополам.