Протокол обмена сообщениями в реальном времени

Эта статья включает в себя список общих ссылок , но он остается в значительной степени непроверенным, поскольку в нем недостаточно соответствующих встроенных ссылок . Пожалуйста, помогите улучшить эту статью, добавив более точные цитаты. ( август 2014 г. ) ( узнайте, как и когда удалять это шаблонное сообщение )

Протокол обмена сообщениями в реальном времени ( RTMP ) — это протокол связи для потоковой передачи аудио, видео и данных через Интернет. Первоначально разработанный Macromedia как частный протокол для потоковой передачи между Flash Player и сервером, Adobe (которая приобрела Macromedia) выпустила неполную версию спецификации протокола для общего пользования.

Протокол RTMP имеет несколько вариантов:

1. Собственно RTMP, «простой» протокол, который работает поверх протокола управления передачей (TCP) и по умолчанию использует номер порта 1935.
2. RTMPS, то есть RTMP через соединение Transport Layer Security (TLS/SSL).
3. RTMPE, который зашифрован RTMP с использованием собственного механизма безопасности Adobe. Хотя детали реализации являются собственностью, механизм использует стандартные криптографические примитивы. ^[1]
4. RTMPT, который инкапсулируется в HTTP -запросы для обхода брандмауэров. RTMPT часто использует незашифрованные запросы на TCP - портах 80 и 443 для обхода большей части фильтрации корпоративного трафика. Инкапсулированный сеанс может содержать простые пакеты RTMP, RTMPS или RTMPE.
5. RTMFP, который представляет собой RTMP по протоколу пользовательских дейтаграмм (UDP) вместо TCP, заменяющий RTMP Chunk Stream. Пакет Secure Real-Time Media Flow Protocol был разработан Adobe Systems и позволяет конечным пользователям подключаться и общаться друг с другом напрямую (P2P).

Хотя основной мотивацией для RTMP был протокол для воспроизведения Flash-видео , он также используется в некоторых других приложениях, таких как Adobe LiveCycle Data Services ES .

Основная операция

RTMP — это протокол на основе TCP, который поддерживает постоянные соединения и обеспечивает связь с малой задержкой. Для бесперебойной доставки потоков и передачи как можно большего количества информации он разбивает потоки на фрагменты, а их размер динамически согласовывается между клиентом и сервером. Иногда его оставляют без изменений; размер фрагмента по умолчанию составляет 64 байта для аудиоданных и 128 байтов для видеоданных и большинства других типов данных. Затем фрагменты из разных потоков могут чередоваться и мультиплексироваться по одному соединению. Таким образом, с более длинными фрагментами данных протокол содержит только однобайтовый заголовок на фрагмент, что приводит к очень небольшим накладным расходам.. Однако на практике отдельные фрагменты обычно не чередуются. Вместо этого чередование и мультиплексирование выполняются на уровне пакетов, при этом пакеты RTMP по нескольким различным активным каналам чередуются таким образом, чтобы гарантировать, что каждый канал соответствует своей пропускной способности, задержке и другим требованиям к качеству обслуживания. Пакеты, чередующиеся таким образом, рассматриваются как неделимые и не чередуются на уровне фрагментов.

RTMP определяет несколько виртуальных каналов, по которым могут отправляться и приниматься пакеты и которые работают независимо друг от друга. Например, есть канал для обработки запросов и ответов RPC, канал для данных видеопотока, канал для данных аудиопотока, канал для внеполосных управляющих сообщений (согласование размера фрагмента и т. д.) и т. д. . Во время типичного сеанса RTMP несколько каналов могут быть активны одновременно в любой момент времени. При кодировании данных RTMP генерируется заголовок пакета. В заголовке пакета указывается, среди прочего, идентификатор канала, по которому он должен быть отправлен, отметка времени его создания (при необходимости) и размер полезной нагрузки пакета. Затем за этим заголовком следует фактическое содержимое полезной нагрузки пакета,который фрагментируется в соответствии с согласованным в настоящее время размером фрагмента перед отправкой по соединению. Сам заголовок пакета никогда не фрагментируется, и его размер не учитывается в данных в первом фрагменте пакета. Другими словами, фрагментации подлежит только фактическая полезная нагрузка пакета (данные мультимедиа).

