flashP2P协议rtmfp解析
1 协议介绍
Real-Time Media Flow Protocol(简称RTMFP)是Flash和Flash之间基于UDP的点对点传输协议，由Adobe公司在2008年在Flash 10.0中发布，随后在Flash10.1中加入了Groups功能。
2 常见用法
rtmfp在Flash 10中的典型使用场景如下图：
它有如下特点：
l 使用Cirrus或者开源的Cumulus来提供Rendezvous服务
l Cirrus或者Cumulus并不提供Peer ID的交换服务，需要提供其它的方式来交换客户端之间的Peer ID
l Flash客户端之间使用NetStream来做点对点传输，Publisher需要给每一个Subscriber单独传输一份数据，这也限制集群的规模。
为了解决这个问题，Adobe在Flash 10.1中提出了Groups的概念，典型的架构如下：
它有如下特点：
l Cirrus或者开源的Cumulus提供Rendezvous服务并提供所有连接client列表
l client从Cirrus或者开源的Cumulus获取邻居节点之后，就可以组成一个完整的P2P架构，所有的audio、video和data数据都在peer之间交互。
3 协议解析
3.1 基本概念
l session：session是两个UDP地址之间的双向管道。
l flow：flow是从一个实体到另一个实体之间的逻辑路径。一个session可以包括多个flow。
l packet：网络中实际传输的数据，一个packet可以包含多个message。数据传输时都经过了128 bit的AES加密
l message：audio、video和data数据。
3.2 Scrambled Session ID
rtmfp协议中每个包的格式如下：
packet := scrambled-session-id | encrypted-part
其中scrambled-session-id是4字节，其后是经过AES加密的数据体。
scramble-session-id的生成规则如下：
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的目的为了减少数据包流经的NAT设备和layer-4 packet inspector对数据的干扰。
session-id用于标识通信双方建立的连接，并确定通信时使用的加密和解密的key，这些key是通过DH key exchange算法获得。但在session建立之前，双方使用一个公有加密key，即128 bit的字符串”Adobe System 02”。
3.3 raw part
encrypted-part经过解密之后就得到了raw-part，它的格式如下：
raw-part := checksum | network-layer-data | padding
其中checksum有16字节，network-layer-data是变长数据，padding都是0xFF，并把network-layer-data补齐为16字节的倍数，这是因为rtmfp使用的是16字节的加解密key。
checksum基于network-layer-data和padding计算。
3.4 network layer data
network-layer-data的格式如下：
network-layer-data = flags | timestamp | timestamp-echo | chunks
其中flags为1个字节，其格式如下：
7 6 5 4 3 2 1 0
TC TCR reserved reserved TS TSE mode
l mode：11代表握手包，01代表initiator发送包，10代表responder发送包，00不是合法值
l TSE：包中是否包含timestamp-echo域
l TS：包中是否包含timestamp域
l TCR：time critical reverse notification表明发送方正在从其它地方收到timecritical包
l TC：time critical forward notification表明发送方发送的是timecritical包
timestamp域有2字节，精度是4ms，他的计算方式如下：
timestamp = int(time * 1000 / 4) & 0xFFFF
timestamp-echo域是server收到包的时间戳，当发送放收到这个值之后，发送方就可以计算RTT值了。
chunk类型的格式如下：
chunk = type | size | payload
type字段为1个字节，其中0xFF不可用，这个是用来区分chunk数据和padding数据的标记。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字节payload长度。
payload根据type的不同有不同的数据体。
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包转发到其它的client：
另外，cumulus server还可以让client重定向到其它server：
……