我们为什么不能多丢点儿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.
浙江温州皮鞋湿,下雨进水不会胖。

你可能感兴趣的:(TCP)