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

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

基于 TACK 机制的传输协议, 原则上可以摒弃传统的滑动窗口机制, 而替代以一种无食言 (No Reneging) 机
制. No Reneging 机制是一种缓存管理机制, 它要求接收方不能将接收缓存中的已成功接收的数据报文丢弃. 那么,
为什么 TCP 要采用滑动窗口机制而不采用缓存管理机制呢? 本质的原因就在于 TCP 报文被成功接收后, 接收方
是可以将不连续的数据报文丢弃的, 也就是说, TCP 是可食言的. 滑动窗口机制要求左边界的报文确认后才能滑
动, 而 No Reneging 缓存管理机制只要有新的已接收数据报文得到确认, 就可以继续发送报文. 根据发送窗口的定
义, 发送窗口大小被限制为不超过拥塞窗口和接收窗口的较小值. 其中, 接收窗口通过 ACK 报文由接收方反馈给
发送方. No Reneging 机制下剩余可发送数据量的更新策略为: 发送窗口−在接收缓存中的已确认数据量 .
值得一提的是, 当原始数据包 K 丢失后, 发送方会将需要重传的数据报文放到待发送队列, 重新编号 (比如数
据报文 K+i) 后重新发送给接收方. 由于使用了单调递增的 PKT.SEQ, 传输控制对重传报文的处理跟原始报文的
处理完全相同. 因此, 基于 TACK 机制的传输协议, 在数据报文的处理逻辑方面比 TCP 相对简单.
(3) QUIC 相关机制
QUIC 协议同样采用了 No Reneging 缓存管理机制, 因此, QUIC 也采用了区别于传统滑动窗口的机制, 从而
克服 HoLB 问题. 并且, QUIC 协议同样采用了与 TACK 机制类似的双 SEQ 机制. 具体地, QUIC 使用单调递增的
packet number 来记录每个报文的发送顺序, 同样根据 packet number 的乱序来检测丢包事件. TACK 机制使用
DATA.SEQ 来确认重传报文和原始报文的内容是否一致, 而在 QUIC 协议中, 使用数据流标识 (Stream ID) 作为数
据报文多路复用传输到接收方后能正常组装的依据. 重传报文和原始报文单靠 Stream ID 的比对无法判断两个数
据报文内容一致. 因此, QUIC 协议在每个数据报文中增加 stream offset 字段, 标识当前数据报文在当前 Stream ID
中的字节偏移量, 从而指导数据的有序组装. 换句话说, QUIC 协议中的 Packet Number 等价于 TACK 机制中的
PKT.SEQ, QUIC 协议中的 stream offset 等价于 TACK 机制中的 DATA.SEQ.
4.2 机制对比和分析
4.2.1 TACK 与 SACK
TCP 的 ACK 报文可以携带 SACK 选项, 也称 SACK 报文. SACK 选项由数据接收方发送, 以通知数据发送方
已经接收、并且在接收方接收缓存中排队的非连续数据区间 (Range). 这些区间信息可以帮助发送方识别已经传
输成功的数据, 避免不必要的重传. 由于 TCP 选项字段的长度限制, 导致 SACK 携带的区间数量有限, 面对反向丢
包时, 选择重传无法精确表达, 不必要的重传无法避免, 导致带宽浪费.
SACK 选项字段长度受限的原因, 是因为 TCP 需要支持 ACK Piggybacking 机制, 所以 SACK 选项字段只能
放在有限的报文头部. 如前面介绍的, ACK Piggybacking 能够间接地减少 ACK 报文的数目. 然而, 当应用 TACK
机制时, ACK 数目通常已经足够小. 因此, 基于 TACK 机制的传输控制, 可以考虑不支持 ACK Piggybacking 机制.
在这种情况下, 除了在报文头部可以携带区间信息以外, 还可以让 ACK 报文自带数据部分, 该数据部分并不是真
正的数据, 而是用于反馈控制的 Range 信息.
4.2.2 TACK 与 HACK
为了提高 IEEE 802.11 无线链路的传输性能, Salameh 等人提出了 HACK (hierarchical ACK) [36] . HACK 通过改
变 Wi-Fi 介质访问控制 (MAC), 在链路层 ACK 报文中携带 TCP ACK 原本需要反馈的信息, 去掉了 TCP ACK 对
频谱资源的需求, 从而提高 TCP 的性能. 下面从 3 个方面来讨论 TACK 和 HACK 的区别.
第一, TACK 减少了端到端的 ACK 报文数目, 而 HACK 只减少了无线链路上的 ACK 报文数目. 因此, TACK
在减少 ACK 开销这方面更为通用, 可用于解决非对称网络中 ACK 路径拥塞的问题 [37] .
第二, HACK 要求修改网卡, 但不需要修改 TCP; TACK 要求修改 TCP, 但不需要修改网卡.
第三, 由于链路层 ACK 和传输层 ACK 的触发时间通常是异步的, 所以 HACK 很可能会导致 ACK 延迟. 因
此, HACK 不能解决传输方面的挑战, 如丢包恢复延迟大、时延评估偏差、流量突发和接收窗口通告延迟等.
4.2.3 TACK 与 RACK
TACK 是为了减少 ACK 数目, 但是又不影响协议性能的一种传输协议确认机制. 确认机制需要支撑的协议功