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

李彤 等: 传输控制中的确认机制研究 2017

基于 TACK 机制测量得到的 RTT 的测量值, 橙色虚线表示基于 TACK 机制使用传统 TCP 的在发送端进行采样的
最小时延探测算法, 绿色实线表示基于 TACK 机制使用了基于单向时延的最小时延探测算法 (算法详情见文
献 [29]). 实验表明, 在应用 TACK 机制的情况下, 如果继续采用传统时延探测算法, 将导致较大的偏差 (8–18 ms),
而如果经过重新精心地设计相应的算法, 则可以避免因应用 TACK 引入的副作用.

802.11b 802.11ac
TCP TACK TCP TACK
RTT min (L=2) (L=2) (L=2) (L=2)
802.11b 802.11g 802.11n 802.11ac
10 ms 294 294 24 777 400 减少的 ACK 数目 90.5% 95.4% 99.4% 99.8%
80 ms 294 50 24 777 50 提升的吞吐量 20.0% 26.3% 27.7% 28.1%
200 ms 294 20 24 777 20
(a) 实际网络中 ACK 报文数目举例 [28] (b) 实际网络中 TACK 机制的有益效果 [28]
图 23 TACK 机制在实际网络中的运行结果

RTT 采样 RTT min (传统方案) RTT min (改进方案)
180 TACK-rich TCP BBR
TACK-poor
160 100 92.7 91.7 91.8 91.6 91.6 80.2 90.8
RTT (ms) 140 118 110 带宽利用率 (%) 78.3 75.9 63.4 60.6 65.3

120 108 50
100
0
0 5 10 15 20 25 0.2 1 5 10
时间 (s) 反向 ACK 路径上的丢包率
(a) 时延抖动下的 TACK 机制性能 [28] (b) 反向丢包下的 TACK 机制性能 [28]
图 24 TACK 机制在时延抖动和反射丢包场景下的性能举例

图 24(b) 给出了反向丢包下的 TACK 机制性能举例. 在这个实验中, RTT 固定为 200 ms, 正向数据路径上的丢
包率为 1%, 反向 ACK 路径上的丢包率在 0.2%–10% 之间变化. “TACK-poor”表示 TACK 报文仅携带 1 个 RBB,
“TACK-rich”表示 TACK 报文携带尽量多的 RBB. 实验表明, 在应用 TACK 机制的情况下, 如果仅携带 1 个 RBB,
反向丢包将导致协议性能恶化, 只有携带更多的信息量, 如“TACK-rich”才可以避免因应用 TACK 引入的副作用.
综上所述, 针对时延抖动和反向丢包场景的实验结果, 进一步证明了频繁的 ACK 数目并不是传输所必须的, 如果
对当前传统的传输协议机制 (如时延探测和丢包恢复) 进行针对性地调整和修改, 则可以避免因减少 ACK 带来的
副作用.
5 未来研究方向

确认机制是传输控制中的关键模块, 针对确认机制的研究对协议性能优化起到关键作用. 但是, 相比拥塞控制
算法, 确认机制与传输控制中的其他模块耦合性更强. 这主要体现在: (1) 确认机制优化方案通常需要收发双端配
合. 例如, 新增一种 ACK 类型, 需要数据接收方按 ACK 报文指定条件进行触发和封装携带指定的信息; 同时, 需
要数据发送方能够识别和解析该 ACK 类型携带的内容, 并正确进行传输控制操作 (例如增减窗口). (2) 确认机制
的变更, 通常需要相应地修改整个协议栈. 例如, 减少 ACK 的数目, 需要修改拥塞控制算法, 将部分原来在发送方
完成的逻辑 (例如统计每包时延), 迁移到接收方来完成 [30] . (3) 不同的确认机制之间差异较大, 协议强耦合性导致
很难在一个统一的协议框架中对不同的机制进行对比. (4) 不存在一种通用的确认机制在所有场景和应用条件下
都能达到最优, 本文中描述的 TACK 机制只是按需确认的在无线局域网中的实例, 然而, 针对更多的场景和差异