SRT: профессиональный стандарт ingest по публичному интернету

Последняя сверка: 2026-05-20 со спецификацией IETF Internet-Draft draft-sharabayko-srt-01 (истёк в марте 2022 года, остаётся наиболее полным публичным документом), исходными кодами и документацией референсной реализации Haivision SRT v1.5.4 на GitHub, руководством по развертыванию SRT Alliance v1.1, публичным списком членов SRT Alliance, а также с текущим статусом поддержки SRT в OBS Studio 32, FFmpeg 7, GStreamer 1.24, VLC 3.0, AWS Elemental MediaConnect, Cloudflare Stream, Dolby Millicast и Mux Live.

TL;DR

Secure Reliable Transport, сокращённо SRT, – это UDP-протокол контрибьюции, который профессиональная вещательная индустрия приняла в период с 2017 по 2024 год для доставки live-видео по публичному интернету с задержкой менее секунды и надёжностью уровня broadcast. Компания Haivision разработала протокол, представила его как open source на NAB 2017 и теперь распространяет его более чем 700 организациям через SRT Alliance – включая Microsoft, NVIDIA, Cloudflare, Paramount, Dolby, Mux, Wowza, EVS и десятки производителей энкодеров. В отличие от RTMP, работающего поверх TCP и теряющего стабильность при потерях пакетов, SRT использует UDP с селективной ретрансмиссией в пределах настраиваемого окна задержки: 3-процентный всплеск потерь вызывает лишь глитч в один кадр, но не разрывает поток. К 2026 году SRT станет протоколом по умолчанию для любой контрибьюции через открытый интернет без выделенной линии, стандартом удалённого продакшена и передачи live-новостей, а также оптимальным решением там, где TCP-поведение RTMP срывается из-за джиттера, потерь или проблем на «последней миле».

Зачем это понимать

Если вы транслируете live-видео с площадки, стадиона, удалённой съёмочной группы, репортажного аппарата или мобильного энкодера, главный операционный риск – это контрибьюшен-путь: участок между энкодером и первым сервером, который вы контролируете. Именно здесь джиттер, потери пакетов и перегрузка публичного интернета разрушают поток, а именно здесь RTMP – стандарт последних двух десятилетий – действительно даёт сбой в реальных условиях. Протокол SRT появился, потому что Haivision нуждался в решении для контрибьюции, способном выдерживать 5-процентный всплеск потерь в Wi-Fi на площадке без разрыва соединения, а остальная индустрия быстро приняла его, поскольку это же решение оказалось эффективным для репортажей, объединения сотовых модемов и передачи данных между облаками.

Эта статья – канонический справочник по блоку 3 протокола SRT: что он собой представляет, какую проблему решает там, где RTMP не справляется, откуда берётся правило «4× round-trip time» для задержки, как работают режимы caller / listener / rendezvous, во что обходится AES-256 шифрование, где в этой картине находится SRTLA – вариант с бондингом нескольких каналов – и как SRT соотносится с RIST и WHIP в контексте решений 2026 года. К концу статьи вы сможете уверенно отстаивать выбор «мы используем SRT» на планёрке и настроить энкодер без догадок.

Что такое SRT – одной страницей

SRT (Secure Reliable Transport) – прикладной протокол поверх UDP, обеспечивающий приложению три ключевых свойства, которых нет у стандартного UDP: надёжную доставку, шифрование и жёсткую верхнюю границу задержки end-to-end. Компания Haivision разработала первоначальную реализацию в период с 2013 по 2017 год как транспортный компонент для своей линейки энкодеров и декодеров KB и в 2017 году на выставке NAB опубликовала как сам протокол, так и его референсную реализацию в открытом доступе. Максим Шарабайко и небольшая группа соавторов представили спецификацию в IETF в виде черновика draft-sharabayko-srt (версии 00 и 01, 2020–2022 гг.). Эти черновики с тех пор утратили силу, поэтому сегодня в качестве основного источника выступает совокупность последнего устаревшего черновика IETF, референсной реализации Haivision на GitHub (текущая версия v1.5.4) и Deployment Guide от SRT Alliance.

Механически SRT работает поверх UDP и использует любой порт, который задаёт оператор – чаще всего это порт 9000, но, в отличие от RTMP, где порт 1935 является стандартным, в SRT ни один порт не считается каноническим. Сессия начинается с рукопожатия (handshake) между caller и listener (или между двумя caller в режиме rendezvous), опционального обмена ключами при включённом шифровании и фазы установления потока, в ходе которой стороны согласовывают бюджет задержки, пропускную способность канала и режим работы. Далее плоскость данных передаёт видео, аудио и метаданные в виде последовательности пронумерованных UDP-датаграмм. Если получатель обнаруживает пропуск в нумерации, он отправляет negative acknowledgement (сокращённо NAK), запрашивая повторную передачу именно этого пакета. Если ретрансляция успевает попасть в заранее согласованное окно задержки, получатель вставляет пакет на своё место и передаёт собранный поток приложению; если нет – он фиксирует пропуск и продолжает работу.

