SRT协议分析（握手控制包）

注：上一篇文章介绍了SRT协议的基本包结构，以及TSBPD、RTT计算、liveCC模式等相关内容。当时提到控制包并未展开介绍，本文将重点分析其中最为复杂的握手控制包。握手过程是SRT连接的基石，涉及版本协商、参数交换、加密配置等一系列操作，理解了握手包，基本上就对SRT的连接建立过程有了全局认识。

1. 握手包二进制结构

握手控制包（Control Type = 0x0000）的控制信息字段（CIF）结构相对复杂，里面包含了很多重要的配置参数。它的结构如下图所示：

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HS Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption Field | Extension Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Initial Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Transmission Unit Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Flow Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Handshake Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRT Socket ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SYN Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Peer IP Address + | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Extension Type | Extension Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Extension Contents + | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

各个字段的具体含义如下：

• HS Version：32位。握手版本号。目前主要使用的是4和5，大于5的值保留给以后用。

• Encryption Field：16位。加密相关的字段，表示支持的分组密码家族和密钥长度。取值含义如下表：

  值	含义
  0	不声明加密
  2	AES-128
  3	AES-192
  4	AES-256

  默认值是0，如果双方都没声明加密，协议会默认选择AES-128。

• Extension Field：16位。扩展字段，具体含义与Handshake Type有关。一般情况下填0，但在INDUCTION和CONCLUSION消息中有特殊用途。这个字段可以看作是位掩码，标志位定义如下：

  位掩码	标志	含义
  0x00000001	HSREQ	握手扩展请求/响应
  0x00000002	KMREQ	密钥材料扩展请求/响应
  0x00000004	CONFIG	其他配置扩展，比如Stream ID

• Initial Packet Sequence Number：31位。第一个数据包的序列号，注意最高位被F字段占用了，所以这里只有31位有效。

• Maximum Transmission Unit Size：32位。MTU大小，单位字节。通常是以太网的1500字节，但也可以根据网络情况调整。

• Maximum Flow Window Size：32位。最大流窗口大小，也就是最多允许有多少个数据包“在途”（已发送但未收到ACK）。

• Handshake Type：32位。握手包的类型，这个字段很重要，决定了当前握手进行到哪一步。具体取值如下：

  值	握手类型	说明
  0xFFFFFFFD	DONE	握手完成
  0xFFFFFFFE	AGREEMENT	双方达成一致
  0xFFFFFFFF	CONCLUSION	结论消息，通常是握手的最后阶段
  0x00000000	WAVEAHAND	主动握手发起
  0x00000001	INDUCTION	引导消息，用于握手初期

• SRT Socket ID：32位。发送方套接字的ID，用于标识这个连接。

• SYN Cookie：32位。握手过程中用于验证的随机数，类似TCP的SYN Cookie机制，防止握手攻击。

• Peer IP Address：128位。对端的IP地址，兼容IPv4和IPv6。如果是IPv4地址，后面的96位都填0。

• Extension Type：16位。扩展类型，表示后面跟着的是哪种扩展内容。常见扩展类型如下：

  值	扩展类型	所属标志	用途
  1	SRT_CMD_HSREQ	HSREQ	握手参数扩展请求
  2	SRT_CMD_HSRSP	HSREQ	握手参数扩展响应
  3	SRT_CMD_KMREQ	KMREQ	密钥材料扩展请求
  4	SRT_CMD_KMRSP	KMREQ	密钥材料扩展响应
  5	SRT_CMD_SID	CONFIG	流ID扩展
  6	SRT_CMD_CONGESTION	CONFIG	拥塞控制算法配置
  7	SRT_CMD_FILTER	CONFIG	包过滤配置
  8	SRT_CMD_GROUP	CONFIG	组成员扩展

• Extension Length：16位。扩展内容的长度，以4字节为单位（也就是按32位字长计数）。

• Extension Contents：可变长度。扩展的具体内容，由Extension Type决定。

2. 握手扩展消息（HSREQ/HSRSP）

这是握手过程中最基本的一个扩展，用来交换一些核心的配置参数。它的结构如下：

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRT Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRT Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver TSBPD Delay | Sender TSBPD Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• SRT Version：32位。SRT库的版本号，编码方式是主版本 * 0x10000 + 次版本 * 0x100 + 修订号。

• SRT Flags：32位。功能标志位，表示支持哪些特性。标志位定义如下：

  位掩码	标志	含义
  0x00000001	TSBPDSND	发送端启用TSBPD
  0x00000002	TSBPDRCV	接收端启用TSBPD
  0x00000004	CRYPT	支持加密（遗留标志，必须设置）
  0x00000008	TLPKTDROP	支持过晚数据包丢弃
  0x00000010	PERIODICNAK	支持周期性NAK
  0x00000020	REXMITFLG	支持重传标志（遗留标志，必须设置）
  0x00000040	STREAM	流模式：1=缓冲模式，0=消息模式
  0x00000080	PACKET_FILTER	支持包过滤

• Receiver TSBPD Delay：16位。接收端的TSBPD延迟，单位毫秒。

• Sender TSBPD Delay：16位。发送端的TSBPD延迟，单位毫秒。

3. 密钥材料扩展消息（KMREQ/KMRSP）

如果需要建立加密连接，就会用到这个扩展来交换密钥材料。KMREQ是请求，KMRSP是响应。具体的密钥材料消息结构比较复杂，这里先不展开，只说下KMRSP在出错时的一种特殊格式。

如果KMRSP的Extension Length等于1（也就是4字节），说明加密协商失败了，这时候Extension Contents的结构很简单：

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KM State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

KM State：32位，表示对端的密钥材料状态，具体取值如下：

• 0：未加密（对端会加密负载，但本端没声明加密）
• 3：无密钥（对端没有解密负载的密钥）
• 4：密钥错误（对端密钥不对，无法解密）
• 5：加密模式错误（对端期望使用不同的加密模式，v1.6以后才有）

4. 流ID扩展消息（SID）

这个扩展比较简单，就是用来标识流内容的。Stream ID可以是任意UTF-8字符串，最大512字节。它的结构就是一段UTF-8文本：

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Stream ID | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

实际长度由Extension Length字段决定（注意单位是4字节），如果实际文本长度不足，后面会用0补齐。存储时是按32位小端序存的。

5. 组成员扩展（GROUP）

这个扩展是保留给将来多路径SRT用的，目前可以先了解下结构：

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• GroupID：32位。组标识符，表示发送方属于哪个组。
• Type：8位。组类型：
  • 0：未定义
  • 1：广播组
  • 2：主/备组
  • 3：负载均衡组
  • 4：多播组（保留）
• Flags：8位。标志位，目前只用了最低位M：
  • M=1：按消息编号同步
  • M=0：按序列号同步
• Weight：16位。权重，在主/备组中表示链路优先级，其他类型暂时没用。

注：由于握手过程涉及的消息交互逻辑比较复杂，本文主要聚焦于握手包本身的结构解析。后续如果有机会，可以再单独写一篇介绍SRT完整的握手流程，包括INDUCTION、CONCLUSION、AGREEMENT这些消息是如何交互的。