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

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

第三, QUIC 协议的 Delayed ACK 机制运行在应用层 (用户态), 而 TCP 协议的 Delayed ACK 机制运行在传输
层 (内核态). 由于用户态相比内核态天然易于调试, 因此可以预见未来 QUIC 协议上的 ACK 机制将会更有机会得
到进一步的演进和优化.
(2) RTCP 与 TCP 的确认机制对比
RTCP 协议主要用于实时音视频传输应用中, 而 TCP 协议是通用传输协议, 两者应用场景的差异导致其在
ACK 报文的类型和携带的信息的设计上截然不同.
ACK 报文的发送频率方面, RTCP 协议的确认机制是 Bounded ACK 机制的具体实现. 因此, 相比 TCP 的
Delayed ACK 机制, RTCP 协议的确认机制具有更强的带宽适应性. 具体地, RTCP 协议的确认机制可以根据会话
中发送方的数目进行适配, 如果发送方超过总成员的 25%, 则 ACK 占用的带宽平均分配给所有发送方和接收方;
否则把至少 25% 的 ACK 带宽分配给发送方, 其余分配给接收方.
RTCP 协议的确认机制是继 TCP 协议的确认机制之后的一种全新的尝试, 为后续的按需确认机制的提出奠定
了良好的基础.

4 按需确认机制设计与评价

4.1 设计实践: 针对无线局域网的 TACK 机制
按需确认机制的实现, 依赖于对收发双方节点的修改 (通常不需要修改中间的转发节点). 即使基于用户态协
议栈, 实现一个全新的确认机制也依然存在双端部署难题. 因此, 设计一个按需确认机制, 使其能够运行在通用网
络中显然不太现实. 真正可行的方式, 是针对某种特定应用环境设计相应的确认机制. 下面, 以无线局域网抗干扰
的应用场景为例, 介绍如何根据应用场景的需求, 设计可行的按需确认机制.
4.1.1 动机: 减少 ACK 数目
传统传输协议 TCP 因为要保证可靠, 在发送数据报文的同时, 难以避免地频繁发送 ACK 报文. 另一方面, 无
线局域网 (如 Wi-Fi) 的半双工特性和冲突避免机制, 使 ACK 报文和数据报文产生直接的资源竞争, 形成“内部干
扰”. 在传统 TCP 的 ACK 机制下, ACK 报文占用大量的可用频谱资源. 而且, 带宽越大, “内部干扰”越严重. 在这种
情况下, 减少 ACK 报文的数目从而降低“内部干扰”, 不仅可以提高无线传输的有效带宽利用率, 而且还可以在弱
网下将有限的宝贵传输资源留给数据报文.
TACK (Tame ACK) 机制 [29,30] 是一种按需确认机制, 其设计目标是最小化 ACK 的数目, 从而减少内部干扰,
并且需要能够支撑其他协议功能模块实现低开销和高性能的基本目标. 如前面所述, TACK 机制的 ACK 频率 f tack
可以表示为:
( )
β
bw max
, (7)
f tack =min
L·MSS RTT min
其中, bw max 表示一段时间内的最大带宽, MSS 表示最大段长度, RTT min 表示一段时间内的最小 RTT. L 和 β 是可
bw max
调参数. 表示每累计收到 L 个 MSS 大小的数据报文后回复 1 个 ACK 报文. β 用于控制每个 RTT 回复的
L·MSS
β
TACK 的数目, 表示每经过 RTT min 回复 β 个 ACK.
RTT min
要最小化 ACK 数目, 则需要确定 β 的下界和 L 的上界. Li 等人 [29] 通过理论推导和分析, 证明了当瓶颈链路
的缓存至少为 1 倍 BDP 时, 有 β =2, 即 β 的下界为 2. 同时, L 的上界可以表示为 Q , 其中 Q 表示 ACK 携带的
ρ·ρ ′
′
信息量, ρ 表示正向路径上的丢包率, ρ 表示反向路径上的丢包率.
为了增加 ACK 报文的反馈鲁棒性, Li 等人 [29] 通过进一步的分析, 结合实际经验, 建议取 β = 4 .
4.1.2 挑战: TACK 引入的副作用
(1) 丢包恢复延迟大
行头阻塞导致报文组装延迟, 从而严重影响传输性能. 应用 TACK 将进一步增大由于行头阻塞引入的报文组