Протокол поддерживает три режима – live, file-buffer и file-message – которые различаются жёсткостью контракта по задержке и тем, что протокол гарантирует на границах пакетов. Режим live используется почти повсеместно в видео: один фрагмент полезной нагрузки на пакет, строгий лимит задержки и чёткий контракт «опоздавшие пакеты отбрасываются, а не блокируют поток». File-режимы предназначены для передачи конечного блока байтов по ненадёжной сети, когда точность важнее своевременности. Если вы не реализуете передачу файлов поверх SRT, можно считать «SRT» и «SRT live mode» синонимами.

Формат передачи данных – бинарный, разрешение тайминга – в микросекундах. Протокол включает прикладные временные метки end-to-end, чтобы приёмник мог восстановить ритм отправителя. SRT поддерживает опциональное шифрование полезной нагрузки с использованием AES-128 или AES-256 в режиме CTR – по общей фразе-паролю или предварительно распределённому ключу. Это вся архитектура в 200 словах.

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

Краткая история появления SRT

История важна, потому что объясняет, под что оптимизирован SRT. Haivision – канадская компания, которая с начала 2000-х разрабатывает broadcast-уровня оборудование для контрибьюции: семейства энкодеров и декодеров KB и Makito, устанавливаемые в стойки репортажных машин, спортивных команд и новостных служб. Около 2012 года компания столкнулась с проблемой: каждый заказчик хотел передавать эфир в реальном времени через публичный интернет (дешевле выделенной оптики, быстрее в развёртывании, чем спутник), но существующие протоколы не справлялись с реальными полевыми условиями. RTMP падал при 2% потерь. Голый UDP без ретрансмиссии вызывал заметные артефакты. RTP через приватный VPN работал – но только в контролируемой сети. Инженеры Haivision, включая Максима Шарабайко, основного автора протокола, разработали новый транспортный протокол, объединив поведение UDP «пропустить опоздавшее» с селективной ретрансмиссией и жёстким ограничением задержки, и внедрили его как транспорт по умолчанию в KB.

К 2017 году у Haivision накопилось достаточно доказательств эффективности – NFL использовала SRT для передачи фидов с площадок, новостные службы применяли его для удалённой контрибьюции – чтобы сделать стратегический шаг: открыть протокол, передать его индустрии и превратить из функции, доступной только в аппаратных решениях, в стандарт, который может реализовать любой. На NAB 2017 компания опубликовала спецификацию протокола и реализацию на C под лицензией Mozilla Public License 2.0, создала SRT Alliance с Wowza в качестве первого сооснователя и пригласила индустрию присоединиться. Microsoft присоединился в 2018 году, AWS Elemental – в 2019-м, NVIDIA – в 2023-м, а Cloudflare, Paramount, Dolby, Mux, JW Player, THEO Technologies, EVS и Chyron – в период с 2023 по 2025 год. В 2024 году число участников SRT Alliance превысило 600, а в 2025-м – 700, сделав его крупнейшим альянсом по открытому протоколу в индустрии стриминга.

Отчёт Haivision Broadcast Transformation Report 2024 – ежегодное исследование использования протоколов контрибьюции в производственном вещании – показал, что 68 процентов вещателей теперь применяют SRT для передачи live-видео. Это самый распространённый современный протокол контрибьюции в индустрии вещания, опережающий RTMP, RIST и Zixi. Что касается платформ для разработчиков (AWS Elemental MediaConnect, Cloudflare Stream, Dolby Millicast, Mux Live), то здесь поддержка SRT-ingest близка к 100 процентам: он универсален и часто используется параллельно с RTMPS и WHIP на одной точке приёма.

Удобный способ держать это в голове: SRT не родился в комитете по стандартам. Он появился как живой продукт, оказался настолько хорош, что вытеснил RTMP для профессиональной передачи контента, и лишь потом был передан индустрии как open source. Порядок «сначала запустили, потом стандартизировали» объясняет, почему SRT работает в реальных условиях и почему документация протокола частично содержится в устаревшем IETF-драфте, а частично – в референсной реализации на GitHub.

Единственная проблема, которую решает SRT, но не решает RTMP

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

Чтобы понять, почему это сложно, нужно разобраться, что потери делают с RTMP. RTMP работает поверх TCP, который гарантирует приложению три вещи: каждый байт дойдёт, каждый байт придёт в том порядке, в котором был отправлен, и отправитель замедляется, если сеть перегружена. Эти гарантии отлично подходят для веб-страниц и скачивания файлов. Однако для прямого видео они становятся катастрофой, потому что «доставка в порядке» означает: если пакет 47 потерян в сети, пакеты 48, 49, 50 и все последующие остаются в буфере ядра приёмника, ожидая, пока пакет 47 будет повторно передан. Ожидание длится минимум один round-trip time – обычно от 30 до 200 миллисекунд в зависимости от маршрута. Всё это время приёмник ничего не передаёт приложению. Это явление называется head-of-line blocking и является основной причиной сбоев любого TCP-протокола при передаче контента по каналу с потерями. Для зрителя это выглядит как «столк»: воспроизведение замирает на полсекунды или несколько секунд, а затем возобновляется.

