Доброго времени суток
Сегодня я расскажу о замечательном протоколе вещания RTMFP. В нём реализовано много интересных подходов и бытует очень много предрассудков относительно его возможностей. Хочу подогреть интерес к этой теме и развеять существующие иллюзии. Я не нашёл ничего лучше для вещания в реальном времени, и решил написать этот пост.
Предыстория
Давным-давно в далёкой галактике...
В 2004'ом жила-была Amicima, Inc. в которой были разработана GPL реализация протокола MFP — MFPNet. Потом они выпустили amiciPhone — одного из конкурентов Skype, но из-за проблем позиционирования дела пошли не очень хорошо. В 2007'ом их приобрели Adobe так как им нужен был хороший протокол вещания реального времени.
А что не так с RTMP ?
RTMP не является протоколом вещания реального времени:
- не решается проблема минимизации задержек;
- вещание прекращается при смене адреса устройства;
- TCP значительно увеличивает задержки и раздувает сообщения ненужными проверками доставки;
- нет контроля размера окна.
Учитывая скорость развития мобильных сетей, покупка Amicima была довольно логичным и перспективным решением.
Предрассудки по поводу RTMFP
-
Это проприетарный протокол
Adobe решила его опубликовать в виде RFC7016 для того, чтобы подогреть внимание общественности, но как-то обошлось. Как ни странно, это не похоже на
кривуюспецификацию RTMP и больше напоминает MFP.Сам по себе протокол модульный: обмен сертификатами, шифрование, синхронизация потоков выполнены в виде отдельного профиля. То, что происходит в Flash'е, остаётся в Flash'e. Для разработчиков сторонних решений, типа Cumulus, Flash оставался чёрным ящикомl; как-то тихо и незаметно в апреле 2014-го вышел Adobe's RTMFP Profile for Flash Communication.
-
Это UDP — значит, нет гарантии доставки
Достаточно много протоколов реального времени используют UDP, для гарантии доставки добавляют сетевую контрольную сумму и избирательные проверки доставки. Проверяют только то, что обязательно должно прийти, а не всё в подряд. Для аудио/видео контроль доставки пакетов не имеет большего смысла. Размер окна (MTU) обычно максимален и статичен, что повышает вероятность возникновения ситуации проигрывания пустоты с последующим приёмом неактуальных данных при потере пакета.
-
RTMFP нам не нужен — у нас есть WebRTC
WebRTC это не протокол, это браузерная технология — попытка интегрировать SIP с RTP стэком в браузер. Если скрестить в кучу RTP, SRTP, SCTP, RTCP, ZRTP, RTSP — получится RTMFP. Но в ряде случаев у подобных связок есть избыточность и проблемы с адресацией которых нет в RTMFP.
У RTMFP есть и проброс через NAT, и контроль размера окна, и метаданные для потоков с контролем избыточности со стороны приложения, и forwarding/redirect сессий, и свой DHT.
Сколько нужно инкапсулировать RTP-подобных протоколов, чтобы это всё реализовать?.. Думаю, где-то 4-5 штук.
Текущая реализация протоколов вещания напоминает ситуацию:
«Существует 6 протоколов, но у них всех есть фатальный недостаток, и мы разработаем ещё один...»
Проходит год.
«Существует 7 протоколов, и у них всех есть фатальный недостаток...»RTMFP — это не попытка заменить существующие решения. Это попытка их генерализировать, избавится от избыточности и сделать доступными для пользователей.
RTMFP и модель OSI
Итак, давайте рассмотрим, какие уровни модели OSI покрывает RTMFP протокол.
-
Физический и канальный
Эфемерных энергетических флуктуаций от порхающих бабочек тут нет, а так хотелось бы избыточности посредством передачи данных в подпространствах варпа.
-
Сетевой и транспортный
Это IP и UDP multicast.
Тут и Path MTU discovery и Congestion Control, уже в коробке, для каждого конкретного потока. Есть режим передачи данных с выборочной частотой проверкой доставки — проверяем раз в N пакетов. Все пакеты имеют временные метки для замера задержки при доставке. Встроенная кольцевая хэш-адресация конечных точек типа DHT. -
Уровень представления
Для Flash это, конечно же, AMF3 и инкапсулированный RTMP, но передавать можно любые другие данные.
-
Прикладной уровень
Есть поддержка URI, сетевых групп и pub/sub по идентификаторам потоков. Подробнее можно почитать в документации API NetStream и NetGroup.
Безопасность в RTMFP
- Классический обмен ключами по Диффи-Хелману c статическими и эфемерными ключами.
- Cookies и сертификаты в сессиях, с возможностью цифровой подписи пакетов. Правда, по умолчанию неподписанные пакеты считаются валидными
- Для шифрования используется AES128, но можно использовать любой другой блочный алгоритм.
- HMAC-SHA256 или сетевые контрольные суммы.
Пользовательскую аутентификацию и авторизацию можно реализовать со стороны приложения. Вопрос фильтрации зловреда остаётся открытым.
Где функция-убийца ?
Я думаю, все помнят провал трансляции последней презентации нового поп-телефона IPhone 6 Plus?
Так вот представьте себе, что один клиент получает входящий поток и транслирует его ещё двум и больше (если возможно), и так — пока позволяет максимально возможная задержка. При этом в дереве клиентов происходят перестановки и сортировки в реальном времени с целью минимизации задержек и оптимизации окна пакета. В итоге можно добиться многократного уменьшения исходящего трафика сервера вещания.
И все его увидят…
Варианты использования
-
Вещание контента в реальном времени
Собственно, это предназначение самого протокола, и с этой задачей он справляется очень хорошо.
Его можно использовать не только для передачи аудио/видео, но и как основной транспорт в Flash играх. -
CDN
Это Р2Р и для загрузки файла нужно лишь знать его имя, хэш и размер.
Можно реализовать http2rtmfp шлюз — возможности открываются довольно занимательные. -
Видео-конференции и чаты
В пост-сноуденовскую эпоху RTMFP — доступный и защищённый Р2Р транспорт. Также основным преимуществом является возможность продолжить вещание при смене сетевого адреса устройства. WebRTC может отвалится при смене соты в 3G/4G. RTP стэк плохо подходит для вещания в подобной среде.
-
Передача данных реального времени внутри приватных сетей
Основным преимуществом для данного варианта использования является возможность гибкой политики маршрутизации, минимизации задержек, опциональной проверки доставки пакетов и встроенные средства приоритезации трафика. Всё это можно настроить индивидуально для каждого конкретного приложения.
Как обстоят дела с существующими решениями на базе RTMFP?
Если кратко — дела обстоят очень плохо. На сегодняшний день из открытых реализаций есть разве что Cumulus. Развивается он очень вяло. Основан не на RFC, а на первых реверсах RTMFP Cirrus 1, так что совместимость с текущим Flash Profile Cirrus 2 довольно сомнительна. В нём реализована большая часть полезностей, в том числе организация избыточности в Р2Р и вещание между устройствами. Есть FMS, но он работает как FMS…
Буду рад конструктивным замечаниям.
В комментариях прошу указать аналоги RTMFP, если вам они известны.
Автор: voidnugget
