TCP BBR拥塞控制算法解析

作者:Liu, Lubin

摘要

2016年底，Google发表了一篇优化tcp传输算法的文章，极大的提高了tcp得throughput，并且已经集成到Linux 4.9 内核。本文给出了论文中省略的一些背景知识，并结合自己的理解做了更加细节的介绍，可以帮助读者理解整个bbr算法。

1.背景

1.1TCP 基于丢包的拥塞控制

TCP拥塞控制将丢包视为网络出现拥塞的信号，以下为其四个主要过程：

引用自参考资料[5]

（1）慢启动阶段（slow start）

当建立新的TCP连接时，拥塞窗口（congestion window,cwnd）初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量，这样cwnd就随着回路响应时间（Round Trip Time,RTT）的增加呈指数增长。

（2）拥塞避免阶段(congestion avoidance)

如果TCP源端发现超时或收到3个相同ACK时，即认为网络发生了拥塞。此时就进入拥塞避免阶段。慢启动阈值（ssthresh）被设置为当前拥塞窗口大小的一半；如果超时，拥塞窗口被置1。当cwnd>ssthresh，TCP就执行拥塞避免算法，此时，cwnd在每次收到一个ACK时只增加1/cwnd个数据包。这样，在一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd线性增长。

（3）快速重传阶段(Fast Retransmit)

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认ACK就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器RTO超时。

（4）快速恢复阶段(Fast Recovery)

与快速重传配合使用，有以下两个要点:
①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，即把ssthresh门限减半。但是接下去并不执行慢开始算法。
②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

2.动机

2.1 基于丢包的拥塞控制算法的两大缺陷

（1）不能区分是拥塞导致的丢包还是错误丢包

基于丢包的拥塞控制方法把数据包的丢失解释为网络发生了拥塞，而假定链路错误造成的分组丢失是忽略不计的，这种情况是基于当时V. Jacobson的观察，认为链路错误的几率太低从而可以忽略，然而在高速网络中，这种假设是不成立的，当数据传输速率比较高时，链路错误是不能忽略的。在无线网络中，链路的误码率更高，因此，