甜品启动速率：2~4 个 RTT 里到底能决定什么？

甜品启动速率2~4 个 RTT 里到底能决定什么一个常见的误解很多人看到“甜品启动速率”这个概念第一反应是算法在第一个 RTT 就把速率提到某个百分比然后疯狂发包。这种理解是错误的。内核的第一道门cwnd 10无论甜品速率算出来是 1 Gbps 还是 100 Mbps实际能发多少包首先受限于内核的初始拥塞窗口。在 Linux 中这个值固定为10 个 MSS约 14 KB。也就是说连接刚建立时无论你期望多高的速度第一个 RTT 内最多只能发 10 个包。后续的发送窗口必须依靠收到的 ACK 来逐步打开。这是一个物理约束不是算法能绕过去的。那么“甜品速率”到底有什么用它是一个指导上限不是瞬时速度。它的作用不是“第一秒就冲到 X Mbps”而是告诉内核的拥塞控制模块你可以按照这个速率去调整 pacing 和 cwnd 的增长步长。换句话说甜品速率决定的是爬坡的斜率而不是起点的位置。2~4 个 RTT 里实际发生了什么以典型的实现为例RTT 1初始 cwnd 10发出少量数据。第一个 ACK 回来后带宽估计模块开始工作。此时速率还远低于链路容量。RTT 2收到更多 ACKcwnd 开始增长pacing 速率按照甜品速率的指导逐步提高。此时仍然远低于瓶颈。RTT 3速率接近瓶颈可能开始出现排队或轻微丢包。RTT 4根据前几轮的反馈算法决定是继续向上爬升还是向下收敛。关键点在前 2 个 RTT 内速率远低于瓶颈算法根本不需要做“向下”的决定——它只需要确认“还能继续向上”。这个判断是每收到一个 ACK 都在做的因此向上的反应是即时的。向下的两种路径当速率真正逼近瓶颈后如果出现拥塞算法有两种降速方式紧急向下检测到丢包后在1 个 RTT 内通过快速恢复机制如 PRR将拥塞窗口减半。有序向下带宽增长停滞且连续多轮确认后才退出启动阶段。这条路径受一个较长的保护窗口例如 8 RTT限制防止误判。所以所谓的“2~4 个 RTT 内决定向上还是向下”指的是算法的核心决策能力——它能在收到足够 ACK 后快速判断方向。向上是每 ACK 都在做紧急向下在出现丢包时 1 RTT 内完成。8 RTT 保护的是什么8 RTT 不是一个反应时间而是一个工程安全窗口。它保护的是有序向下路径防止因短时干扰如测试工具的控制流、应用层空闲而过早退出启动阶段。在高延迟链路RTT 200 ms上这个窗口保证算法有足够多的观测轮次来确认瓶颈是否真的已满而不是误判后提前降速。为什么不是“暴力发包”因为没有哪个正经的拥塞控制算法会无视 cwnd 的限制。cwnd 是内核的硬约束甜品速率再高实际发送也必须等待 ACK 回来才能继续。这个机制天然防止了暴力过冲。总结甜品速率只是一个理论指导值不是实际发送速率。实际发送受限于初始 cwnd 10 和每个 ACK 的反馈。2~4 个 RTT 内算法能够根据反馈判断方向向上即时紧急向下 1 RTT有序向下受 8 RTT 保护。不存在“第一个 RTT 就暴力发包”的情况这是对内核机制和算法设计双重误解。理解这一点就能明白“甜品启动速率”不是什么黑科技它只是利用有限信息设定一个合理的爬坡斜率然后在 2~4 个 RTT 内快速纠偏。它没有消除过冲也没有绕过内核限制它只是让启动过程变得更可控。