На более высоком уровне RTMP инкапсулирует аудиопотоки MP3 или AAC и мультимедийные видеопотоки FLV1 и может выполнять удаленные вызовы процедур (RPC) с использованием формата сообщения действия . Любые требуемые службы RPC выполняются асинхронно, с использованием единой модели запроса/ответа клиент/сервер, поэтому связь в реальном времени не требуется. ^{[ требуется уточнение ] [2] [3]}

Шифрование

Сеансы RTMP могут быть зашифрованы одним из двух способов:

• Использование стандартных механизмов TLS/SSL . Базовый сеанс RTMP просто заключен в обычный сеанс TLS/SSL.
• Использование RTMPE, который заключает сеанс RTMP в более легкий уровень шифрования.

HTTP-туннелирование

В RTMP Tunneled (RTMPT) данные RTMP инкапсулируются и передаются через HTTP , а сообщения от клиента (в данном случае медиаплеера) адресуются на порт 80 (по умолчанию для HTTP) на сервере.

Хотя сообщения в RTMPT больше, чем эквивалентные нетуннелируемые RTMP-сообщения из-за заголовков HTTP, RTMPT может облегчить использование RTMP в сценариях, где использование нетуннелируемого RTMP в противном случае было бы невозможно, например, когда клиент отстает. брандмауэр , который блокирует исходящий трафик не-HTTP и не-HTTPS.

Протокол работает, отправляя команды через URL-адрес POST и сообщения AMF через тело POST. Примером является

ПОСТ/открыть/1 HTTP/1.1

для открытия соединения.

Спецификация и патентная лицензия

Adobe выпустила спецификацию для версии 1.0 протокола от 21 декабря 2012 г. ^[4] На целевой веб-странице, ведущей к этой спецификации, отмечается, что «для удобства клиентов, которые хотят защитить свой контент, спецификация открытого RTMP не включает уникальную безопасные меры RTMP». ^[5]

Документ, сопровождающий спецификацию Adobe, предоставляет «неисключительную, безвозмездную, непередаваемую, не подлежащую сублицензированию, личную, всемирную» патентную лицензию на все реализации протокола с двумя ограничениями: одно запрещает использование для перехвата потоковых данных («любая технология который перехватывает потоковое видео, аудио и/или данные для хранения на любом устройстве или носителе»), а другой запрещает обход «технологических мер по защите аудио, видео и/или данных, включая любые меры безопасности Adobe RTMP». . ^[6]

Патенты и связанные с ними судебные процессы

Стефан Рихтер, автор нескольких книг по Flash , в 2008 году отметил, что, хотя Adobe не имеет четкого представления о том, какие патенты применяются к RTMP, патент США 7 246 356 , по- видимому, является одним из них. ^[2]

В 2011 году Adobe подала в суд на Wowza Media Systems, утверждая, среди прочего, о нарушении их патентов RTMP. ^{[7] [8] [9]} В 2015 году Adobe и Wowza объявили, что судебные иски были урегулированы и отклонены с предубеждением. ^[10]

Структура пакета

Пакеты отправляются через TCP-соединение, которое сначала устанавливается между клиентом и сервером. Они содержат заголовок и тело, которое в случае команд подключения и управления кодируется с использованием формата сообщения действия (AMF). Заголовок разделен на основной заголовок (показан отдельно от остальных на диаграмме) и заголовок фрагмента сообщения . Основной заголовок является единственной постоянной частью пакета и обычно состоит из одного составного байта, где два самых значащих бита представляют собой тип фрагмента ( fmtв спецификации), а остальные формируют идентификатор потока. В зависимости от значения первого некоторые поля заголовка сообщения могут быть опущены, а их значение получено из предыдущих пакетов, в то время как в зависимости от значения последнего базовый заголовок может быть расширен одним или двумя дополнительными байтами (как в случай диаграммы, которая имеет всего три байта (c)). Если значение оставшихся шести битов базового заголовка(BH) (наименее значащий) равен 0, тогда BH составляет два байта и представляет идентификатор потока от 64 до 319 (64+255); если значение равно 1, то BH составляет три байта (с последними двумя байтами, закодированными как 16-битный Little Endian) и представляет идентификатор потока от 64 до 65599 (64+65535); если значение равно 2, то BH представляет собой один байт и зарезервирован для низкоуровневых управляющих сообщений и команд протокола. Заголовок фрагмента сообщения содержит метаданные, такие как размер сообщения (измеряемый в байтах), дельту временной метки и тип сообщения . Это последнее значение представляет собой один байт и определяет, является ли пакет аудио, видео, командой или «низкоуровневым» пакетом RTMP, таким как RTMP Ping.

