FlashP2P库librtmfp设计

1 背景

正值Flash被彻底干掉的时间，FlashP2P在页面上很快也没有用武之地，本文就介绍一下我们在项目中使用的自研的librtmfp，其主要作用是使App可以和页面Flash播放器通过RTMFP协议互通，这样移动端搜狐视频可以通过P2P技术从页面获取视频数据。

2 参考文档

RFC7016，RFC7425

3 外部结构

• HotVrs：获取文件信息；
• Gateway：获取Tracker、RtmfpServer；
• Tracker：获取Peer；
• RtmfpServer：Flash打洞服务器，负责Peer之间交互打洞信息。

4 内部层次结构

• Stream：用于用户接口与底层实现的交互；
• Session：标识一个会话，一次逻辑上的连接会话，管理状态，封装消息处理、传输接口；
• Protocol：封装Rtmfp、Rtmp、As3等协议实现；
• Flow：模拟TCP流控实现，处理丢包、乱序、拥塞控制等，SendFlow实现发送端流控，RecvFlow实现接收端流控；
• Transport：使用UDP。

简单说，核心的几个类里面，NetStream用于底层(Session)与上层交互，send_stream_用于发送数据，recv_stream_用于接收数据；Session用于管理连接；SendFlow、RecvFlow用于流控，从属于Session。

类名	功能	实现
P2PFlash	提供全局接口的类，主要接口有初始化、反初始化、打洞接口；	该类内部包含一个NetConnect对象，作为全局的唯一特殊Session，用于与服务器之间的交互。
BaseFlashPeer	提供Peer接口调用的类，上层需要实现该类的若干回调以得到FlashP2P的事件；主要接口有下载、上传、事件通知等	1.该类内部包含NetStream对象， 用于实现用户接口与底层的交互；2.send_stream_主要用于发送数据；3.recv_stream_主要上报接收数据。
NetStream	主要实现用户接口与底层的交互；	1.该类内部包含send_queue_、recv_queue_两个队列，前者是异步发送队列，上层调用线程将数据放入send_queue_，StartRtmfp线程从send_queue_获取发送数据发送，而recv_queue_是异步接收队列，StartRtmfp线程读到下载数据后向recv_queue_推送，并由StartDownload线程通知上层; 2.该类内部包含一个Session列表(每次打洞都添加一个Session，相当于建立一个新的会话)，StartRtmfp线程会将send_queue_中的数据向这些Session广播(As3的规则)。
Session	对会话的封装，Session是一个端到端的会话，有一个唯一的会话id标识该次会话，该类提供了各种消息的发送、处理接口。	1. 该内内部维护两个Flow列表，一个是send_flows_，一个是recv_flows_，分别做发送端、接收端的数据传输、流控；2. 该类建立NetStream和RecvFlow的联系，将从send_stream_的数据传给SendFlow，将从RecvFlow收到的数据传给NetStream，最终吐给上层。
SendFlow	实现发送端流控	算法见下面流控算法一节 。
RecvFlow	实现接收端流控	1. RecvFlow从属于一个Session，包含一个NetStream用于与用户接口交互;2. 算法见下面流控算法一节。

5 线程模型

会创建3个线程(按照启动顺序)：

• NetConnect::StartRtmfp：负责底层的数据收发；
• P2PFlash::StartDownload：负责下载数据的上报；
• P2PFlash::StartUpload：负责获取上传数据。

6 数据流

6.1 数据传递机制

下载端将下载请求放入send_stream_的发送队列，由StartRtmfp线程检查并放入发送端Session的SendFlow进行流式发送。send_stream_的发送队列为只允许一读一写的无锁队列，没有通知StartRtmfp线程的机制，StartRtmfp线程在处理完一次select之后处理发送队列中的数据，因此效率可能不高。

上传端StartRtmfp线程中，对应Session从Socket获得请求后放入RecvFlow进行接收端流控，然后放入recv_stream_的接收队列，由StartDownload线程检查并提交上层。上传端的收包使用select，相当于通知机制，数据提交给recv_stream_的接收队列使用信号量通知，效率较高。

6.2 打洞

6.3 上传、下载

7 协议封装

在会话建立阶段，使用IHello、RHello、IIKeying、RIKeying等RTMFP Chunk与Server或者Remote Peer建立安全连接，建立连接之后，使用RTMFP承载携带AMF格式的请求参数的RTMP消息来进行数据的请求、响应。因此，在这里，RTMFP为基础通信协议，RTMP为中间层协议，AMF为应用层协议。
RTMFP协议中的所有数据都使用大端字节序。

8 RTMFP协议消息交互

8.1 打洞

8.2 下载、上传

9 数据安全

上述的数据封装结构为明文形式，RTMFP规定在网络中传输的数据必须进行加密。由于本地端点和远端端点上可能都存在多个Session，所以每个Session维护一对数据加、解密的密钥。
加密之后的RTMFP包形式如下：

