1 協(xié)議介紹
Real-Time Media Flow Protocol(簡稱RTMFP)是Flash和Flash之間基于UDP的點對點傳輸協(xié)議，由Adobe公司在2008年在Flash 10.0中發(fā)布，隨后在Flash10.1中加入了Groups功能。
2 常見用法
rtmfp在Flash 10中的典型使用場景如下圖：
它有如下特點：
l 使用Cirrus或者開源的Cumulus來提供Rendezvous服務
l Cirrus或者Cumulus并不提供Peer ID的交換服務，需要提供其它的方式來交換客戶端之間的Peer ID
l Flash客戶端之間使用NetStream來做點對點傳輸，Publisher需要給每一個Subscriber單獨傳輸一份數(shù)據(jù)，這也限制集群的規(guī)模。
為了解決這個問題，Adobe在Flash 10.1中提出了Groups的概念，典型的架構如下：
它有如下特點：
l Cirrus或者開源的Cumulus提供Rendezvous服務并提供所有連接client列表
l client從Cirrus或者開源的Cumulus獲取鄰居節(jié)點之后，就可以組成一個完整的P2P架構，所有的audio、video和data數(shù)據(jù)都在peer之間交互。
3 協(xié)議解析
3.1 基本概念
l session：session是兩個UDP地址之間的雙向管道。
l flow：flow是從一個實體到另一個實體之間的邏輯路徑。一個session可以包括多個flow。
l packet：網(wǎng)絡中實際傳輸?shù)臄?shù)據(jù)，一個packet可以包含多個message。數(shù)據(jù)傳輸時都經(jīng)過了128 bit的AES加密
l message：audio、video和data數(shù)據(jù)。
3.2 Scrambled Session ID
rtmfp協(xié)議中每個包的格式如下：
packet := scrambled-session-id | encrypted-part
其中scrambled-session-id是4字節(jié)，其后是經(jīng)過AES加密的數(shù)據(jù)體。
scramble-session-id的生成規(guī)則如下：
scrambled-session-id = a ^ b ^ c
這里^代表XOR操作，a是session-id，b和c是encrypted-part的頭8個bytes。
當目標收到這個包后，unscramble的操作如下：
session-id = x ^ b ^ c
其中x是scrambled-session-id，b和c同上。
使用scramble-session-id的目的為了減少數(shù)據(jù)包流經(jīng)的NAT設備和layer-4 packet inspector對數(shù)據(jù)的干擾。
session-id用于標識通信雙方建立的連接，并確定通信時使用的加密和解密的key，這些key是通過DH key exchange算法獲得。但在session建立之前，雙方使用一個公有加密key，即128 bit的字符串”Adobe System 02”。
3.3 raw part
encrypted-part經(jīng)過解密之后就得到了raw-part，它的格式如下：
raw-part := checksum | network-layer-data | padding
其中checksum有16字節(jié)，network-layer-data是變長數(shù)據(jù)，padding都是0xFF，并把network-layer-data補齊為16字節(jié)的倍數(shù)，這是因為rtmfp使用的是16字節(jié)的加解密key。
checksum基于network-layer-data和padding計算。
3.4 network layer data
network-layer-data的格式如下：
network-layer-data = flags | timestamp | timestamp-echo | chunks
其中flags為1個字節(jié)，其格式如下：
7 6 5 4 3 2 1 0
TC TCR reserved reserved TS TSE mode
l mode：11代表握手包，01代表initiator發(fā)送包，10代表responder發(fā)送包，00不是合法值
l TSE：包中是否包含timestamp-echo域
l TS：包中是否包含timestamp域
l TCR：time critical reverse notification表明發(fā)送方正在從其它地方收到timecritical包
l TC：time critical forward notification表明發(fā)送方發(fā)送的是timecritical包
timestamp域有2字節(jié)，精度是4ms，他的計算方式如下：
timestamp = int(time * 1000 / 4) & 0xFFFF
timestamp-echo域是server收到包的時間戳，當發(fā)送放收到這個值之后，發(fā)送方就可以計算RTT值了。
chunk類型的格式如下：
chunk = type | size | payload
type字段為1個字節(jié)，其中0xFF不可用，這個是用來區(qū)分chunk數(shù)據(jù)和padding數(shù)據(jù)的標記。type的定義如下：
typemeaning
0x30initiator hello
0x70responder hello
0x38initiator initial keying
0x78responder initial keying
0x0fforwarded initiator hello
0x71forwarded hello response
0x10normal user data
0x11next user data
0x0csession failed on client side
0x4csession died
0x01reset keepalive request
0x41reset keepalive response
0x5enegative ack
0x51some ack
size是2字節(jié)payload長度。
payload根據(jù)type的不同有不同的數(shù)據(jù)體。
3.5 message flow
session中包括3類消息：
l handshake：握手包，包括initiator hello, responder hello, initiator initial keying,responder initial keying, responder hello cookie change和responderredirect
l control：控制包，包括ping, ping reply, rekeying initiate, rekeying response, close, closeacknowledge, forwarded initiator hello.
l flow：流消息，包括user data, next user data, buffer probe, user data ack, user dataack, flow exception report.
session的建立是通過握手(handshake)來完成的，正常的messageflow如下：
如果是在NAT打洞是，cumulus server就作為一個forwarder，他會把initiatro hello包轉發(fā)到其它的client：
另外，cumulus server還可以讓client重定向到其它server：