我们为什么不能多丢点儿TCP的ACK报文呢？

TCP的拥塞控制需要ACK形成的self-clock来促使数据包的继续发送，但这只是1988年范雅各布森的观点，即 保持VJ管道的满载但不溢出的理想 。

显然，这个理想直到今天也没有实现。后来BBR把VJ管道改造了，以pacing rate而不是cwnd进行拥塞控制，然而不管怎么说，pacing rate也是依赖ACK的，只是没有AIMD那么重度依赖而已，self-clock可以弱化，甚至取消。

这意味着不需要连续的ACK了，只要能采集到一个max bandwidth，并且在一个既定的max-filter函数里保持，就可以持续以计算好的pacing rate发送数据。

以前在数据包守恒和AIMD原则共同作用下，ACK必须持续不断到来，现在ACK只需要在max-filter范围内确保能测速即可。这意味着什么？

这意味着midbox可以随机或者故意丢弃一些pure ACK报文了，我们来看丢了这些pure ACK报文可以带来什么收益。

• 弱网环境/半双工环境的box不再需要为了处理pure ACK而进行共享资源的arbitration。
• 加解密box不再需要为了处理仅仅提供self-clock的pure ACK而消耗CPU，节能减排。
• midbox们不再需要为了兼顾pure ACK而设计复杂的AQM系统，降低了控制平面的复杂度。
• …

所以，如果你有一个pacing rate的计算方法，那就抛弃持续不断的ACK吧。你可能受到过灌输，然后觉得持续不断的ACK是不可缺失的，怎么能没有ACK呢？…具体参考BBRv2是如何在没有持续ACK的情况下估算pacing rate的。

有点意思的是，ACK形成的self-clock本来是用于滑动窗口控制，而不是拥塞窗口控制的。

…

max-filter不完美，但它是个开始。这个基于时间窗口的filter难道没有意味着什么吗？它正是在摆脱对ACK流的持续性依赖。

我的建议是，若想提高单机传输性能，在你使用BBR或者自研算法的前提下，那就在更底层丢掉更多的pure ACK报文吧！ 事实上，对于自研算法，这背后有另一层意思，如果是自研算法，你们TMD还依赖ACK吗？谢特了。当然了，这篇短文是中文写的，也就针对中文圈子的TCP加速厂商了，哦，那是我憎恨的领域。

有什么好办法吗？幸运的是我早就已经不在这个领域做事了，所以在我没事的时候，我可以仔细想想。

---

Zhejiang Wenzhou skinshoe wet，down rain enter water not can fat.
浙江温州皮鞋湿，下雨进水不会胖。