谈谈 tcp 慢启动与拥塞控制_tcp慢启动

慢启动是一种 capacity-search 策略，不限于 tcp，但不说 tcp 慢启动不配标题党，所以就说 tcp 慢启动。

慢启动用指数灌报文的方式快速探测网络容量，所谓 “慢” 是起点慢。值得注意的是，传统慢启动不做 pacing，不做拥塞控制，由于指数灌报文，非常容易拥塞，丢包，指标剧烈抖动导致大部分测量没有意义，平稳流量抖动大多由新进流量慢启动行为导致。

bbr 以 pacing 做拥塞控制，但对慢启动机制并没有太大修正，反而完全适配了传统慢启动，bbr startup 和传统慢启动在效果上一致，这似乎建立在一种很不自然的假设上，即传统慢启动是正确的。但它真的正确吗？和 aimd 一样，它只是简单，能处。

看下 bbr 是如何使用 pacing 和传统慢启动保持一致的。

要保持每个 rtt 增加一倍数据量，设 pacing_rate 为 p，第 x 个 rtt 时满足 $p(x)=2^x$，它由增益 g 获得，不丢包时 delivery_rate 等于 pacing_rate，即 $p(x)=g\ast p(x-1)$。$p$ 作为速率，它是发送量的变化率，对发送量求导可得。为和传统慢启动一致，设发送量为 w，bbr 在第 x 个 rtt 时的发送量为 $w(x)=2^x$，其导数为 $p(x)=w(x{)}^{\prime }=2^x\ln 2$，因此有 $g\ast 2^{x-1}\ln 2=2^x$，解得 $g=\frac{2}{\ln 2}\approx 2.89$

有点故弄玄虚，但最终只是和传统一致。

早在 vegas 被提出时，该算法便对慢启动进行了修正，参见 TCP Vegas: End to End Congestion Avoidance on a Global Internet 的 3.3 Modified Slow-Start Mechanism 小节。但人们对此无动于衷，人们对 cubic 等诸如 hystart 也并不感兴趣。我也写过一篇分析：tcp 慢启动丢包分析。

bbr 的 startup pacing 和 vegas 的 alpha < diff < beta 结合起来是一种高尚的可选，为慢启动增加了拥塞控制。将 diff 划分到不同的区间，在每一个区间调整增益系数 g 的值，随着 diff 的增加，g 逐渐减少，最终由 2.89 降到 1，平滑离开慢启动。

新式慢启动期间丢包也不需被特殊处理，由时间序(如 rack)重传保证。只需计算 diff，根据 diff 计算 g，根据 g 调速，根据 delivery_rate 结果计算 diff，根据 diff 计算 g，这已经不需要单独对待一个叫慢启动的状态了，这是全生命周期内的无级变速：

没有状态机，没有探测，不处理丢包，不修边角。

浙江温州皮鞋湿，下雨进水不会胖。