Ниже показан пример, когда флэш-клиент выполняет следующий код:

var  stream : NetStream  =  новый  NetStream ( connectionObject );

это создаст следующий фрагмент:

Пакет начинается с базового заголовка из одного байта (0x03), где два старших бита (b 00 000011) определяют тип заголовка фрагмента, равный 0, а остальные (b00 000011 ) определяют идентификатор потока фрагмента, равный 3. Четыре возможных варианта значения типа заголовка и их значение:

• b00 = 12-байтовый заголовок (полный заголовок).
• b01 = 8 байт - аналогично типу b00, не включая идентификатор сообщения (4 последних байта).
• b10 = 4 байта — включены основной заголовок и метка времени (3 байта).
• b11 = 1 байт — включен только основной заголовок.

Последний тип (b11) всегда используется в случае агрегированных сообщений, где в приведенном выше примере второе сообщение будет начинаться с идентификатора 0xC3 (b11000011) и будет означать, что все поля заголовка сообщения должны быть получены из сообщения с идентификатор потока 3 (который будет сообщением прямо над ним). Шесть младших значащих битов, формирующих идентификатор потока, могут принимать значения от 3 до 63. Некоторые значения имеют особое значение, например 1, обозначающий расширенный формат идентификатора, и в этом случае за ним следуют два байта. Значение два предназначено для сообщений низкого уровня, таких как Ping и Set Client Bandwidth.

Следующие байты заголовка RTMP (включая значения в приведенном выше примере пакета) декодируются следующим образом:

• байт #1 (0x03) = тип заголовка блока.
• байт #2-4 (0x000b68) = дельта метки времени.
• байт #5-7 (0x000019) = длина пакета — в данном случае это 0x000019 = 25 байт.
• байт #8 (0x14) = идентификатор типа сообщения - 0x14 (20) определяет командное сообщение в кодировке AMF0.
• байт #9-12 (0x00000000) = идентификатор потока сообщений. Это в обратном порядке.

Байт идентификатора типа сообщения определяет, содержит ли пакет аудио/видеоданные, удаленный объект или команду. Некоторые возможные значения для:

• 0x01 = установить сообщение о размере пакета.
• 0x02 = Прервать.
• 0x03 = Подтвердить.
• 0x04 = управляющее сообщение.
• 0x05 = пропускная способность сервера
• 0x06 = пропускная способность клиента.
• 0x07 = виртуальный контроль.
• 0x08 = Аудиопакет.
• 0x09 = видеопакет.
• 0x0F = расширенные данные.
• 0x10 = Расширенный контейнер.
• 0x11 = расширенная команда (команда типа AMF3).
• 0x12 = Data (Invoke (информация onMetaData отправляется как таковая)).
• 0x13 = Контейнер.
• 0x14 = Команда (команда типа AMF0).
• 0x15 = UDP
• 0x16 = Совокупность
• 0x17 = присутствует

После заголовка 0x02 обозначает строку размером 0x000C и значениями 0x63 0x72 ... 0x6D (команда "createStream"). После этого у нас есть 0x00 (число), которое является идентификатором транзакции со значением 2.0. Последний байт равен 0x05 (нулевой), что означает отсутствие аргументов.

Структура сообщения вызова (0x14, 0x11)

