慢启动、拥塞避免、快速重传、快速恢复:
说实话,这些机制完美适应了1980年代的网络特征,低带宽,浅缓存队列,美好持续到了2000年代。
随后互联网大爆发,多媒体应用特别是图片,音视频类的应用促使带宽必须猛增,而摩尔定律促使存储设施趋于廉价而路由器队列缓存猛增,这便是BBR诞生的背景。
正文之前,给出本文的图例:
bbr算法实际上非常简单,在实现上它由5部分组成:
BBR(Bottleneck Bandwidth and Round-trip time)拥塞控制算法是由Google开发的一种现代化的TCP拥塞控制算法。与传统的TCP拥塞控制算法(如TCP Cubic)相比,BBR采用了不同的工作原理和算法策略。
BBR拥塞控制算法具有以下几个显著的优势:
a. 噪声丢包
如果是噪声丢包,在收到reordering个重复ACK后,由于bbr并不区分一个确认是ACK还是SACK引起的,所以在bbr看来,即时带宽并没有降低,可能还有所增加,所以一个数据包的丢失并不会引发什么,bbr依旧会给出一个比较大的cwnd配额,此时虽然TCP可能已经进入了Recovery状态,但bbr依旧按照自己的bw以及调整后的增益系数来计算cwnd的新值,过程中并不会受到任何TCP拥塞状态的影响。
如此一来,所有的噪声丢包就被区别开来了!bbr的宗旨是:“首先,在我的bw计算指示我发生拥塞之前,任何传统的TCP拥塞判断-丢包/时延增加,均全部失效,我并不care丢包和RTT增加”,随后brr又会说:“但是我比较care的是,RTT在一段时间内(随你怎么配,但我个人倾向于自学习)都没有达到我所采集到的最小值或者更小的值!这也许意味着着链路真的发生拥塞了!”…
b. 拥塞丢包
将a的论述反过来,我们就会得到奇妙的封闭性结论。这样,bbr不光是消除了吞吐曲线的锯齿(ssthresh所致,bbr并不使用ssthresh!),而且还消除了传统拥塞控制算法的判断滞后性问题。在cubic发现丢包进而判断为拥塞时,拥塞可能已经缓解了,但是cubic无法发现这一点。为什么?原因在于cubic在计算新的cwnd的时候,并没有把当前的网络状态(比如bw)当作参数,而只是一味的按照数学意义上的三次方程去计算,这是错误的,这不是一个正确的反馈系统的做法!
基于a和b,看到了吧,这就是新的拥塞判断机制!综合考虑丢包和RTT的增加:
b-1.如果丢包时真的发生了拥塞,那么测量的即时带宽肯定会减少,否则,丢包即拥塞就是谎言。
b-2.如果RTT增加时真的发生了拥塞,那么测量的即时带宽肯定会减少,否则,时延增加即拥塞就是谎言。
bbr测量了即时带宽,这个统一cwnd和rtt的计量,完全忽略了丢包,因此bbr的算法思想是TCP拥塞控制的正轨!事实上,丢包本就不应该作为一种拥塞的标志,它只是拥塞的表现。
拥塞控制算法(如TCP拥塞控制算法)的主要目标是通过监测丢包事件来判断网络的拥塞程度,并调整发送速率以缓解拥塞。然而,对于噪声丢包,这些算法并不会做出相应的调整,因为噪声丢包并不表示网络拥塞。因此,对于拥塞控制算法来说,区分噪声丢包和拥塞丢包是非常重要的。
的调整,因为噪声丢包并不表示网络拥塞。因此,对于拥塞控制算法来说,区分噪声丢包和拥塞丢包是非常重要的。
BBR拥塞控制算法在这方面相对于传统算法具有优势,它通过观察发送数据包的出队情况和接收确认ACK的延迟时间,估计网络的瓶颈带宽,并使用这些信息来动态调整发送速率。BBR算法在设计上能够更好地识别和应对拥塞丢包,从而提供更好的网络性能和拥塞控制。