Вторая половина поведения TCP – это управление перегрузками (congestion control). Когда TCP обнаруживает потерю пакета, он интерпретирует это как признак перегрузки сети и снижает скорость передачи, обычно вдвое. Для потока в 6 Мбит/с одна потеря пакетов приведёт к уменьшению скорости до 3 Мбит/с на несколько секунд, пока TCP осторожно будет восстанавливать пропускную способность. Энкодер продолжает генерировать видео со скоростью 6 Мбит/с, но канал может принять только 3 Мбит/с; локальный буфер энкодера заполняется, кадры отбрасываются, и зрители замечают ухудшение качества изображения. Реакция протокола на сообщение «потерян пакет» – «я буду отправлять меньше данных» – оказывается неверной в ситуации, когда цель – сохранить стабильный поток.

SRT решает обе проблемы, полностью отказываясь от TCP и перестраивая надёжный слой поверх UDP с использованием селективной ретрансмиссии и явно заданного бюджета задержки. Когда SRT теряет пакет 47, приёмник отправляет один NAK с запросом на повторную передачу только этого пакета. Отправитель повторно передаёт пакет 47. Приёмник продолжает передавать приложению пакеты 48, 49, 50 по мере их поступления – никаких ограничений на порядок доставки, если приложение явно не требует ин-ордерной обработки. Если повторная передача пакета 47 успевает попасть в настроенное окно, приёмник вставляет его на своё место. Если нет – приёмник фиксирует одну пропущенную позицию, позволяет декодеру выполнить скрытие ошибок (или отбрасывает один кадр) и продолжает поток.

Арифметика вслух, с реалистичными цифрами. Допустим, ваш путь передачи – 90 мс RTT и 2 процента средних потерь с пиками до 5 процентов. RTMP на таком канале: 2 процента потерь – это примерно один пакет из 50; каждая потеря вызывает ретрансмиссию длительностью 180 мс и снижение скорости отправки вдвое; энкодер передаёт 6 Мбит/с, канал выдерживает только 3 Мбит/с, локальный буфер переполняется, кадры отбрасываются, зрители видят «стол» каждые 30 секунд. SRT на том же пути с буфером 360 мс (4× 90-мс RTT – рекомендованное значение): приёмник отправляет NAK при каждой потере, отправитель ретранслирует пакет в течение одного RTT, приёмник вставляет восстановленный пакет на своё место. Скорость отправки остаётся 6 Мбит/с. Зритель не замечает проблем. Одно и то же событие потерь – два разных результата.

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

Откуда берётся правило 4× RTT для задержки

Если вы ничего больше не запомните про настройку SRT, запомните главное: значение latency должно быть как минимум в четыре раза больше round-trip time контрибьюшен-пути. Это правило – своего рода фольклор: каждый гайд Haivision, каждый документ SRT Alliance и каждый туториал вендора его повторяют. Понимать математику за этим полезно, потому что она помогает правильно рассчитать бюджет задержки для нестандартных маршрутов.

NAK-восстановление включает три временные составляющие. Первая – приёмник должен обнаружить пропущенный пакет: обычно это происходит при обнаружении разрыва в нумерации (пришёл 46, затем 48, а 47 отсутствует). Приёмник ждёт некоторое время перед отправкой NAK, на случай если пакет 47 просто задержался; по умолчанию – один интервал передачи пары пакетов. Вторая – NAK должен дойти от приёмника к отправителю, что занимает половину времени кругового маршрута. Третья – отправитель должен повторно передать пакет 47, что ещё раз занимает половину времени кругового маршрута в том же направлении. Итого – один полный круговой маршрут на одно восстановление плюс небольшая задержка ожидания.

Если одна ретрансмиссия не удаётся – ретранслированный пакет теряется, и приёмник отправляет ещё один NAK, после чего проходит ещё один round-trip. Две ретрансмиссии подряд – два рейса. Три – три. Правило 4× RTT позволяет приёмнику терпеть примерно три раунда ретрансмиссии, прежде чем опоздавший пакет будет отброшен. На канале со средним уровнем потерь 1 % и пиковым – 5 % две последовательные ретрансмиссии редки, но не уникальны; три подряд – ещё реже. Правило настроено так, чтобы обрабатывать реальные паттерны потерь, не отбрасывая пакеты, которые можно было бы восстановить при чуть более длительном ожидании.