Некоторые из показанных выше типов сообщений, такие как Ping и Set Client/Server Bandwidth, считаются сообщениями протокола RTMP низкого уровня, которые не используют формат кодирования AMF. Командные сообщения, с другой стороны, будь то AMF0 (тип сообщения 0x14) или AMF3 (0x11), используют формат и имеют общую форму, показанную ниже:

(Строка) <Имя команды>
(Число) <Идентификатор транзакции>
(Смешанный) <Аргумент> напр. Null, String, Object: {ключ1:значение1, ключ2:значение2...}

Идентификатор транзакции используется для команд, которые могут иметь ответ. Значение может быть либо строкой, как в приведенном выше примере, либо одним или несколькими объектами, каждый из которых состоит из набора пар ключ/значение, где ключи всегда кодируются как строки, а значения могут быть любым типом данных AMF, включая сложные типы, такие как массивы.

Структура управляющего сообщения (0x04)

Сообщения управления не кодируются в формате AMF. Они начинаются с идентификатора потока 0x02, что подразумевает полный (тип 0) заголовок и тип сообщения 0x04. За заголовком следуют шесть байтов, которые интерпретируются следующим образом:

• #0-1 - Тип управления.
• #2-3 - Второй параметр (имеет значение в определенных типах управления)
• #4-5 — Третий параметр (то же самое)

Первые два байта тела сообщения определяют тип Ping, который, по-видимому, ^[11] может принимать шесть возможных значений.

• Тип 0 — Clear Stream: отправляется, когда соединение установлено и не несет никаких дополнительных данных.
• Тип 1 - очистить буфер.
• Тип 2 - Поток Сухой.
• Тип 3 - буферное время клиента. Третий параметр содержит значение в миллисекундах.
• Тип 4 - Сбросить поток.
• Тип 6 - пропинговать клиента с сервера. Второй параметр — текущее время.
• Тип 7 — ответ Pong от клиента. Второй параметр — это время, когда клиент получает Ping.
• Тип 8 — UDP-запрос.
• Тип 9 — ответ UDP.
• Тип 10 - Ограничение пропускной способности.
• Тип 11 - пропускная способность.
• Тип 12 - Ширина полосы дроссельной заслонки.
• Тип 13 - Поток создан.
• Тип 14 - Поток удален.
• Введите 15 - Установить доступ для чтения.
• Введите 16 — установите доступ для записи.
• Тип 17 - Метазапрос потока.
• Тип 18 — поток метаответа.
• Введите 19 — Получить границу сегмента.
• Введите 20 - Установить границу сегмента.
• Тип 21 — при отключении.
• Введите 22 - Установить критическую ссылку.
• Тип 23 - Отключить.
• Тип 24 - Обновление хеша.
• Тип 25 - Тайм-аут хеширования.
• Тип 26 - Хэш-запрос.
• Тип 27 - Хэш-ответ.
• Введите 28 — проверьте пропускную способность.
• Введите 29 — установите доступ к аудиосемплам.
• Введите 30 - Установить доступ к видеосэмплу.
• Тип 31 - Начало дроссельной заслонки.
• Тип 32 - Дроссельная заслонка.
• Тип 33 - Уведомление DRM.
• Тип 34 — RTMFP-синхронизация.
• Тип 35 - Запрос IHello.
• Тип 36 - Вперед Привет.
• Тип 37 - перенаправить IHello.
• Введите 38 — уведомить EOF.
• Введите 39 — Продолжить через прокси.
• Введите 40 — Удалить прокси вверх по течению.
• Тип 41 - RTMFP Set Keepalives.
• Тип 46 - Сегмент не найден.

Pong — это имя для ответа на Ping со значениями, используемыми, как показано выше.

Структура сообщения ServerBw/ClientBw (0x05, 0x06)

Это относится к сообщениям, которые имеют отношение к восходящему потоку клиента и нисходящему потоку от сервера. Тело состоит из четырех байтов, показывающих значение пропускной способности, с возможным расширением в один байт, который устанавливает тип ограничения. Это может иметь одно из трех возможных значений: жесткое, мягкое или динамическое (мягкое или жесткое).

Установить размер фрагмента (0x01)

Значение получено в четырех байтах тела. По умолчанию существует значение 128 байт, и сообщение отправляется только тогда, когда требуется изменение.

