Page 422 - 《软件学报》2024年第4期

2000 软件学报 2024 年第 35 卷第 4 期

量控制的目标是优化收发双方之间的连接性能. 拥塞控制依赖于 ACK 报文反馈的传输时延、速率和丢包等信息,
评估可用的网络瓶颈带宽, 从而调整发送速率; 流量控制依赖于 ACK 报文反馈接收方的接收缓存占用情况, 从而
避免因发送方的发送速率过高导致接收方接收缓存满的情况.

发送方 接收方 上层应用 发送方 接收方 上层应用
报文 1 报文 1
报文 3 ... 报文 2 报文 3 报文 2
报文 1−11 ... 报文组装 报文 1−101 ... 报文组装
ACK
延迟 ACK 延迟
重传报文 3 报文 3−11 重传报文 3 报文 3−101
图 7 丢包恢复: 每收到 1 个数据报文回复 1 个 ACK 图 8 每收到 100 个数据报文回复 1 个 ACK

确认机制的设计, 直接影响拥塞控制的效果. 发送方进行拥塞控制时, 需要根据接收到的 ACK 报文的到达
情况及其反馈的信息, 对网络的传输管道进行评估, 从而确定最大可发送的数据量 (即拥塞窗口) 或者最大发送
速率. 因此, ACK 的触发时机影响拥塞控制的更新粒度和数据发送过程中的流量模式. 而 ACK 携带的反馈信
息, 则直接影响拥塞控制的精准性. 图 9 从发送方的视角, 对比了不同 ACK 触发间隔时间对流量模式的影响.
如图 9(a) 所示, 当 ACK 间隔时间短时, 数据的发送速率相对恒定; 然而, 如图 9(b) 所示, 当 ACK 间隔时间较长
时, 流量呈现突发的特征. 众所周知, 突发流量可能导致瓶颈链路缓存满导致丢包, 从而严重地影响整网的传输
效率.
发送方进行流量控制时, 需要根据 ACK 反馈的接收窗口大小, 相应地调整发送速率. 具体地, 发送速率取决于
发送窗口, 而发送窗口通常取拥塞窗口和接收窗口的较小值. 也就是说, 速率控制是由拥塞控制中的拥塞窗口和流
量控制中的接收窗口共同决定的, 类似于“木桶效应”, 处于瓶颈的一方起到控制作用. 图 10 给出了接收方接收缓
存结构示意图. 其中, 接收窗口大小等于接收方接收缓存中的剩余缓存量, 由 ACK 报文反馈给发送方. 已缓存的数
据, 其序列号空间连续的部分可以提交至上层应用, 不连续的部分则造成行头阻塞现象, 必须继续保留在接收缓存
中, 等待行头的报文成功到达后, 才能提交至上层应用.

数据报文
ACK 间隔时间短 ACK 报文

上层应用
时间
(a) ACK 间隔时间短 已缓存的数据量
ACK 间隔时间长 接收缓存
剩余缓存量 接收窗口

时间
(b) ACK 间隔时间长 数据报文
图 9 流量模式与 ACK 间隔时间的关系 图 10 接收方接收缓存

另一方面, 确认机制的设计, 直接影响流量控制的效果. 如图 11 所示, 当 ACK 触发时间间隔较大时, 可能造成
反馈延迟, 进而导致带宽利用率低下. 举例来说, 设 ACK 触发时间间隔为 50 ms, 当部分数据报文丢失导致行头阻
塞时, 接收缓存会呈现即被填满的状态. 此时, 接收方发送 ACK1 通告一个小接收窗口 (例如接近 0). 当发送方接
收到 ACK1 报文后, 将减少或停止数据发送. 然而, 如果此时由于数据重传成功, 接收方行头阻塞恢复, 即使已占用
的接收缓存得到释放, 发送方也无法继续发送数据. 在这种情况下, 发送方需要等接收方 50 ms 后触发 ACK2,
ACK2 通告一个大于 0 的接收窗口后, 发送方才能恢复发送数据. 在这一过程中, 原本发送方可以发送数据的机会,
可能被白白浪费掉了. 因此, ACK 延迟触发会降低传输效率.