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

Последняя сверка: 2026-05-20 со спецификацией IETF Internet-Draft draft-sharabayko-srt-01 (истёк в марте 2022, остаётся наиболее полным публичным документом), исходниками и документацией референсной реализации Haivision SRT v1.5.4 на GitHub, SRT Alliance Deployment Guide 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-grade надёжностью. 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-видео с площадки, стадиона, удалённой съёмочной группы, репортажного аппарата или мобильного энкодера, главный операционный риск – контрибьюшен-путь: участок между энкодером и первым сервером, который вы контролируете. Именно там джиттер, потери и congestion публичного интернета съедают поток заживо, и именно там RTMP – дефолт двух десятилетий – реально ломается в полевых условиях. SRT появился, потому что Haivision был нужен протокол контрибьюции, переживающий 5-процентный всплеск потерь на venue Wi-Fi без разрыва, а остальная индустрия подхватила его, потому что тот же ответ работает для репортажек, бондинга сотовых модемов и cloud-to-cloud фидов.

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

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

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

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

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

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

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

Краткая история того, как SRT сюда пришёл

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

К 2017 году у Haivision накопилось достаточно proof points (NFL, использующая SRT для venue-фидов; новостные службы для удалённой контрибьюции), чтобы сделать стратегическую ставку: открыть протокол, отдать его индустрии и превратить hardware-only фичу в стандарт, который каждый может реализовать. На NAB 2017 Haivision выложила спецификацию протокола и реализацию на 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 годами. SRT Alliance перевалил отметку 600 членов в 2024-м и 700 – в 2025-м, став крупнейшим open-protocol альянсом в стриминг-индустрии.

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

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

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

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

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

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

SRT решает обе проблемы, отказываясь от TCP полностью и перестраивая слой надёжности поверх UDP с селективной ретрансмиссией и явным бюджетом задержки. Когда SRT теряет пакет 47, receiver посылает один NAK с запросом ретрансмитнуть только 47. Sender ретрансмитит 47. Receiver продолжает отдавать приложению пакеты 48, 49, 50 по мере их прихода – никакого in-order ограничения, если только приложение его явно не потребует. Если ретрансмиссия 47 успевает в настроенное окно – receiver вставляет 47 на нужное место. Если нет – receiver фиксирует одну дыру, пускает декодер делать error concealment (или дропает один кадр) и продолжает поток.

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

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

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

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

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

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

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

Выбираемое значение – это прямой trade между glass-to-glass задержкой и устойчивостью. Меньше latency – у SRT меньше времени на восстановление, больше дропов, больше глитчей. Больше latency – больше пакетов восстановится, но зритель видит событие позже. Правило 4× RTT – это пол; рабочая настройка – пол плюс запас на worst-case джиттер, замеренный на пути.

Вывод: пол задержки SRT настраиваемый, не фиксированный. Проводной путь внутри города даёт sub-200 мс glass-to-glass; спутник – секунды. Правильное значение – наименьшее, которое выдерживает worst-case RTT плюс джиттер, замеренный, а не угаданный.

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

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

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

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

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 (receiver тянет от listener-энкодера) – легитимный и полезный паттерн для удалённого продакшена.

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

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

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

AES-128 против AES-256 – выбор между двумя силами одного алгоритма. AES-128 использует 128-битный ключ и даёт 10 раундов подстановки; AES-256 – 256-битный ключ и 14 раундов. Вычислительный overhead AES-256 примерно на 40 процентов выше AES-128 – цифра, которая невидима на современных CPU с AES-NI (фактически ноль) и заметна только на маленьких встраиваемых энкодерах без аппаратного ускорения. Криптографическая разница академична для live-видео: AES-128 оценивается в ~2^128 операций для brute-force, что недосягаемо. Берите AES-128, если важен CPU на маленьком энкодере; AES-256, если ваш compliance это мандатирует (некоторые broadcast-стандарты специфицируют AES-256 для защиты контента). Протокол негоциирует размер ключа во время handshake; обе стороны должны согласиться, и если не согласны – соединение не устанавливается.

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

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

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

