趣谈TCP协议的缺陷

来自:车小胖谈网络?(微信号:chexiaopangnetwork),作者:车小胖谈网络

如果CWND不变,SRTT越小,发送速率越快。

但一旦网络拥堵,路由器缓存队列使得SRTT变大,所以rate 会变小。

如果缓冲队列尾丢(溢出),意味着有丢包,发送方肯定能检测出,指数减小CWND,这样rate 也会突减1/2。

TCP就是通过这种小速率探测网络拥堵、指数增加发送速度、检测到丢包、发送速率减半、直到不再检测到丢包、线性增长发送速率、检测到丢包、再指数减小发送速率…

TCP流控算法的关键,是基于丢包,有否丢包是唯一的判断依据,是加油门还是踩刹车。

但TCP由于对网络了解的很片面,无法分辨丢包是什么原因造成的

1.?网络真的拥堵而丢包

2. 线路质量差CRC校验失败丢、或信号干扰丢

3. IP包乱序而引起的误判

只有情况1是需要踩刹车的,而情况2、3并不需要。

Google BBR算法则提出基于带宽实时测量的算法,对于每个有数据的TCP包都测量其RTT,动态计算SRTT,这个比传统TCP计算的SRTT更精准,因为传统的TCP是一个SRTT时间周期内测量一次,而不是每个有数据的TCP包都测量。

根据实时带宽值的趋势,是增还是减,如果增,说明带宽还有空间,可以乐观,在当前的delivery rate 的基础上 * 大于1的系数,等于加小油门,发送速率攀升。

如果是减,则需要谨慎,在当前的delivery rate 的基础上 * 小于1的系数,等于小踩刹车,发送速率放缓。

BBR算法不依赖于丢包,可以克服传统TCP对丢包的过分敏感与过激反应,避免发送速率骤增与骤减,使得整体发送速率在一个小范围内波动,更平缓、更平滑。

这是对传统TCP流控算法的一个优化。

至于TCP其他的需要改进的,已经通过TCP option做了补丁,比如:

  • Scaling Window?应对长肥管道

  • Selective ACK??应对高丢包率场景。

  • Timestamp? 应对序列号回滚RTT测量的精度。

  • Authentication Option? 应对数据完整性挑战。

  • TCP Cookie? 应对SYN Flooding?DOS攻击。

  • FAST TCP Open? 应对TCP传输数据延时大。

推荐↓↓↓
程序员的那点事
上一篇:网络延迟是如何产生的?