Арифметика вслух. Допустим, у пути RTT составляет 30 мс (типичная проводная связь в пределах одной страны). Задержка должна быть не менее 4 × 30 = 120 мс, а 200 мс – безопасное значение по умолчанию с запасом на джиттер. При RTT 200 мс (трансатлантический оптический канал): задержка не менее 4 × 200 = 800 мс, 1000 мс – безопасный дефолт. 4G-аплинк с RTT 150 мс и высоким джиттером: задержка не менее 4 × 150 = 600 мс, но мобильные соединения выигрывают от большего запаса – типичные значения для сотовой контрибьюции составляют 1500–4000 мс, поскольку сам RTT может колебаться на сотни миллисекунд. Геостационарный спутник с RTT 600 мс: минимум 2400 мс; production-сетапы спутниковой контрибьюции часто работают на 4000–8000 мс.

Выбираемое значение – это прямой компромисс между задержкой «стекло к стеклу» и устойчивостью. Чем меньше задержка – тем меньше времени у SRT на восстановление, больше потерь пакетов, больше артефактов. Чем больше задержка – тем больше пакетов успевает восстановиться, но зритель видит происходящее с опозданием. Правило 4× RTT – это минимальное значение; рабочая настройка – это минимальное плюс запас на худший случай джиттера, измеренный на пути.

Вывод: задержка SRT настраивается, она не фиксирована. Проводное соединение в пределах города обеспечивает задержку менее 200 мс от экрана до экрана, тогда как спутниковая связь даёт задержки в несколько секунд. Оптимальное значение – минимальное, которое выдерживает худший случай RTT плюс измеренный джиттер, а не предполагаемый.

Caller, Listener, Rendezvous – режимы соединения

SRT определяет три режима соединения. Большинство операторов настраивают только два из них; третий используется в одном конкретном случае прохождения NAT. Понимание того, в каком режиме работает энкодер, а в каком – сервер, – самая частая трудность при настройке нового SRT-линка.

Caller mode. Энкодер инициирует соединение, отправляя UDP-пакеты на адрес сервера. Это аналог сценария «я – клиент, подключаюсь к серверу». Режим Caller применяется на стороне энкодера, когда сервер имеет фиксированный публичный адрес, а сам энкодер находится за NAT или иначе не может принимать входящие соединения.

Listener mode. Энкодер (или сервер) открывает UDP-сокет и ожидает входящих запросов на подключение. Это аналог сценария «я – сервер, принимаю клиентов». Режим listener используется на стороне сервера в стандартной архитектуре потоковой передачи: ingest-сервер слушает srt://0.0.0.0:9000, а энкодер инициирует соединение как caller. Реже встречается обратная конфигурация – энкодер, размещённый в облачной виртуальной машине с публичным IP-адресом, работает в режиме listener, а receiver подключается как caller. Такой подход полезен, когда receiver мобильный, а отправитель – статичный.

Rendezvous mode. Оба конца одновременно пытаются установить соединение, отправляя UDP-пакеты на публичный адрес друг друга. Это аналог сценария «оба инициируют, протокол выбирает мастера». Режим rendezvous применяется в симметричных NAT, где ни одна из сторон не может слушать на публичном порту, но обе способны пробить свой NAT с помощью исходящих пакетов на известную пару адресов. На практике rendezvous используется в peer-to-peer-сценариях обмена данными между двумя энкодерами или двумя полевыми локациями; почти ни один коммерческий ingest-решение не предоставляет rendezvous-точки.

Правило сопоставления работает механически: caller должен подключаться к listener’у, либо два caller’а используют rendezvous. Caller-to-caller без rendezvous – недопустимо; listener-to-listener – тоже недопустимо. Большинство production-развёртываний используют схему caller (энкодер) → listener (сервер), при этом сервер находится по публичному адресу; именно такую конфигурацию ожидает каждая крупная облачная платформа.

Тонкость, на которую стоит обратить внимание: режим соединения SRT не зависит от того, какая сторона передаёт медиа. Протокол содержит параметр направления (m=publish / m=read в SRT URI), определяющий, будет ли инициатор (caller) отправлять данные или получать их. Таким образом, caller может либо передавать видео listener’у, либо получать видео от listener’а – топология соединения не привязана к направлению передачи медиа. Большинство путей для вклада контента – это caller-publish (энкодер отправляет данные на сервер listener’а), однако паттерн caller-read (приёмник получает данные от энкодера listener’а) также является легитимным и полезным, особенно в условиях удалённого производства.

Шифрование – AES-128 vs AES-256, и почему оно вам нужно

SRT опционально шифрует полезную нагрузку с помощью AES-128 или AES-256 в режиме CTR. Шифрование по умолчанию отключено – протокол может работать и без него – однако любой production-сетап в публичной сети должен его включать. Затраты минимальны (несколько процентов CPU на современном энкодере; накладные расходы на пропускную способность – один байт на пакет под заголовок шифрования), а выгода существенна: стрим невозможно перехватить, перенаправить или повторить, даже если кто-то перехватывает UDP-трафик на пути доставки.

