再论滑动窗口与行头阻塞
今天我们将从三个部分对传输控制中的确认机制进行讨论，分别介绍滑动窗口机制的概述、TACK 机制如何解决行头阻塞问题，以及 QUIC 协议中采用的相关机制。
1. 滑动窗口机制概述
为了保证数据报文的可靠交付，如果采用发送方每发出一个数据报文后必须等待收到确认该报文的 ACK 报文才能发送下一个数据报文，则形成一种“停止-等待”协议。由于前一个报文会阻塞下一个报文的发送，这种协议的效率通常较低。
为了提高数据传输效率，TCP 采用了滑动窗口机制。其主要特点包括：
- 连续发送：允许发送方一次性发送不超过窗口大小的数据报文，窗口内的后续报文无需等待前序报文的 ACK。
- 窗口大小：发送窗口（SWND）的最大值通常取拥塞窗口（CWND）与接收窗口（RWND）中较小的值。
- 窗口滑动：当可发送数据用尽时，必须等待 ACK 确认，一旦收到 ACK，窗口向前滑动，为后续数据报文腾出空间。
行头阻塞（Head-of-Line Blocking, HoLB）问题：
假设某个数据报文丢失且迟迟未收到相应 ACK，在该报文的重传未成功前，整个滑动窗口都无法滑动，从而阻塞后续所有数据报文的发送，即出现行头阻塞问题。
2. TACK 机制如何解决行头阻塞问题
行头阻塞的根本原因
- 传统滑动窗口机制要求：滑动窗口只能在最小数据序号（DATA.SEQ，即窗口左边界）的报文得到确认后才能滑动。
- TCP 的局限性：即便 TCP 的 SACK 选项能确认非连续的后序报文，但其并不能推动窗口的滑动，因而仍无法解决队头阻塞问题。
TACK 机制及 No Reneging 缓存管理机制
-
No Reneging 机制简介：
与传统滑动窗口机制不同，No Reneging 缓存管理机制要求接收方不能丢弃已成功接收的数据报文。这意味着，只要有新的已接收数据得到确认，就可以继续发送数据，而不必等待窗口最左端报文的确认。 -
TACK 机制的优势：
- 基于 TACK 的传输协议可以摒弃传统滑动窗口机制，采用 No Reneging 缓存管理来替代。
- 发送窗口的更新策略在 No Reneging 机制下为：
发送窗口 = 原始发送窗口 - 已确认接收缓存中的数据量
- 在数据重传时，发送方会将丢失的报文放入待发送队列，并为其重新编号（例如：数据报文 K+i），重新发送给接收方。
- 使用单调递增的 Packet Sequence（PKT.SEQ）确保重传报文与原始报文处理逻辑一致，从而简化了传输控制的实现。
3. QUIC 相关机制
QUIC 与传统机制的异同
-
No Reneging 缓存管理：
QUIC 协议同样采用了 No Reneging 缓存管理机制，从而克服了传统滑动窗口机制导致的行头阻塞问题。 -
双序号机制：
- Packet Number：QUIC 使用单调递增的 Packet Number 记录每个报文的发送顺序，相当于 TACK 机制中的 PKT.SEQ，用于检测报文乱序和丢包。
- Stream Offset：为支持多路复用，QUIC 在每个数据报文中增加了 Stream Offset 字段，标识数据在对应流中的字节偏移量。这个字段类似于 TACK 机制中的 DATA.SEQ，用于指导数据的有序组装。
-
总结：
QUIC 的确认机制利用 Packet Number 与 Stream Offset 的组合，既能检测重传报文和原始报文的一致性，又实现了高效的数据多路复用和有序组装，从而在结构上与 TACK 机制相似，但在应用层实现上提供了更高的灵活性和调试便利性。
4. 参考文献
- Tong Li, Kai Zheng, Ke Xu, Rahul Arvind Jadhav, Tao Xiong, Keith Winstein, Kun Tan. “TACK: Improving Wireless Transport Performance by Taming Acknowledgments.” In ACM International Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (ACM SIGCOMM), pp. 15-30, 2020.
- 李彤 等. 传输控制中的确认机制研究. 软件学报, DOI: [10.13328/j.cnki.jos.000000].