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

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

层协议, 如 TCP, 确认机制工作在传输层; 针对基于 UDP 的应用层传输协议, 如 QUIC, 确认机制工作在应用层, 其
主要作用是在 UDP 的数据传输能力基础上, 增强应用系统数据传输的可靠性, 或者帮助应用系统数据传输进行拥
塞控制.

数据 发送方 数据 接收方
5 6 7 8 发送缓存 1 2 3 4 接收缓存

丢包恢复 状态监测 接收
状态监测 反馈处理 确认机制
ACK 报文
发送 速率控制
数据报文

图 1 传输控制的功能模块关系

自 1974 年 Cerf 等人 [17] 提出 TCP 以来, TCP 经历了 30 年的持续优化, 并在 2000 年左右确定了基本框架. 基
本框架确定过程中, 有一些关键算法模块也有其各自的演进路线. 其中, 最典型的就是拥塞控制算法和确认机制.
拥塞控制是网络领域经久不衰的、最经典的研究课题之一. 如图 2 所示, 2000 年以后, 随着网络条件和应用需求
的不断演进, 新型的拥塞控制算法如雨后春笋般持续涌现, 在不同的场景和目标中各显神通. 例如, Tan 等人提出
Compound TCP [18] 是 Windows 系统使用的拥塞控制优化算法; Winstein 等人提出适应蜂窝网络带宽抖动的
Sprout [19] 以及基于机器学习的拥塞控制算法 Remy [20] 和 Indigo [21] 等. Cardwell 等人提出 BBR [22] , 被认为是继
CUBIC [23] 以后拥塞控制研究的一个新的里程碑.

LIA OLIA BALIA wVegas

Westwood FAST Remy BBR
DECbit Vegas Eifel Veno Compound TCP LEDBAT PCC Copa

Tahoe Reno NewReno BIC H-TCP CUBIC Sprout Verus Indigo PBR-CC
1980s 1990s 2000s 2010s 2020s
图 2 拥塞控制算法演进

相比拥塞控制, 确认机制相关的工作较少. 如图 3 所示, 确认机制作为传输控制的反馈模块, 20 世纪 90 年代
后很少有大的改动. 这是因为, 人们通常关注正向路径的数据报文传输性能, 却很少关心反向路径上 ACK 报文的
传输. 而且, 确认机制与传输控制中的拥塞控制、丢包恢复和状态监测等模块紧密耦合, 贸然修改确认机制容易导
致副作用. 然而, 在动态变化的网络条件下, 设计更为灵活的、自适应的确认机制, 支撑现代新型业务的多样性, 已
经成为业界迫切的需求 [24] .

Delayed ACK

Periodic ACK
Byte-counting ACK D-SACK
Per-packet ACK SACK NACK HACK TACK
1980s 1990s 2000s 2010s 2020s
图 3 确认机制演进

针对协议的修改, 其鲁棒性严重依赖于充分的单元测试和端到端测试. 在过去, 人们默认使用内核态协议栈
(例如内核 TCP). 由于内存受限、内核接口受限等因素影响, 加上确认机制涉及协议的多个模块的修改, 针对确认