Механизм прост. Обе стороны договариваются о общей фразе-пароле (shared passphrase) – строке длиной от 10 до 79 символов, которую настраивает оператор на каждой стороне. На заключительной стадии рукопожатия (conclusion phase) слушатель (listener) генерирует случайную соль, отправляет её вызывающей стороне (caller), и обе стороны на основе фразы-пароля и соли с помощью PBKDF2 вычисляют ключ шифрования ключей (Key Encrypting Key, KEK). Затем слушатель генерирует случайный ключ шифрования потока (Stream Encrypting Key, SEK), оборачивает его с помощью AES key-wrap с использованием KEK и передаёт обёрнутый SEK вызывающей стороне. Вызывающая сторона разворачивает SEK с помощью своего KEK. Теперь обе стороны обладают общим свежим SEK, который никто, перехватывающий соединение, не может восстановить только по данным рукопожатия – сама фраза-пароль никогда не передаётся по каналу. Далее плоскость данных шифрует каждый блок полезной нагрузки с помощью SEK в режиме AES-CTR, используя номер последовательности плюс случайную компоненту IV в качестве входного значения счётчика.

AES-128 против AES-256 – выбор между двумя вариантами одного и того же алгоритма. AES-128 использует 128-битный ключ и выполняет 10 раундов подстановки; AES-256 – 256-битный ключ и 14 раундов. Вычислительная нагрузка AES-256 примерно на 40 % выше, чем у AES-128 – разница, которая практически незаметна на современных процессорах с поддержкой AES-NI (фактически равна нулю) и ощущается только на маломощных встраиваемых энкодерах без аппаратного ускорения. Криптографическая разница для потокового видео носит академический характер: AES-128 требует около 2¹²⁸ операций для перебора, что абсолютно недостижимо. Выбирайте AES-128, если важна производительность CPU на маломощном энкодере; AES-256 – если требования соответствия (compliance) это предписывают (некоторые стандарты вещания требуют AES-256 для защиты контента). Протокол согласовывает размер ключа во время установления соединения: обе стороны должны прийти к соглашению, иначе соединение не будет установлено.

Самая частая ошибка при настройке шифрования – слабый пароль-фраза: «test1234» или «password» на продакшн-сервере. PBKDF2 замедляет перебор, но 10-символьная фраза-пароль из стандартного алфавита клавиатуры имеет около 60 бит энтропии – это вычислительно осуществимо, если злоумышленник перехватил handshake. Используйте генератор фраз-паролей и обращайтесь с ним как с приватным TLS-ключом: 32+ случайных символа, регулярная ротация, хранение в менеджере секретов. Надёжность шифрования протокола определяется исключительно силой passphrase.

Три режима – Live, File-Buffer, File-Message

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

Live mode – режим, используемый для видео. Отправитель формирует один пакет прикладного уровня (обычно чанк MPEG-TS или тег FLV) и передаёт его в одной UDP-датаграмме. Получатель считывает одну датаграмму и извлекает из неё один прикладной пакет. Бюджет задержки строго ограничен: пакеты, превышающие этот лимит, отбрасываются. Протокол может доставлять пакеты не по порядку – например, если более поздний пакет приходит раньше восстановленного, – однако на практике при передаче MPEG-TS через SRT временные метки содержатся в elementary stream, и приложение самостоятельно переупорядочивает данные внутри декодера. Режим Live – единственный, имеющий значение для стриминга. Если у вас нет особых причин выбирать иное, и энкодер, и сервер должны работать в режиме live.

File-Buffer Mode – режим для передачи больших объёмов данных, в котором используются семантики потокового байтового потока, как в TCP, но с возможностью селективной ретрансмиссии, характерной для SRT. Отправитель записывает поток байтов, получатель читает поток байтов. SRT не сохраняет границы на уровне приложения – поведение аналогично TCP, но без требования строгой упорядоченности, с тем отличием, что получатель может видеть фрагменты данных на произвольных границах. Этот режим предназначен для перемещения крупных медиафайлов (например, готовый 4K-мастер из удалённой локации в центральный архив), где важна надёжность, а задержка не критична.

Режим file-message сохраняет границы сообщений на уровне приложения, используя ту же селективную ретрансмиссионную механику. Отправитель формирует одно сообщение объёмом до 64 КБ; получатель читает ровно это сообщение. По сути напоминает SCTP. Редко применяется для передачи видео.

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

SRTLA – объединение нескольких соединений для мобильной и IRL-контрибуции

Единственное слабое место SRT, как и любого другого протокола с передачей потока, – он может использовать только столько пропускной способности, сколько предоставляет нижестоящее соединение. Один 4G-аплинк может обеспечивать до 8 Мбит/с при хороших условиях и лишь 1 Мбит/с при перегрузке соты или слабом сигнале. Для движущегося энкодера – репортёра в машине, спортивного видеографа на бровке, IRL-стримера на улице – ни одно сотовое соединение в одиночку не способно обеспечить вещательное качество видео.

