TCP 慢启动会导致持续突发丢包。

慢启动以 $y=2^x$ 增加窗口，在 BDP 已经填满时，后续的慢启动过程如下：

​每一个 ACK 触发 2 个 报文，最终至少丢掉 1 个 BDP 的数据后 sender 才能检测到丢包而退出慢启动并进行重传。

这是尾丢的结果，现实中很少部署尾丢，因此很难实际观测到该结果，但这是慢启动的理论伤。

HyStart 可以解决该问题，可以参考 Linux CUBIC 代码的实现，还有一个 HyStart++ 算法：HyStart++: Modified Slow Start for TCP

但这些都很难奏效，和 BBR 很难达到预期的原因一样，这些依托的都是理想模型，而现实并不是。连 RTT 测量都不能算数，需要一个移指平均也不能太算数，何况 HyStart 的测量。

现实的做法是 “不要总以 2 倍为增量”。一开始以 2 倍为增加，后续逐渐递减，比如以 1.5 倍为增量时，即收到 2 个 ACK 后增加 3 个 cwnd，以此类推：
​
绿色曲线在后期比红色曲线平缓很多，丢包就减少很多，缓慢的增速虽然更慢探测到最大带宽，但也不算太慢，相反，优点有两个，首先减缓的慢启动过程增加的延迟大概率小于大量丢包重传增加的延迟，其次，减少了丢包重传在全局上提高了带宽利用效能。

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