SRT协议中ACK包序列号错误的分析与修复

问题背景

在SRT(可靠传输协议)1.5.2版本中，发现了一个罕见的ACK包序列号(SN)错误问题。该问题会导致重传机制失效，进而造成数据包丢失。这个问题在特定条件下才会触发，主要影响高吞吐量、长时间运行的稳定网络环境。

问题现象

当接收端检测到数据包丢失时，会发送NAK(否定确认)包请求重传。正常情况下，随后发送的ACK(确认)包应该包含丢失数据包的序列号。但在某些情况下，ACK包中却包含了比丢失序列号更大的序列号，导致发送端误认为数据已被接收，从而取消重传。

根本原因分析

经过深入分析，发现问题出在接收端丢失列表(CRcvLossList)的管理机制上：

1. 丢失列表更新失败：当新发现的丢失数据包序列号小于列表中记录的最大序列号时，系统会拒绝更新丢失列表。这是因为系统认为新发现的丢失数据包"太小"。

2. 序列号循环问题：在长时间高吞吐量传输中，序列号会循环使用。当两次丢包事件间隔超过序列号范围的一半时，就会出现新丢失数据包序列号"小于"之前记录的情况。

3. ACK生成逻辑缺陷：当丢失列表为空时，系统会使用当前接收到的最大序列号加1作为ACK号，而不是使用实际丢失的序列号。

技术细节

在代码层面，问题具体表现为：

1. CRcvLossList::insert()函数中，当检测到新序列号小于m_iLargestSeq时，会拒绝更新丢失列表。

2. CUDT::sendCtrlAck()函数中，当丢失列表为空时，会使用m_iRcvCurrSeqNo + 1作为ACK号，而不是使用实际丢失的序列号。

3. m_iLargestSeq在列表清空时没有被正确重置，导致后续插入操作判断错误。

解决方案

修复方案主要包含两个关键修改：

1. 在CRcvLossList::remove()函数中，当检测到丢失列表被清空时，主动将m_iLargestSeq重置为SRT_SEQNO_NONE。

2. 确保在丢失列表为空时，ACK生成逻辑能够正确处理这种情况。

影响范围

该问题影响SRT 1.5.0至1.5.3版本。在以下环境中更容易出现：

• 数据包传输速率极高
• 网络极其稳定，数天没有丢包
• 序列号已经循环多次

预防措施

为避免类似问题，建议：

1. 定期检查序列号循环相关逻辑
2. 在关键数据结构清空时，重置所有相关状态变量
3. 增加边界条件测试用例

总结

这个案例展示了在高性能网络协议开发中，边界条件处理的重要性。特别是对于长时间运行的场景，必须考虑所有可能的序列号循环情况。通过这次修复，SRT协议在极端情况下的可靠性得到了进一步提升。