Протокол

Рукопожатие

После установления TCP-соединения сначала устанавливается RTMP-соединение, выполняя рукопожатие посредством обмена тремя пакетами с каждой стороны (также именуемые в официальной документации Chunks). В официальной спецификации они обозначаются как C0-2 для пакетов, отправленных клиентом, и S0-2 для серверной стороны соответственно, и их не следует путать с пакетами RTMP, которыми можно обмениваться только после завершения рукопожатия. Эти пакеты имеют собственную структуру, а C1 содержит поле, устанавливающее временную метку «эпохи», но, поскольку она может быть установлена ​​равной нулю, как это делается в сторонних реализациях, пакет может быть упрощен. Клиент инициализирует соединение, отправляя пакет C0 с постоянным значением 0x03, представляющим текущую версию протокола.Он следует прямо с C1, не дожидаясь, пока S0 будет получен первым, который содержит 1536 байтов, причем первые четыре представляют отметку времени эпохи, вторые четыре все равны 0, а остальные являются случайными (и которые могут быть установлены на 0 в третьей стороне). реализации). C2 и S2 являются эхом S1 и C1 соответственно, за исключением того, что вторые четыре байта представляют собой время получения соответствующего сообщения (вместо 0). После получения C2 и S2 рукопожатие считается завершенным.После получения C2 и S2 рукопожатие считается завершенным.После получения C2 и S2 рукопожатие считается завершенным.

Соединять

На этом этапе клиент и сервер могут договориться о соединении, обменявшись закодированными сообщениями AMF. К ним относятся пары ключ-значение, которые относятся к переменным, необходимым для установления соединения. Пример сообщения от клиента:

