注：上一篇文章介绍了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这些消息是如何交互的。