SRTLA – SRT Link Aggregation – это ответ. Это UDP-прокси, который размещается между SRT-отправителем и сетью, принимает поток SRT-пакетов и распределяет его по двум и более сетевым интерфейсам (обычно двум–шести сотовым модемам от разных операторов, плюс опционально Wi-Fi). На стороне приёма соответствующий SRTLA-приёмник собирает пакеты обратно в единый SRT-поток, который SRT-сервер обрабатывает так, будто он пришёл по одному каналу. Агрегированная пропускная способность равна сумме всех каналов, отказ одного из операторов компенсируется остальными, а объединённый канал оказывается надёжнее любого отдельного сотового соединения.

SRTLA разработан проектом BELABOX – open-source инициативой IRL-стриминга, вышедшей из культуры уличного стриминга (Twitch, Kick, YouTube Live), – и сегодня является де-факто стандартом для мобильной сотовой передачи. Аппаратная часть BELABOX (компактный Linux-устройство с USB-портами для сотовых модемов) – самый распространённый SRTLA-отправитель; приёмник SRTLA работает на облачных серверах или на стороне приёма. Сейчас SRTLA также реализован в нескольких коммерческих энкодерах: Haivision Pro 460, LiveU LU800 (с проприетарным бондингом параллельно SRTLA) и у ряда менее крупных вендоров, ориентированных на рынок новостей и спорта.

Детали протокола важны для планирования ёмкости. SRTLA не разбивает поток по кадрам – он делит данные на уровне SRT-пакетов, что означает, что один кадр может быть разделён между двумя-тремя модемами. На стороне приёмника SRTLA собирает пакеты по номеру последовательности перед передачей в SRT-сервер. Задержка, вносимая SRTLA, невелика (обычно 20–100 мс сверх базового бюджета SRT), но протокол требует, чтобы SRT-латентность была установлена с учётом худшего случая вариации RTT по всем объединённым каналам – ведь пакет, отправленный по быстрому 5G, может прийти раньше пакета, отправленного ранее по медленному 4G, и приёмнику SRT нужен запас времени, чтобы дождаться более медленного. Типичная конфигурация SRTLA использует SRT-латентность 4000–8000 мс для объединённого канала 4G/5G – значительно больше, чем для одного проводного соединения, но такой компромисс оправдан выигрышем в пропускной способности и устойчивости.

Для развёртки IRL- или remote-продакшена в 2026 году стандартный стек включает оборудование BELABOX на стороне источника, SRTLA-бондинг через три–шесть сотовых модемов, SRT-receiver в облаке (чаще всего Cloudflare Stream, AWS Elemental MediaConnect или самостийный Linux-VM с эталонной реализацией SRT) и SRT-to-HLS или SRT-в-RTMP пакер на выходе для дистрибуции. Мы применяли эту архитектуру в live-новостях и полевом продакшене – она надёжно работает на сотовых, фиксированных беспроводных и смешанных полевых локациях.

Что поддерживает SRT в 2026 году

Полезное упражнение: перечислить платформы, поддерживающие SRT-ингест в 2026 году, и указать, где SRT вытесняет RTMPS, а где используется параллельно с ним.

Паттерн остаётся стабильным: consumer-соцплатформы (YouTube, Twitch, Facebook, TikTok, Kick) в 2026 году продолжают использовать только RTMPS для приёма потока, тогда как developer-платформы и broadcast-решения (AWS MediaConnect, Cloudflare Stream, Dolby Millicast, Mux Live, Wowza, Nimble, Haivision Hub, Vimeo) поддерживают SRT, обычно наряду с RTMPS и WHIP на одной точке подключения. Разделение по аудитории таково: публикуете контент в consumer-социальные сети – используйте RTMPS; работаете с профессиональной контрибьюцией, удалённым продакшеном или B2B-видео-продуктами – SRT – правильный выбор.

Частые ловушки – ошибки, ломающие SRT в продакшене

Короткий список отказов, которые чаще всего возникают при настройке нового SRT-линка. Большинство из них – не ошибки протокола, а конфигурационные несоответствия, о которых сообщения об ошибках протокола не дают понятного объяснения.

Ловушка 1: рассинхрон latency между sender и receiver. Latency согласовывается на этапе handshake – обе стороны предлагают своё значение, и итоговый бюджет определяется как максимум из двух. Если sender требует 200 мс, а receiver – 5000 мс, то общий лимит составит 5000 мс. Большинство сбоев в production возникают, когда receiver настроен на значение по умолчанию – 120 мс, а отправителю (sender) реально нужно 800 мс; receiver отбрасывает «опоздавшие» пакеты, которые sender считал восстановимыми, и поток начинает выглядеть повреждённым, хотя восстановление могло бы сработать при более высоком бюджете. Решение – настроить обе стороны на одинаковое значение, соответствующее худшему случаю RTT.

