Google的BBR拥塞控制算法

背景

传统基于预测的TCP拥塞控制

  • 以Reno的改进为例,TCP发送端在拥塞避免阶段收到ACK后,无条件地将cwnd增加1/cwnd,在慢启动阶段收到ACK后cwnd增加1,这是毫无根据的,然而Reno并没有什么更好的做法,只能瞎猜!
  • 后来Cubic也改进了一波,搞了一个高大上的以三次方程凸凹曲线来抉择的增窗机制,看似十分地“博士”,并且十分地“经理”,然而还是无法高效利用互联网的空闲带宽,相反在碰到异常现象,比如丢包,拥塞的时候,反应太过保守,在保守的路线上趋于激烈,即激烈地保守降低拥塞窗口,更加可悲的是,这个窗口下降的过程并不受这些算法所控制。

拥堵算法,状态机一人管

  • 拥塞算法内部是受外部的拥塞状态影响的,比如说在Recovery状态下,甚至都不会进入拥塞控制算法,在bbr进入内核之前,Linux使用PRR算法控制了Recovery状态的窗口调整,即便说这个时候网络已经恢复,TCP也无法发现,因为TCP的Recovery状态还未恢复到Open,这就是根源!
  • 按照“上帝的事情上帝管,凯撒的事情凯撒管”的原则,这两件事本来就该由不同的机制来完成,不考虑对端接收窗口的情况下,拥塞窗口是唯一的主导因素,“传输多少数据”这件事应该由拥塞算法来回答,而“传输哪些数据”这个问题应该由TCP拥塞状态机以及SACK分布来决定,诚然这两个问题是不同的问题,不应该杂糅在一起。
  • 在bbr进入内核之前的Linux TCP实现中
  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值