かつての夢Flashサイトを想う。。

News!
Check!
遡ること20XX年、私はFlash職人になって食っていこうと本気で考えてました。そう、あの日までは…

RTMFPとRTMP

Real Time Media Flow Protocolとは

P2P の確立にはUDPホールパンチングを利用しており、ファイアウォール等により、UDPホールパンチングが失敗する場合は、P2P 通信は利用できません。

RTMFP を使うと、ソーシャルネットワークやマルチユーザーゲーム等の、ライブ・リアルタイムコミュニケーションを利用しているアプリケーションはより高品質なコミュニケーションを提供できます。RTMFP はエンドユーザー間を直接つなぎ、それぞれのコンピュータのマイクとカメラで直接通信ができます。

サーバー側は Adobe Flash Media Server が対応。UDPポート番号1935および19350〜65535。

Real Time Media Flow Protocol (RTMFP) は Adobe が開発しているプロトコル。RTMFP は低レイテンシの UDP ストリーミングや複数の Adobe Flash プレーヤー間の P2P 通信を可能にし、リッチなライブのリアルタイムコミュニケーションを可能にします。Flash Player 10.0 から利用可能。

話題のflashゲーム

RTMPとRTMFPの違い

主要違いは、それぞれのプロトコルがどのネットワークを使うかにあります。RTMFP は User Datagram Protocol (UDP) を利用するのに対して、RTMP は Transmission Control Protocol (TCP) を利用します。ライブストリーミングメディアを配信する時、レイテンシやオーバーヘッドを減らしたり、信頼性を犠牲にしてもパケット損失により大きな耐性がある等、UDP を利用するプロトコルはTCP を利用するプロトコルに比べて複数のの利点があります。無線インターネット接続等、パケットロスの多い通信環境では、TCP を利用すると再送のためレイテンシが大きくなります。

サーバーからの UDP ユニキャストにも使えるが、RTMPとは異なり、RTMFP はデータをサーバーを経由せずに直接他の Adobe Flash プレーヤーに送ることもできます。ただし、最初の P2P コネクションを確立するために、サーバーサイドの接続は必ず必要になります。

UDP であるにもかかわらず、TCP のような信頼性のある通信にも Flash Player 10.1 から対応しており、クライアント側の flash.net.NetStream の dataReliable 等で設定します。

アプリケーションレベルマルチキャスト

Flash Player 10.0 までの P2P は機能としては、1対1の通信のみでしたが、10.1 からアプリケーションレベルでマルチキャストが行えるようになりました。Flash Player 側で適切な配信経路(オーバーレイ・ネットワーク)を見つけ出し、P2P でつながったグループ全体に配信できるようになりました。

Real Time Messaging Protocolとは

Real Time Messaging Protocol (RTMP) とは、Adobe が開発している、Adobe Flash プレーヤーとサーバーの間で、音声・動画・データをやりとりするストリーミングのプロトコル。元々は Macromedia が開発していて、Adobe に買収されました。プロトコルの仕様は公開されています。

RTMP プロトコルは多数の変種があります。

1、RTMP (素のプロトコル) - TCP 上で動き、デフォルトのポート番号は1935

2、RTMPS - HTTPS を使い、SSL で暗号化されましたプロトコル

3、RTMPE - Adobe の独自のセキュリティ機構で暗号化されました RTMP。詳細な仕組みは非公開だが、業界標準の暗号を使っています。

4、RTMPT - HTTP で包んだ物。RTMP, RTMPS, RMPTE を入れてることができます。

RTMP の主要な利用法は Flash Video を再生することだが、Adobe LiveCycle Data Services ES 等、他のアプリケーションにも使われています。

RTMP (RTMFP を除く) は TCP 上のプロトコルで、持続的接続を使い、(HTTPとの比較で)低レイテンシ通信を実現します。ストリームをスムーズに配信し、できるだけ多くの情報を送れるようにするために、ストリームをフラグメントに分割し、そのサイズはクライアントとサーバーの間で動的に交渉します。デフォルトのフラグメントサイズは音声は64バイト、動画とその他のデータタイプは128バイトです。複数のストリームのフラグメントは、インターリーブされ、単一の接続上に多重化されます。データチャンクが豊富大きく、フラグメントのヘッダーは1バイトしかないので、オーバーヘッドは小さいです。しかしながら、実節は、個々のフラグメントは典型的にはインターリーブされありません。代わりに、インターリーブと多重化はパケットレベルで行われ、複数のアクティブなチャンネルが、それぞれの帯域、レイテンシ、Quality of Service が要求を満たすように RTMP パケットが作られます。このようにパケットがインタリーブされるときは、独立に扱われ、フラグメントレベルではインタリーブされありません。

RTMP は複数のチャンネルを定義していて、それの上でパケットが送受信され、それぞれは独立に動く。例えば、RPC リクエストとレスポンスを扱うチャンネル、動画ストリームを扱うチャンネル、オーディオストリームを扱うチャンネル、帯域外コントロールメッセージ (フラグメントサイズ交渉等) を扱うチャンネル等があります。典型的な RTMP のセッションの間では、複数のチャンネルは同時にアクティブになります。RTMP データがエンコードされるとき、パケットヘッダーが生成されます。パケットヘッダーは、送信するチャンネルのID、必要なら生成されました時刻のタイムスタンプ、パケットペイロードの大きさ等を含みました。このヘッダーの後に、実節のペイロード内容が通じます。これは、今のフラグメントサイズに基づき送信される前に分割されます。パケットヘッダー自らは決して分割されることはなく、パケットの最初のフラグメントのデータのサイズに含まれありません。別の言い方をすると、実節のパケットペイロード(メディアデータ)だけが、分割の対象となります。

より上のレイヤーでは、RTMP は MP3 や AAC や Flash Video を含み、Action Message Format を使いリモートプロシージャコールができます。全てのリモートプロシージャコールサービスは非同期で扱われ、単一のクライアントサーバーリクエストレスポンスモデルが使われ、リアルタイム通信は必要とされありません。

今、あえてのflash