Ловушка 2: rendezvous там, где работает caller-listener. Операторы иногда выбирают rendezvous по умолчанию, потому что фраза «обе стороны коннектятся» звучит проще, но на деле rendezvous значительно сложнее в отладке (обе стороны должны быть доступны в момент соединения; firewall должен разрешать исходящие соединения на IP и порт пира; многие облачные провайдеры вообще не пропускают входящий UDP). Используйте caller-listener, когда у одной из сторон есть стабильный публичный адрес; rendezvous оставляйте для случаев, когда ни у одной стороны его нет.

Ловушка 3: слабый или дефолтный passphrase. Относитесь к passphrase как к приватному TLS-ключу: используйте 32 и более случайных символов, регулярно меняйте и храните в менеджере секретов.

Ловушка 4: UDP-фаервол не открыт. SRT работает поверх UDP, и многие корпоративные фаерволы обрабатывают исходящий UDP иначе, чем исходящий TCP. Типичная ситуация – энкодер не может установить handshake, потому что фаервол блокирует выбранный порт. Решение – открыть исходящий UDP на нужный порт (и входящий на стороне приёмника); в большинстве production-развёртываний используют порты UDP 9000 или 9999, поскольку операторы привыкли к этим номерам.

Ловушка 5: MTU не учли. SRT по умолчанию использует полезную нагрузку размером 1316 байт, что укладывается в стандартный Ethernet-кадр объёмом 1500 байт с учётом IP- и UDP-заголовков. Однако на путях с меньшим MTU – например, в VPN-туннелях или при передаче IPv6 через IPv4 – большие пакеты SRT фрагментируются на уровне IP. При этом механизм path-MTU discovery в IPv4 иногда работает некорректно или вообще не срабатывает, из-за чего поток может успешно установить handshake, но не сможет передавать медиаданные. Решение – настроить параметр mss в SRT под реальный MTU канала.

Ловушка 6: нет мониторинга retransmission rate. SRT предоставляет богатый набор статистики – отправленные, ретранслированные, потерянные и отброшенные пакеты, а также отправленные и полученные NAK – но большинство операторов её игнорируют. Здоровый SRT-канал должен иметь retransmission rate ниже 0,5 процента. Если показатель превышает 5 процентов – канал сильно подвержен потерям, и при пиковых нагрузках он начнёт сбрасывать кадры. Следите за этим показателем, настраивайте оповещения по retransmission rate и разберитесь с проблемой до того, как зрители начнут жаловаться.

Прорабатываемый пример – SRT на проводе, числа вслух

Протестируем одну реальную end-to-end конфигурацию с цифрами. Передаём 1080p60 HEVC со скоростью 8 Мбит/с с venue-энкодера в облачный ingest, где работает HLS-пакер. Контрибьюшен-путь – 90 мс по публичному интернету от стадиона в Мадриде до AWS eu-west-1 в Дублине. Энкодер – OBS Studio 32 на Mac mini с проводным Ethernet, у которого зафиксировано 2 % средних потерь пакетов с пиками до 5 % вечером.

SRT URI на стороне энкодера: srt://ingest.example.com:9000?mode=caller&latency=400&passphrase=<32-char-secret>&pbkeylen=16&streamid=#!::r=eu-west-1,m=publish,u=stadium-cam-1. На приёмной стороне – поток AWS Elemental MediaConnect, настроенный как SRT-слушатель на порту 9000 с тем же паролем и временем ожидания 400 мс. Обмен ключами завершается примерно за 100 мс (два UDP-рейса). Энкодер устанавливает одно UDP-соединение и начинает передавать HEVC-пакеты, упакованные в MPEG-TS: каждый TS-чанк помещается в один SRT-пакет в режиме live, а каждый SRT-пакет – в одну UDP-датаграмму с полезной нагрузкой 1316 байт.

В стационаре энкодер генерирует видео со скоростью 8 Мбит/с. Слой SRT добавляет около 4 % накладных расходов на sequence numbers, заголовки и шифрование AES-128 – итого по каналу передаётся примерно 8,32 Мбит/с. Приёмник отправляет NAK с частотой около 1,8 % от общего числа пакетов в вечерний пик; отправитель выполняет ретрансмиссию, которая укладывается в 400-миллисекундное окно – поток остаётся стабильным. Поток MediaConnect форвардится в origin-сервер Elemental MediaPackage, который формирует HLS-сегменты длительностью 4 секунды. Зритель получает поток с задержкой около 8 секунд «от экрана до экрана»: 1 секунда – буфер GOP энкодера, 0,4 секунды – окно SRT, 0,1 секунды – транзит через MediaConnect, 4 секунды – упаковка в HLS, 2,5 секунды – буфер плеера на стороне зрителя.

