良い一日
今日は素晴らしいRTMFPブロードキャストプロトコルについてお話します。 多くの興味深いアプローチを実装しており、その機能に関して多くの偏見があります。 このトピックへの関心を高め、既存の幻想を払拭したいと思います。 リアルタイム放送でこれ以上良いものは見つからなかったので、この投稿を書くことにしました。
背景
2004年、静脈はAmicima、Incでした。 GPLはMFPプロトコル-MFPNetの実装を開発しました 。 その後、彼らはSkypeのライバルの1つであるamiciPhoneをリリースしましたが 、ポジショニングの問題のためにうまくいきませんでした。 2007年、アドビは優れたリアルタイムブロードキャストプロトコルを必要としていたため、それらを取得しました。
RTMPの何が問題になっていますか？
RTMPはリアルタイムブロードキャストプロトコルではありません。
- 遅延を最小化する問題は解決されません。
- デバイスアドレスが変更されると、ブロードキャストは停止します。
- TCPは遅延を大幅に増加させ、不必要な配信チェックでメッセージを増大させます。
- ウィンドウサイズの制御なし。
モバイルネットワークの開発速度を考えると、Amicimaの購入はかなり論理的で有望なソリューションでした。
RTMFPに対する偏見
これは独自のプロトコルです。
アドビは、人々の注目を集めるためにRFC7016の形式で公開することを決定しましたが、どういうわけかうまくいきました。 奇妙なことに、これは湾曲したRTMP仕様のようには見えず、MFPのように見えます。
プロトコル自体はモジュール式です。証明書交換、暗号化、スレッド同期は個別のプロファイルとして実行されます。 Flashで起こることはFlashに残ります。 Cumulusなどのサードパーティソリューションの開発者にとって、Flashはブラックボックスのままでした。 どういうわけか、2014年4月に静かに、静かに、Flash通信用のAdobeのRTMFPプロファイルがリリースされました 。
これはUDPです。つまり、配信の保証はありません。
かなり多くのリアルタイムプロトコルがUDPを使用しており、配信を確実にするために、ネットワークチェックサムと選択的配信チェックを追加します。 彼らは来るものだけをチェックし、すべてを連続してチェックするのではありません。 オーディオ/ビデオの場合、パケット配信制御はあまり意味がありません。 ウィンドウサイズ（MTU）は通常最大で静的であり、パケット損失が発生した場合に関連性のないデータを受信すると、ボイドが発生する可能性が高くなります。
RTMFPは必要ありません-WebRTCがあります
WebRTCはプロトコルではなく、ブラウザテクノロジーです。SIPをRTPスタックとブラウザに統合する試みです。 RTP、SRTP、SCTP、RTCP、ZRTP、RTSPを交差させて束にすると、RTMFPが得られます。 しかし、場合によっては、そのようなバンドルにはRTMFPには存在しない冗長性とアドレス指定の問題があります。
RTMFPには、NATを介した転送、ウィンドウサイズ制御、アプリケーション側からの冗長制御を備えたフローのメタデータ、転送/リダイレクトセッション、および独自のDHTがあります。
これをすべて実装するためにRTPのようなプロトコルをカプセル化するのにどれくらい時間がかかりますか？.. 4-5個のどこかにあると思います。
ブロードキャストプロトコルの現在の実装は、状況に似ています。
「6つのプロトコルがありますが、それらにはすべて致命的な欠陥があり、別のプロトコルを開発します...」
1年が経ちました。
「7つのプロトコルがあり、それらにはすべて致命的な欠陥があります...」
RTMFPは、既存のソリューションを置き換えるものではありません。 これは、それらを一般化し、冗長性を取り除き、ユーザーが利用できるようにする試みです。
RTMFPおよびOSIモデル
それでは、RTMFPプロトコルがカバーするOSIモデルのレベルを見てみましょう。
物理的およびチャネル
ここでは蝶の羽ばたきによる一時的なエネルギーの変動はありません。ワープ部分空間でデータを送信することで冗長性が欲しいです。
ネットワークと輸送
これらはIPおよびUDPマルチキャストです。
ここでは、特定のストリームごとに、既にボックス内にあるパスMTUディスカバリーおよび輻輳制御。 配信をチェックすることにより、選択的な頻度でデータ転送モードがあります-Nパケットで1回チェックします。 すべてのパッケージには、配達遅延を測定するためのタイムスタンプがあります。 DHTなどのエンドポイントの組み込みリングハッシュアドレス指定。
プレゼンテーションレベル
Flashの場合、これはもちろんAMF3およびカプセル化されたRTMPですが、他のデータを転送できます。
アプリケーションレベル
ストリーム識別子によるURI、ネットワークグループ、pub / subのサポートがあります。 詳細については、 NetStreamおよびNetGroup APIのドキュメントをご覧ください。
RTMFPのセキュリティ
- 静的キーと一時キーを使用した従来のDiffie-Hellmanキー交換。
- セッションのCookieと証明書。パッケージにデジタル署名する可能性があります。 True、デフォルトでは、署名されていないパケットは有効と見なされます。
- AES128は暗号化に使用されますが、他のブロックアルゴリズムも使用できます。
- HMAC-SHA256またはネットワークチェックサム。
ユーザー認証と承認は、アプリケーションによって実装できます。 マルウェアフィルタリングの問題は未解決のままです。
キラー機能はどこにありますか？
新しいIPhone 6 Plus
したがって、1人のクライアントが着信ストリームを受信し、それをさらに2つ（可能であれば）にブロードキャストすることを想像してください。 同時に、遅延を最小限に抑え、パッケージウィンドウを最適化するために、クライアントツリーでリアルタイムの並べ替えと並べ替えが行われます。 その結果、ブロードキャストサーバーの発信トラフィックを複数削減することができます。
そして誰もが彼を見るでしょう...
ユースケース
ライブコンテンツ放送
実際、これはプロトコル自体の目的であり、このタスクに非常によく対処します。
オーディオ/ビデオの送信だけでなく、Flashゲームの主なトランスポートとしても使用できます。
CDN
これはP2Pであり、ファイルをダウンロードするには、ファイルの名前、ハッシュ、サイズを知るだけで済みます。
http2rtmfpゲートウェイを実装できます-可能性は非常に面白いです。
ビデオ会議とチャット
スノーデン後の時代では、RTMFPは手頃な価格で安全なP2Pトランスポートです。 また、主な利点は、デバイスのネットワークアドレスを変更してもブロードキャストを継続できることです。 3RT / 4Gでセルを変更すると、WebRTCが落ちる場合があります。 RTPスタックは、このような環境でのブロードキャストにはあまり適していません。
プライベートネットワーク内でのリアルタイムデータ転送
このユースケースの主な利点は、柔軟なルーティングポリシーを持ち、遅延を最小限に抑え、オプションでパケット配信を検証し、トラフィックの優先順位付けツールを内蔵していることです。 これらはすべて、特定のアプリケーションごとに個別に構成できます。
既存のRTMFPソリューションはどうですか？
要するに、物事は非常に悪いです。 今日、オープンな実装の中には、おそらくCumulusがあります。 非常に緩慢に発達します。 RFCに基づいていませんが、RTMFP Cirrus 1の最初の反転に基づいているため、現在のFlash Profile Cirrus 2との互換性はかなり疑わしいものです。 P2Pでの冗長性の編成やデバイス間のブロードキャストなど、ほとんどの有用性を実装しています。 FMSがありますが、FMSのように機能します...
建設的なコメントを歓迎します。
コメントで、RTMFPの類似物を知っている場合はそれを示してください。