其中前4个字节称为SSID(Scrambled Session ID)，是Session ID和加密后的RTMFP Packet的前两个4字节异或的结果，目的是为了混淆原始的Session ID，这样接收端可以通过前3个4字节计算出原始的Session ID，从而找到这个Packet归属的Session，并进行解密。
另外，待加密字段的前两个字节，也就是first32[0]明文的前两个字节是CRC校验值check sum，校验范围是check sum后面的所有数据。之后包括check sum在内的所有RTMFP数据将被加密。

9.1 加解密算法

RTMFP协议(RFC7016)本身不规定加解密的方案，在RFC7425中规定了Adobe官方目前默认的加解密方案：

• 会话建立以后使用AES-CBC-1024对称加密算法加解密，使用的密钥称为会话密钥，包含一个加密密钥和一个解密密钥；
• 建立会话的握手过程的一个主要目标是使用DH算法交换会话密钥；
• 在会话建立期间收发的握手消息也进行加密，但是使用默认的会话密钥“Adobe System 02”；
• 一旦会话建立成功后将使用交换之后的会话密钥对后续的会话消息进行加解密。

9.2 DH密钥交换算法

RTMFP使用DH算法来交换会话密钥，计算会话密钥主要分为两部分，包含在会话建立的过程中：

• 在上述的会话建立过程中，在会话发起者的IIKeying和会话响应者的RHello消息中，分别携带各自的证书，证书主要包含DH Group信息(目前为2)以及RSA公钥；通过这两个消息的交换，双方可以拿到对方的公钥，这样可以使用对方的公钥与本地的私钥计算一个共享密钥shared_secret；
• 在上述的会话建立过程中，在会话发起者的IIKeying和会话响应者的RIKeying中，分别携带各自的Key Component(实际上是一个随机数)，使用HMAC+SHA256算法，结合共享密钥、各自的Key Component可以分别计算出加、解密密钥，这样就完成了密钥的交换过程。

10 流控算法：滑动窗口机制

发送端用SendFlow、接收端用RecvFlow做流控，每个包编号(序列号)，并携带flow id。

发送端将编号的数据放入SendFlow的发送缓冲中，判断是否满足发送条件，是则发送，否则等待确认，发送条件最典型的是待发送数据长度是否小于对端通告的接收窗口大小。在启动过程中，使用慢启动，增加发送窗口，直到发生拥塞条件开始降低发送窗口。

接收端对收到的数据回确认(ACK)，分成两种类型的确认，一种是连续的确认，一种是不连续的分段确认，用于处理乱序。在确认数据中携带接收端剩余可用的接收缓冲大小(接收端通告窗口)，同时接收端提取连续数据提交上层。

10.1 发送端流控

SendFlow类负责发送端流控，由三个函数完成发送端的所有流控操作：

• CreateUserData，从预先申请的发送缓冲中申请一个结点承载发送数据；
• AckUserData，处理确认数据，将发送缓冲中的数据状态设置为ACK；
• FlushUserData，流式数据发送，处理发送缓冲中的数据；
  如上节的滑动窗口图，发送端每次收到ACK，调用AckUserData，将“已经发送但是未收到确认的数据”状态设置为“已经发送并且收到确认”(右移窗口左沿)，并根据对方通告的窗口调整发送缓冲上限(右移窗口右沿)，每次调用FlushUserData，将重置已经确认的数据，并且根据对端的通告窗口发送可以发送的数据(移动待发数据指针)。

10.1.1 CreateUserData

10.1.2 AckUserData

10.1.3 FlushUserData

1. 已经收到确认但是未处理的数据:
   

2. 还未发送的数据:
   

3. 已经发送还未收到确认的数据:
   

4. 已经收到确认并且处理过的数据:
   

10.2 接收端流控

RecvFlow类负责发送端流控，主要由两个函数完成接收端的所有流控操作：

• FiltrateUserData：处理重传、乱序，更新连续确认的最大序列号，并获得有效数据；
• GenerateDataAckRanges：产生确认包，包括连续确认的最大序列号和不连续确认的各个区间。

10.2.1 GenerateDataAckRanges

11 分片/重组

11.1 分片

控制单个数据包(UserData)的最大长度为MAX_CHUNK_SIZE(1168字节)，信令包例如IHello、RHello、IIKeying等不做分片处理，并且在打洞交互信令时期的Play等数据包也不做分片处理，因为数据都比较小，需要分片的是传输视频数据时的包。
分片操作主要由Session::SendMessage和UserData::SetMessage完成，他们的调用时机为发送数据请求或者发送视频数据时。

11.2 重组

重组发生在接收端的RecvFlow::FiltrateUserData中，在7.2.7.2.2节中描述了重组的逻辑，提取有效数据时必须满足：

• 有序；
• 不分片(FRAGMENT_CONTROL_WHOLE)；
• 分片结尾(FRAGMENT_CONTROL_END)。