Live mode – то, что использует видео. Sender пишет один application-level пакет (обычно чанк MPEG-TS или Tag FLV) в одну UDP-датаграмму. Receiver читает одну датаграмму, получает один application-пакет. Бюджет задержки жёстко принудителен: пакеты старше бюджета дропаются. Протокол может отдать пакеты не по порядку, если поздний пришёл раньше восстановленного, но на практике MPEG-TS-over-SRT несёт timestamps в elementary stream, и приложение переупорядочивает внутри декодера. Live – единственный режим, который имеет значение для стриминга, и если у вас нет специального повода выбрать иное, и энкодер, и сервер должны быть в live.

File-buffer mode – для перекачки bulk-данных, где нужны byte-stream-семантики как у TCP, но с селективной ретрансмиссией SRT. Sender пишет поток байт; receiver читает поток байт. SRT не сохраняет application-level границы – поведение TCP без in-order-ограничения, с тем нюансом, что receiver может видеть чанки на произвольных границах. Этот режим – для перемещения больших медиа-файлов (готовый 4K-мастер из удалённой локации в центральный архив), где задержка не важна, а надёжность важна.

File-message mode сохраняет application-level границы сообщений, используя ту же селективно-ретрансмиссионную машинерию. Sender пишет одно сообщение до 64 КБ; receiver читает ровно это сообщение. По духу похоже на SCTP. Редко используется для видео.

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

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

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

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

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

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

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

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

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

Паттерн стабильный: consumer-соцплатформы (YouTube, Twitch, Facebook, TikTok, Kick) в 2026 году остаются RTMPS-only для ingest, а developer-platform и 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 думал успеть восстановить, и поток выглядит сломанным, хотя восстановление сработало бы при большем бюджете. Лечение – настраивать обе стороны на одно значение, под worst-case RTT.

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

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

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

Ловушка 5: MTU не учли. SRT дефолтит на 1316-байтную полезную нагрузку, что вписывается в стандартный 1500-байтный Ethernet-MTU с запасом на 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 процентов – путь существенно lossy, и линк будет дропать кадры на пиках. Мониторьте; алертьте по retransmission rate; разбирайтесь до того, как пожалуются зрители.

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

Прогоним одну реальную конфигурацию end-to-end с цифрами. Гоним 1080p60 HEVC на 8 Mbps с 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 flow, настроенный как SRT-listener на порту 9000 с тем же passphrase и бюджетом 400 мс. Handshake завершается за ~100 мс (два UDP-рейса). Энкодер устанавливает одно UDP-соединение и начинает стримить HEVC-пакеты, упакованные в MPEG-TS, каждый TS-чанк в один SRT live-mode пакет, каждый SRT-пакет в одну UDP-датаграмму 1316 байт полезной нагрузки.

В стационаре энкодер генерирует 8 Mbps видео, слой SRT добавляет ~4 процента overhead под sequence numbers, заголовки и AES-128 – итого ~8.32 Mbps по проводу. Receiver шлёт NAK на замеренной частоте 1.8 процента от общего числа пакетов в вечерний пик; sender ретрансмитит, ретрансмиссии успевают в 400-мс окно, поток чистый. MediaConnect flow форвардит в Elemental MediaPackage origin, делающий 4-секундные HLS-сегменты. Зритель видит поток с примерно 8 секундами glass-to-glass – 1 секунда GOP-буфера энкодера, 0.4 секунды SRT-окна, 0.1 секунды транзита MediaConnect, 4 секунды HLS-пакейджинга, 2.5 секунды плеер-буфера у зрителя.

Сравните тот же путь по RTMPS. 2-процентный всплеск потерь триггерил бы TCP-ретрансмиссии каждые 50 пакетов и ополовинивал бы send rate с 8 Mbps до 4 Mbps на несколько секунд в вечерний пик. Локальный буфер энкодера заполнялся бы, кадры дропались, зрители видели бы столы каждые ~30 секунд. Форма та же – пуш контрибьюции с площадки в облако – но режим отказа разный. SRT держит поток; RTMPS дропает кадры.

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

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

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

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

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

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

Решение одной фразой: SRT – для профессиональной контрибьюции с 200 мс – несколькими секундами задержки на lossy-пути; RIST – когда constraint это SMPTE-compliance; WHIP – когда constraint это суб-секундная задержка на чистом пути.

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

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

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

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

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

CTA

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