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-leg, какие – distribution-leg и почему workflow выбрал именно такую пару.

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

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

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

Эти две задачи тянут дизайн протоколов в противоположные стороны. Протокол, который хорошо держит один хрупкий канал – тяжёлые буферы для ретрансмиссии, выделенные порты, кастомное congestion control, – будет ужасно кэшироваться 600 edge-точками по всему миру. Протокол, который отлично кэшируется – короткие HTTP-сегменты, plain-text манифесты, обычный 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 году contribution-ландшафтом владеют четыре протокола.

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

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

RIST (Reliable Internet Stream Transport). Broadcast-альтернатива SRT, определена SMPTE в трёх Technical Recommendations: 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 peer connection. Sub-секундная задержка end-to-end, нативный обход файрволов через ICE/STUN/TURN, поддержка H.264, H.265, VP8, VP9 и AV1 – и поставка в каждом современном кодере начиная с OBS 30. Дефолт для любого нового конвейера в 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-протоколов: один источник, одно соединение, push-инициатива. Технические решения отличаются – TCP против UDP, набор кодеков, congestion control, глубина буфера, – но роль в конвейере одна. Все они отвечают на один и тот же вопрос: как перенести один хрупкий поток через одну плохую сеть в облако, теряя не больше, чем приемлемо для конкретного use case?

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

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

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

Distribution-ландшафт 2026 года:

HLS (HTTP Live Streaming). Доминирующий протокол. Создан в Apple в 2009, стандартизован как RFC 8216 в 2017, сейчас обновляется как draft-pantos-hls-rfc8216bis в IETF. HLS публикует plain-text манифест (.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-миллисекундные «parts», которые плеер может скачивать сразу же по мере их появления; снижает буфер плеера с 3 сегментов до примерно 1.5 и использует HTTP/2 blocking playlist requests, чтобы плеер узнавал о новых parts в момент их публикации. Полная механика – в LL-HLS подробно.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP). ISO/IEC-альтернатива HLS, определена в ISO/IEC 23009-1:2022. DASH публикует XML-манифест Media Presentation Description (.mpd), в остальном структурно близок к HLS: сегменты по HTTP, ABR на стороне плеера. DASH доминирует в OTT на Android, Smart TV и в любом workflow, где гибкость 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 – то, что делает возможным единую low-latency историю. Подробный разбор брендов и профилей – в CMAF подробно.

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

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

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

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

Пары: какой contribution-протокол с каким distribution-протоколом

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

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

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

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

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

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

Для потока 1080p, закодированного при 5 Mbps, это:

• 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-мегабитный поток на стороне distribution, наоборот, почти не требует запаса в origin – CDN поглощает burst-ность, а каждый зритель берёт ровно столько, сколько выдерживает его last-mile. Запас на distribution-стороне платится единожды на CDN-edge и амортизируется по всем зрителям.

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

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

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

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

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

Вторая – транскодирование в битрейт-лестницу. Один contribution-feed на 5 Mbps превращается в лестницу из пяти рендишенов – 1080p, 720p, 480p, 360p, 240p – с прогрессивно более низкими битрейтами. Каждый рендишен кодируется транскодером в реальном времени, на GPU или специализированной ASIC. Форма лестницы – то, что делает ABR-стриминг рабочим на стороне distribution. Дизайн лестницы – в Построение битрейт-лестницы.

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

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

Пятая – распространение по CDN. Слой origin-shield на 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. Издатель – кодер на площадке или релэй внутри облака – анонсирует именованные треки медиа-объектов. Подписчик – релэй или плеер – подписывается на трек и получает объекты по мере их публикации, с per-stream надёжностью QUIC и без head-of-line blocking. Модель – push с точки зрения издателя и pull с точки зрения подписчика, с релэями посередине, которые могут кэшировать объекты, дедуплицировать подписки и распределять fan-out по большому числу подписчиков.

Что это даёт стриминговым продуктам: contribution-задержку (sub-секунда, сравнимая с WHIP) и distribution-fan-out (кэши на каждом релэе, без per-viewer-CPU в облаке). Первые коммерческие развёртывания пошли в 2025-м; IETF MoQ working group итерирует драфт транспорта и несколько application-профилей. К концу десятилетия MoQ – самый правдоподобный кандидат на замену связки HLS/DASH плюс WHIP/WHEP единым протоколом, который закрывает обе задачи.

Это пока ещё forward-looking работа, не production-default – 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-live-аудитории, платит SFU-compute за каждого зрителя, тогда как HLS-конвейер платил бы только CDN-egress.

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

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

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

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

Где встраивается Фора Софт

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

Главное

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

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

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