( Invoke )  «connect» ( ID транзакции  ) 1.0 ( Object1 ) { app : «sample» , flashVer : «MAC 10,2,153,2» , swfUrl : null , tcUrl : «rtmpt://127.0.0.1/sample» , fpad : ложь , возможности : 9947,75 , аудиокодеки : 3191 , видеокодеки : 252 , видеофункция : 1 ,                       pageUrl :  null ,  objectEncoding :  3.0  }

Flash Media Server и другие реализации используют концепцию «приложения» для концептуального определения контейнера для аудио/видео и другого контента, реализованного в виде папки в корне сервера, которая содержит мультимедийные файлы для потоковой передачи. Первая переменная содержит имя этого приложения как «образец», которое является именем, предоставленным сервером Wowza для их тестирования. Строка flashVerтакая же, как и возвращаемая getversion()функцией Action-script. Символы audioCodecи videoCodecзакодированы как двойные , и их значение можно найти в исходной спецификации. То же самое верно и для videoFunctionпеременной, которая в данном случае является самоочевидной константой SUPPORT_VID_CLIENT_SEEK. Особый интерес представляетobjectEncodingкоторый определит, будет ли остальная часть связи использовать расширенный формат AMF3 или нет. Поскольку версия 3 является текущим значением по умолчанию, флэш-клиент должен быть явно указан в коде Action-script для использования AMF0, если это запрошено. Затем сервер отвечает последовательностью сообщений ServerBW, ClientBW и SetPacketSize, за которой, наконец, следует Invoke с примером сообщения.

( Вызов )  "_result" ( идентификатор транзакции  ) 1.0 ( Объект1 ) { fmsVer : "FMS/3,5,5,2004" , возможности : 31.0 , режим : 1.0 } ( Объект2 ) { уровень : "статус" , код : " NetConnection.Connect.Success" , описание : "Соединение установлено успешно" , данные : ( массив ) { версия :                     "3,5,5,2004"  },  clientId :  1728724019 ,  objectEncoding :  3.0  }

Некоторые приведенные выше значения сериализуются в свойства универсального объекта Action-script, который затем передается прослушивателю событий NetConnection. Будет clientIdустановлен номер для сеанса, который будет запущен соединением. Кодировка объекта должна соответствовать ранее установленному значению.

Проиграть видео

Чтобы запустить видеопоток, клиент отправляет вызов «createStream», за которым следует сообщение ping, а затем вызов «play» с именем файла в качестве аргумента. Затем сервер ответит серией команд «onStatus», за которыми следуют видеоданные, инкапсулированные в сообщениях RTMP.

После установления соединения мультимедийные данные отправляются путем инкапсуляции содержимого тегов FLV в сообщения RTMP типа 8 и 9 для аудио и видео соответственно.

HTTP-туннелирование (RTMPT)

Это относится к версии протокола с туннелированием HTTP. Он обменивается данными через порт 80 и передает данные AMF в запросах и ответах HTTP POST. Последовательность подключения следующая:

POST  /fcs/ident2  HTTP / 1.1 Content-Type :  application/x-fcs\r\nHTTP/1.0 404 Не найден

POST  /open/1  HTTP / 1.1 Content-Type :  application/x-fcs\r\nHTTP/1.1 200 ОК
Тип содержимого: приложение/x-fcs\r\n 1728724019

Первый запрос имеет /fcs/ident2путь, и правильный ответ — ошибка 404 Not Found. Затем клиент отправляет запрос /open/1, на который сервер должен ответить 200 ok, добавив случайное число, которое будет использоваться в качестве идентификатора сеанса для указанной связи. В этом примере в теле ответа возвращается 1728724019.

POST  /idle/1728724019/0  HTTP / 1.1 HTTP/1.1  200 ОК  0x01

Отныне /idle/<session id>/<sequence #>это запрос на опрос, в котором идентификатор сеанса был сгенерирован и возвращен с сервера, а последовательность — это просто число, которое увеличивается на единицу для каждого запроса. Соответствующим ответом является 200 OK с целым числом, возвращаемым в теле, обозначающим время интервала. Данные AMF передаются через/send/<session id>/<sequence #>

Реализации программного обеспечения

RTMP реализуется на этих трех этапах:

• Кодировщик живого видео
• Сервер потоковой передачи мультимедиа в прямом эфире и по запросу
• Живой клиент и клиент по запросу

rtmpdump

Инструмент командной строки клиента RTMP с открытым исходным кодом rtmpdump предназначен для воспроизведения или сохранения на диск полного потока RTMP, включая протокол RTMPE , который Adobe использует для шифрования. RTMPdump работает в Linux, Android, Solaris, Mac OS X и большинстве других операционных систем, производных от Unix, а также в Microsoft Windows. Первоначально поддерживая все версии 32-битной Windows, включая Windows 98, начиная с версии 2.2, программное обеспечение будет работать только в Windows XP и выше (хотя более ранние версии остаются полностью функциональными).

Пакеты программного обеспечения rtmpdump доступны в основных репозиториях с открытым исходным кодом (дистрибутивы Linux). К ним относятся интерфейсные приложения «rtmpdump», «rtmpsrv» и «rtmpsuck».

Разработка RTMPdump была возобновлена ​​в октябре 2009 года за пределами США на сайте MPlayer . ^[12] Текущая версия имеет значительно улучшенную функциональность и была переписана, чтобы использовать преимущества языка программирования C. В частности, основная функциональность была встроена в библиотеку (librtmp), которую можно легко использовать в других приложениях. Разработчики RTMPdump также написали поддержку librtmp для MPlayer , FFmpeg , XBMC , cURL , VLC.и ряд других проектов программного обеспечения с открытым исходным кодом. Использование librtmp обеспечивает этим проектам полную поддержку RTMP во всех его вариантах без каких-либо дополнительных усилий по разработке.

FLVстример

FLVstreamer — это форк RTMPdump без кода, который, по утверждению Adobe, нарушает DMCA в США. Это было разработано в ответ на попытку Adobe в 2008 году подавить RTMPdump. FLVstreamer — это RTMP-клиент, который сохраняет поток аудио- или видеоконтента с любого RTMP-сервера на диск, если для потока не включено шифрование (RTMPE).

Смотрите также

• Защищенная потоковая информация о RTMPS и RTMPE
• Видео по запросу (VoD)
• Расширения источников мультимедиа (MSE)
• Веб-сокет

использованная литература

внешняя ссылка

• Страница Adobe Developer — RTMP — официальная спецификация