SRT
Введение
Secure Reliable Transport (SRT) — протокол, разработанный компанией Haivision в 2012 году. Протокол работает на базе UDT (UDP-based Data Transfer Protocol) и технологии восстановления пакетов ARQ.
UDT работает поверх транспортного протокола UDP, как показано в таблице 1. В текущей 4й версии протокола UDT есть система управления потоком, система контроля целостности данных и реализован механизм работы с клиентами за NAT:S
Таблица 1 – Расположение протокола UDT в протоколе TCP/IP
| 4 – Прикладной уровень | UDT |
|---|---|
| 3 – Транспортный уровень | UDP |
| 2 – Сетевой уровень | Для TCP/IP – это IP |
| 1 – Канальный уровень | Физическая среда (LAN/WiFi) и принципы кодирования информации |
Протокол устанавливает два UDP соединения (рисунок 1). Одно — для передачи данных получателю, второе — для передачи контрольной информации отправителю:
Рисунок 1 – UDP-соединение между клиентом и сервером
В отличие от стандартного UDT, в SRT полностью переписана архитектура переотправки пакетов, чтобы реагировать сразу же, как только пакет потерян. Такая технология является вариацией selective repeat/reject ARQ. Selective Repeat (SR) и Selective Reject (SREJ) - это две разновидности протокола автоматического запроса повторной передачи (ARQ), используемого для обеспечения надежной передачи данных по ненадежной сети. Оба протокола используют метод скользящего окна для отслеживания отправленных и принятых пакетов данных. Принцип "скользящего окна" (sliding window), заключается в том, что каждая сторона может отправлять максимум столько байт, сколько отправитель указал в поле "размер окна" заголовка TCP-пакета, подтверждающего получение предыдущих данных.
Соединение
На приведенной ниже диаграмме представлен обмен данными между двумя одноранговыми узлами (рисунок 2):
Начало рукопожатия
Обмен файлами cookie MD5 – это функция, предназначенная для защиты потоков от DDoS-атак. DDoS-атака – это способ заблокировать работу сайта путем подачи большого количества запросов, превышающих пропускную способность сети. Для предотвращения этого SRT использует обмен cookie-файлами, над которыми выполняется функция хэширования с помощью алгоритма MD5.
Cookie-файл — небольшой фрагмент данных, отправленный веб-сервером и хранимый на компьютере пользователя. Веб-клиент (обычно веб-браузер) всякий раз при попытке открыть страницу соответствующего сайта пересылает этот фрагмент данных веб-серверу в составе запроса. Требуя от источника выполнения этой операции, обмен файлами cookie MD5 помогает предотвратить получение запросов от злоумышленников.
Обмен возможностями
На данном этапе между сервером и клиентом происходит обмен информацией: размер буфера, информация о шифровании, версия рукопожатия (в SRT реализовано два механизма установления связи), идентификатор потока.
Шифрование
SRT поддерживает сквозное шифрование с помощью AES. Сквозное шифрование — это когда сообщения шифруются на вашем устройстве и расшифровываются только на конечном устройстве. Весь путь от отправителя до получателя сообщение преодолевает в зашифрованном виде, поэтому его никто не может прочитать, кроме вашего собеседника.
Advanced Encryption Standard (AES) — симметричный алгоритм блочного шифрования. Основу алгоритма составляют замены, подстановки и линейные преобразования, каждое из которых выполняется блоками по 128 бит (цифры со значениями от 0 или 1), являющиеся основой структуры входных и выходных данных, поэтому он и носит называние блочного шифра. Повторение операций происходит неоднократно и в процессе каждой итерации (раунда) вычисляется уникальный ключ на основе ключа шифрования и встраивается в дальнейшие вычисления. Надежность шифрования обеспечивается тем, что изменение даже одного блока влечет за собой изменение последующих блоков и полное изменение конечных данных на выходе.
Только точка-точка
В настоящее время невозможно создать зашифрованный поток SRT через какое-либо промежуточное устройство (например, шлюз). Это связано с тем, что ключи, используемые для шифрования, обмениваются во время первоначального рукопожатия между отправителем и получателем. Это тип соединения "точка-точка", что означает, что обмен ключами осуществляется только между двумя конечными точками и не может быть перехвачен или изменен каким-либо промежуточным устройством. Если бы в канал связи было введено промежуточное устройство, у него не было бы ключей шифрования, которыми обменивались во время первоначального рукопожатия. В результате промежуточное устройство не смогло бы расшифровать данные и переслать их на следующий переход по каналу связи. Это потребовало бы установления другого сеанса между промежуточным устройством и конечной точкой, что потребовало бы нового рукопожатия и новых ключей шифрования.
С точки зрения возможности маршрутизации зашифрованных потоков через промежуточные устройства, существует разница между RTSP и SRT. Потоки RTSP могут маршрутизироваться через промежуточные устройства при условии, что устройства способны должным образом обрабатывать пакеты RTP (Real-time Transport Protocol) и RTCP (Real-time Transport Control Protocol).
Восстановление соединения
Как только поток запущен, протокол устанавливает соединение с регулярным подтверждением между узлами. По мере необходимости для поддержания соединения осуществляется обмен пакетами keepalive. При перерывах в работе сети продолжительностью менее 1 секунды соединение SRT может быть восстановлено автоматически. Устройства будут пытаться повторно подключиться и повторять попытки до тех пор, пока пользователь не удалит соединение из своей конфигурации.
Шифрует ли SRT поток на пакетном уровне? Нет, шифрование происходит на уровне полезной нагрузки. Шифруются только те данные, которые передаются. Вся управляющая информация отправляется в открытом виде (это позволяет избежать повторяющихся шаблонов, которые ослабили бы шифрование). Обратите внимание, что шифрование не оказывают влияние на сам поток SRT – оно создает нагрузку на процессоры отправителя и получателя, которая пропорциональна количеству потоков и их битрейтам.
Задержка
Существует временная задержка, связанная с отправкой пакетов по (обычно непредсказуемой) сети. Из-за этой задержки устройству-источнику SRT приходится помещать пакеты, которые оно отправляет, в очередь в буфере, чтобы убедиться, что они доступны для передачи и повторной передачи. С другой стороны, устройство назначения SRT должно поддерживать свой собственный буфер для хранения входящих пакетов (которые могут поступать в любом порядке), чтобы убедиться, что у него есть нужные пакеты в нужной последовательности для декодирования и воспроизведения. Задержка SRT - это фиксированное значение (от 80 до 8000 мс), не меньшее максимального размера буфера, доступный для управления пакетами SRT. Время задержки равно сумме используемого буфера (не обязательно максимального), пингов, времени кодирования и декодирования.
Буфер задержки
Задержка – это время, определяющее насколько позже пришли пакеты после отправки. На отправителя задержка почти не влияет, т.к. она важна только если ACK-сообщение не дошло или потерялось. Со стороны получателя задержку можно представить как окно, которое скользит с течением времени, в течение которого выполняется ряд действий (рисунок 3):
Рассмотрим буфер получателя, в котором хранится серия пакетов. Допустим, мы определили задержку так, что она охватывает период, эквивалентный передаче шести пакетов. Возможность восстановления пакетов в пределах этого окна зависит от времени между пересылками (рисунок 4). С помощью параметра RTT окно задержки определяет, что подлежит восстановлению или сколько раз пакет может быть восстановлен. RTT — это время, затраченное на отправку сигнала, плюс время, которое требуется для подтверждения, что сигнал был получен. Теперь давайте посмотрим, что происходит, когда пакет не получен (пакет №4 в этом примере).
Поскольку окно задержки перемещается, предполагается, что этот пакет готов к передаче, но если он недоступен, то он оказывается пропущен (рисунок 5). Он не может быть восстановлен, поэтому будет удален из списка утерянных.
Скользящее окно можно рассматривать как зону, в которой приемник может восстанавливать (большинство) пакетов.
С другой стороны, буфер отправителя также имеет такое окно. С течением времени самые старые пакеты, которые выходят за пределы окна задержки, больше не подлежат восстановлению — даже если их каким-то образом отправят, они прибудут слишком поздно, чтобы быть успешно обработанными получателем.
Если скользящее окно задержки переместилось за пределы пакетов, которые еще не были доставлены (получение не было подтверждено), отправлять их нет смысла. Таким образом, эти пакеты могут быть удалены из буфера отправки.
Режимы caller, listener и rendezvous Как и его предшественник UDT, SRT поддерживает две конфигурации подключения:
- Caller-Listener, где одна сторона ждёт, пока другая инициирует соединение. Вызывающая сторона (caller) - это клиент, которому потребуется адрес получателя (listener), и он попытается подключиться при инициализации.
- Rendezvous, когда обе стороны пытаются установить соединение.
| Режим | Что делает | Когда использовать |
|---|---|---|
| Caller | Устанавливает источник или приемник в качестве инициатора подключения SRT. Источник должен знать публичный IP-адреси номер порта приемника. | Чтобы инициировать потоковую передачу "точка-точка":на источнике или приемнике, которые находятся за брандмауэром: может потребоваться, чтобы сетевой администратор настроил параметры брандмауэрана источнике или приемнике, которые не находятся за брандмауэромна источнике или приемнике с динамическим IP-адресом (например, портативный кодировщик, использующий DHCP). |
| Listener | Настраивает устройство на ожидание запроса на открытие SRT-соединения | Чтобы принять соединение "точка-точка", инициированное вызывающим абонентом:на источнике или приемнике, которые находятся за брандмауэром, у которого вы можете открыть порт.на источнике или приемнике, которые не находятся за брандмауэром и не подключены к Интернету.когда вы знаете, что другое устройство инициирует сеанс |
| Rendezvous | Позволяет двум устройствам согласовывать подключение SRT по взаимно согласованному порту. И источник, и пункт назначения должны находиться в режиме рандеву. | Для установления соединения "точка-точка", когда одно или оба устройства находятся за брандмауэрами. Как только на брандмауэре установлены определенные настройки, SRT-соединение может быть инициированобез дальнейшего вмешательства сетевогоадминистратора. Это работает это при проброшенных портах и наличии белых IP при работе через фаерволы и интернет |
SRT и Firewall
Часто при передаче потока через Интернет, данные должны проходить через брандмауэр со стороны источника или на стороне получателя или на обоих концах сразу. Чтобы разрешить это, сетевому администратору придется настроить определенные параметры брандмауэра: (NAT) и фильтрацию пакетов. Настройки будут отличаться в зависимости от того, в каком режиме (caller, listener, rendezvous) находятся устройства.
Пример 1: Простой поток SRT
Рассмотрим простой пример, когда устройство-источник пытается передавать поток через Интернет в пункт назначения, находящийся за брандмауэром. Если мы рассмотрим случай, когда исходное устройство SRT находится в режиме вызывающего (caller), а устройство назначения - в режиме прослушивателя (listener), то для успешного завершения процесса установления связи должны быть выполнены определенные условия:
- Исходное устройство SRT знает общедоступный IP-адрес брандмауэра и номер порта, который “прослушивает” устройство назначения.
- Брандмауэр должен разрешать доступ из Интернета определенному порту назначения, используемому SRT.
- Брандмауэр должен разрешать двунаправленный UDP-трафик.
- На брандмауэре должна быть включена переадресация портов, чтобы данные дошли до устройства назначения.
- Фильтрация пакетов должна быть отключена (чтобы разрешить прохождение пакетов SRT).
Пример 2: Поток SRT через брандмауэры
Рассмотрим более сложный пример, когда устройство-источник SRT за брандмауэром пытается передавать поток через Интернет к устройству назначения, находящемуся также за брандмауэром. Если мы рассмотрим случай, когда источник потока SRT находится в режиме вызывающего (caller), а устройство назначения - в режиме прослушивателя (listener), то должны быть выполнены определенные условия:
- Исходное устройство SRT знает общедоступный IP-адрес брандмауэра и номер порта, который “прослушивает” устройство назначения.
- Оба брандмауэра должны разрешать двунаправленный UDP-трафик.
- Переадресация портов (NAT) должна быть настроена на обоих брандмауэрах, чтобы обеспечить передачу данных между исходным и конечным устройствами.
- Фильтрация пакетов должна быть настроена на обоих брандмауэрах.
Получение потока
Для демонстрации получения SRT-потока воспользуемся VLC и кодером, поддерживающим данный протокол. На странице веб-интерфейса кодера нужно найти раздел с SRT. Далее включим эту функцию, выберем режим listener и в поле IP запишем свой локальный адрес. В режиме “слушателя” нам не надо указывать IP-адрес приемника, поскольку сам приемник будет “звонить” на наш адрес. Остальные поля без надобности заполнять не стоит.
В VLC откроем сетевой ресурс:
И вставим ссылку (srt://172.18.191.51:9001?mode=caller) с указанием режима соединения. Данный локальный IP-адрес и порт (заранее прописанный в веб-интерфейсе) принадлежит кодеру. После этого должен появиться поток ("No signal" -- это видеопоток от кодера, когда на него не подается входной HDMI сигнал).:
Вложения
- image-10-2.png
- image-10.png
- image-11-2.png
- image-11.png
- image-12-2.png
- image-12.png
- image-13.png
- image-14.png
- image-15.png
- image-2-2.png
- image-2-3.png
- image-2-4.png
- image-2-5.png
- image-2.png
- image-3-2.png
- image-3-3.png
- image-3-4.png
- image-3.png
- image-4-2.png
- image-4-3.png
- image-4.png
- image-5-2.png
- image-5.png
- image-6-2.png
- image-6.png
- image-7-2.png
- image-7.png
- image-8-2.png
- image-9-2.png
- image-9.png
- image.png