rtmfp流媒体-部分关键协议介绍

转载自：http://bbs.baofengcloud.com/home.php?mod=space&uid=30&do=blog&quickforward=1&id=2

1.0x30 : Initiator Hello

2.0x70 : Responder Hello

3.0x0f : Forwarded Initiator Hello

4.0x71 : Responder Redirect

5.0x38 : Initiator Initial Keying

6.0x78 : Responder Initial Keying

7.0x10 : User Data

8.0x11 : Next User Data

9.0x51 : Data Acknowledgement Ranges

0.rtmfp数据包格式

      rtmfp真实数据包格式与官方文档中描述的有差别，官方文档的描述缺少了checksum字段。

1.0x30 : Initiator Hello

      0x30协议官方文档和实际看到的结果是不一样的，区别如下图所示。

真实的0x30协议结构为:0x30 + chunklen + 1B(无用) + 1B(urllen + 1) + 1B(flag) + url + 16B(tag)。

flag取值有两种:0x0a和0x0f，0x0a说明后面的url为连接服务器，0x0f表示后面的url为epd（其他peer的32字节id）。

2.0x70 : Responder Hello

• tag:IHello中的tag。
• cookie:64字节数据，cumulus使用的是随机数，正确的做法是根据Initiator的ip地址算出一个值，否则无法验证发送IIKeying的ip地址是否正确，也就无法发送0x79 : RHello Cookie Change协议。
• respondercertificage:Responder的证书，其结构为单个或多个Option的组合，Initiator将用他计算peer id。

3.0x0f : Forwarded Initiator Hello

• epd:IHello协议中携带的32字节的peer id，Responder应该将这个值与自己的peer id做比较，如果不相等（也就是说找的不是自己）则应该拒绝连接。
• replyaddress:server观察到的Initiator的地址，Initiator可能会有多个地址，如果Responder没有反应则server会定时重发0x0f协议，但是每次携带的地址是不同的，多个地址轮询发送。
• tag:IHello协议中携带的tag。

4.0x71 : Responder Redirect

• tag:IHello协议中携带的tag，Initiator可以验证下是不是自己发送的，避免攻击。
• redirectDestination:多个地址，每个地址有一个flag标志，第一个flag=2表示地址是Initiator自己上报的，第二个flag=1表示地址是server观察到的，观察到的地址可能是错误的。

5.0x38 : Initiator Initial Keying

• initiatorSessionID:Initiator希望使用的session id，4个字节，奇怪的是这个值应该是网络序，但flash client使用的却是小字节序。
• cookieEcho:Responder发来的cookie，注意发送IIKeying的ip地址应该和发送IHello的地址相同，否则会收到0x79 : RHello Cookie Change协议
• nitiatorCertificate:Initiator的证书，其结构为单个或多个Option组合，Responder用他来计算peer id。
• sessionKeyInitiatorComponent:其结构为单个或多个Option组合，用于秘钥计算。
• signature:只有一个字节0x58。

6.0x78 : Responder Initial Keying

• responderSessionID:Responder希望使用的session id，4个字节，奇怪的是这个值应该是网络序，但flash client使用的却是小字节序。
• sessionKeyResponderComponent:其结构为单个或多个Option组合，用于秘钥计算。
• signature:只有一个字节0x58。

7.0x10 : User Data

• OPT:后面是否有Option list。
• FRA:0=whole, 1=begin, 2=end, 3=middle，如果0x10封装了协议则这个值几乎全是0。
• flowID:流ID。
• seq:编号从1开始，每一个0x10或0x11都会使他加1。
• fsnOffset:
• optionslist:单个或多个Option，由marker结尾。注意多个Option和OptionList是不同的，后者有marker结尾。
• userData:如果是协议则其内容可能是AMF结构。

Option只有两种结构，如下所示:

userMetadata用法未知。

这个Option后面的flowID表示两个flowID相关联。

8.0x11 : Next User Data

用法通0x10，只是少了几个字节。

9.0x51 : Data Acknowledgement Ranges

• flowID:确认的流id。
• bufAvail:responder当前可用的缓冲区大小。
• cumAck:表示小于等于这个值的seq值都已经收到了，这个值应该等于当前接收到的连续seq编号的最大值。
• holes,recv:如果0x51用于确认命令，则没有hole和recv字段。