Сравним тот же путь по RTMPS. Всплеск потерь на 2% вызвал бы TCP-ретрансмиссии каждые 50 пакетов и снизил бы скорость передачи с 8 до 4 Мбит/с на несколько секунд в вечерний пик. Локальный буфер энкодера заполнялся бы, кадры терялись, зрители видели бы «столы» примерно каждые 30 секунд. Форма та же – потоковая передача с площадки в облако – но режим отказа разный. SRT сохраняет поток; RTMPS теряет кадры.

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

Мы внедрили SRT-трансмиссию в продакшен для OTT- и удалённых производственных решений, спортивных и event-стримов, телемедицины (клиническая камера, передающая данные на центральный сервер через госпитальный Wi-Fi), записи аудиторий в e-learning через коммерческий широкополосный интернет, а также для систем видеонаблюдения, агрегирующих потоки с полевых энкодеров в центральный recording origin. Паттерн, повторяющийся во всех вертикалях, один: если путь контрибьюшена – не приватная оптика, SRT превосходит RTMPS и оправдывает усилия по правильной настройке. При построении стека контрибьюшена для клиента мы по умолчанию используем SRT с RTMPS в качестве резервного канала для legacy-энкодеров.

SRT vs RIST vs WHIP – как выбрать

SRT – не единственный современный протокол контрибьюции, но самый распространённый. Чтобы получить полную картину, кратко сравним его с двумя главными конкурентами. Подробное сравнение – в Как выбрать ingest-протокол в 2026, а краткая версия – ниже.

RIST (Reliable Internet Stream Transport) – ответ отраслевого стандарта broadcast-индустрии на ту же задачу, что и SRT. Его специфицируют технические отчёты SMPTE TR-06-1, TR-06-2 и TR-06-3. У RIST есть три профиля: Simple, Main и Advanced. Профиль Simple примерно соответствует раннему SRT (UDP с селективной ретрансляцией), Main добавляет шифрование и аутентификацию, а Advanced – туннелирование и объединение каналов (link bonding). Главное преимущество RIST в том, что это открытый стандарт, опубликованный авторитетной организацией (SMPTE), а не инициатива одного вендора; это особенно важно для вещательных компаний, где требования к соответствию регламентам (compliance) опираются на документы от стандартовых организаций. Распространение RIST реальное, но пока уступает SRT: по данным отчёта Haivision Broadcast Transformation Report 2024, RIST использовали 22 процента вещателей против 68 у SRT. Выбирайте RIST вместо SRT, если ваш compliance-мандат требует использование стандарта SMPTE или вы интегрируетесь в вещательную систему, уже нативно работающую с RIST.

WHIP (WebRTC-HTTP Ingestion Protocol, RFC 9725) – это новый протокол для субсекундной передачи контента. WHIP представляет собой WebRTC-ingest, реализованный через простой HTTP POST: транспортная часть – SCTP поверх DTLS поверх UDP, как в WebRTC, а бюджет задержки соответствует WebRTC (обычно 200 мс – 1 секунда от экрана до экрана). Выбирайте WHIP вместо SRT, если нужна субсекундная задержка и вы готовы принять вычислительную нагрузку WebRTC и сложность разработки. Оставайтесь на SRT, если оборудование для передачи – традиционный вещательный энкодер, не поддерживающий WebRTC, или если путь проходит через спутник или имеет экстремальную задержку, при которой буфер джиттера WebRTC не справляется.

Решение одной фразой: SRT – для профессионального вещания с задержкой от 200 мс до нескольких секунд по lossy-каналу; RIST – когда требуется соответствие стандарту SMPTE; WHIP – когда важна субсекундная задержка по надёжному каналу.

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

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

• SRT передаёт данные по UDP с селективной повторной передачей в пределах окна задержки; при потерях пакетов не «зависает», в отличие от RTMP.
• Задержка должна быть не менее 4× RTT; рассчитывайте на худший случай джиттера, а не на среднее значение.
• Топология «вызывающий – слушающий» – стандартная; rendezvous используется только при симметричном NAT.
• Шифрование AES-128 или AES-256 практически не нагружает современное оборудование – включайте его на каждом production-соединении.
• SRTLA объединяет несколько сотовых аплинков в единый поток; это стандарт для мобильной и IRL-трансляции.
• В 2024 году SRT использовали 68 процентов вещателей; поддержка протокола в developer-платформах (AWS, Cloudflare, Mux, Dolby) стала повсеместной.

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

• RTMP в 2026: мёртвый протокол, бессмертный дефолт – протокол, который SRT вытесняет на lossy-каналах, и почему социальные платформы до сих пор его требуют.
• WHIP – WebRTC ingest и RFC 9725 – альтернатива с задержкой менее секунды для передачи контента, когда критична низкая латентность.
• Как выбрать ingest-протокол в 2026 – полное решение по выбору между RTMP, SRT, RIST, WHIP и профессиональными опциями вещания.

CTA

Поговорить с инженером по стримингу · Посмотреть кейсы · Скачать чек-лист SRT-контрибуции (PDF)