TCP/IP拥塞控制总结...

r囧r小猫 2022-08-29 09:46 109阅读 0赞

## 一.先唠唠嗑 ##

按照计划，今天该出分布式一致性系列的第四篇-Paxos算法，但是又鸽了。

Paxos这个算法要很好地表达写出来并不容易，所以到现在还没有完成，于是就有了这篇**组装的**带有丝丝标题党感觉的干货文章，**全小区最强TCP/IP总结...逃...**

在正式开始文章技术点之前，想先聊一下**我对面试中的TCP/IP问题的一些拙见**，希望对盆友们有所帮助。

在招聘岗位描述中，几乎必然有一条熟悉、掌握、精通TCP/IP协议、Http协议、网络编程技术。

对于我们求职者来说，**肯定知道的越多越好，但是就像过日子一样钱要花在刀刃上，准备面试也是一样的**，我们该怎么准备这部分呢？

我个人认为合理的优先级排序是：**网络编程技术 > Http协议 > TCP/IP协议热点问题 > TCP/IP协议普通问题**。

![图片][e5792a39bf3204fa0c100f10df58e274.png]

**从面试官的角度来说**，面试中还是要注重实战，问一些边边角角的细节或者自己平时遇到的奇怪问题，并不能探测出**侯选人的边界**，反而让侯选人觉得这个面试官抓不住重点。

有时候遇到一些侯选人说自己哪块掌握的比较好，那可以交流一下，比如之前遇到侯选人说自己读过Redis源码，顿时让我很有兴趣，简单了解了对方阅读的版本之后，就开始切磋，很快就可以探测出侯选人的所说的Redis源码边界。

回到网络这块，C/C++的话轮子比较少，有时候需要自己搞一个Socket写个小型的服务端或者客户端，像Python/Go这些语言做的已经非常好了，可能不到5行一个简单的echo服务就跑起来了。因为之前自己是写C++服务端的，回忆起第一次用Python的Tornado框架写服务，着实被惊艳了，开发速度着实很快，性能也很不错。

说这个的目的在于，如果**对于时间紧任务重的求职者就不要胡子眉毛一把抓，抓几个重点问题好好理解一下就可以了**，如果真遇到问边角问题的面试，那也不必懊恼，可能大概率以后共事脑回路也不一样，还是相忘于江湖比较好。

在掌握一些重点问题的面试套路和回答之后，还是**建议去深入了解一些这些技术细节，更多的是去培养和锻炼我们思考问题的方法和意识**，之前在知乎就有这样的问题，就像研究往年的高考题一样，**我们去思考TCP/IP在发展过程中的问题以及解决方案，并且当前存在的瓶颈作出自己的判断和思考，都是很有益的**。

我想这也是打开TCP/IP的正确方式吧：**实战派和训练思维派**。

今天和大家一起学习下TCP/IP中的热点问题：**拥塞控制**。本文本着实战和思维训练兼顾的原则将从以下几个方面展开：

*  **拥塞控制的算法策略分类**
 *  **拥塞控制出现的意义和目的**
 *  **实现拥塞控制的几种算法和侧重点**
 *  **拥塞控制的主要过程和关键点**
 *  **BBR算法的一些原理和思路**

## 2. 我和TCP/IP协议 ##

我在5年前研究生刚毕业的时候，在一家做深度包检测DPI的公司待了差不多两年，可能读者要问啥是**深度包检测**？

简单提一下哈，深度包检测 DPI (**Deep Packet Inspection**)就是**识别TCP/IP网络协议中各种各样的报文，来进行流量管控和分析，在网络安全领域应用很多，属于通信&互联网领域的交叉业务**。

整个DPI系统是非常复杂的，目前业界有**硬件DPI和软件DPI**两种主流类型，硬件的吞吐量大造价也高，软件的比较灵活成本也相对低廉。

当时每天的工作就是抓包分析、用C++写业务插件来处理各种**丢包/乱序/重传**问题等等，有时候业务需要还要单独开发wireshark的插件来解析自定义的报文。

现在看看这份工作开启了我和TCP/IP协议网络的友谊之门。

在刚毕业前3年换工作的时候，几乎总会被问到TCP/IP协议的一些东西，碰到一些专业人士问的就比较深入，好在近两年的经验让这些问题基本都在射程之内。

所以**经历都是财富**，好好学一下，说不准哪天就派上用场了呢。

## 三. 走心推荐 ##

TCP/IP协议是一个协议族，如果真的非常感兴趣或者工作需要**建议直接卷一卷二卷三**，但是对于大多数读者来说，应付面试或者平时排查问题掌握一些重点内容也就够了。

TCP/IP详解的三本书**译文难免失真**，有决心和兴趣的同学可以搞几本英文原版的，这是豆瓣读书上的一些评分：

![图片][042d3ca31878fa91f31f22410ac98691.png]

![图片][ecd7f4561c482e996e94fb7793353c9a.png]

![图片][9d8dba2727cdb6e057c781a5445da958.png]

## 四.聊聊拥塞控制算法 ##

我们知道TCP/IP协议栈是一个简化的分层模型，是互联网世界连接一切的基石，一起来看一张**七层模型vs四层模型**的简图：

![图片][f1cbc7f49c67104028122c10be86623e.png]

看到一篇文章说到TCP拥塞控制算法并不是简单的计算机网络的概念，也属于**控制论范畴**，感觉这个观点很道理。

TCP拥塞控制算法的目的可以简单概括为：**公平竞争、充分利用网络带宽、降低网络延时、优化用户体验，然而就目前而言要实现这些目标就难免有权衡和取舍。**

但是现在的网络通信基础设施水平一直在飞速提高，相信在未来的某个时间点这些目标都可以达到，小孩子才选择，我们大人全都要！

### 算法演进 ###

在理解拥塞控制算法之前我们需要明确一个核心的思想：**闻道有先后 术业有专攻**，笔者觉得这是一个非常重要的共识问题，把A踩在泥土里，把B吹捧到天上去，都不是很好的做法。

实际的网络环境十分复杂并且变化很快，并没有哪个拥塞控制算法可以全部搞定，每一种算法都有自己的特定和适用领域，每种算法都是对几个关键点的权衡，在无法兼得的条件下有的算法选择带宽利用率，有的算法选择通信延时等等。

在明确这个共识问题之后，**我们对待各个拥塞控制算法的态度要平和一些，不要偏激地认为谁就是最好**，几十年前的网络状况和现在是截然不同的，**我们永远都是站在巨人的肩膀之上的**，这也是科学和文明进步的推动力。

### 算法分类 ###

传统拥塞控制算法并不是一蹴而就的，复杂的网络环境和用户的高要求推动着拥塞控制算法的优化和迭代，我们看下**基于丢包策略**的传统拥塞控制算法的几个迭代版本，如图所示：

![图片][36b27b6f8788de49a228c0e71ce3d8ac.png]

与此同时还有一类算法是基于RTT延时策略来进行控制的，但是这类算法在发包速率上可能不够激进，竞争性能不如其他算法，因此在共享网络带宽时有失公平性，但是算法速率曲线却是很平滑。

![图片][a08a8624dd933fb80a8d7e0400e55c01.png]

### 4.1 流量控制和拥塞控制 ###

大约在1988年之前TCP/IP是没有拥塞控制的，但是随着网络接入规模的发展之前仅有的端到端窗口控制已经无法满足要求，在1986年引发大规模网络瘫痪，此时就要提到一个重量级人物：**Van Jacobson范·雅各布森**。

这位力挽狂澜的人物入选了**计算机名人堂Internet Hall of Fame**，Van Jacobson大神提出并设计实施了TCP/IP拥塞控制，解决了当时最大的问题，来简单看下Van Jacobson的维基百科简介(笔者做了部分删减)：

> 范·雅各布森Van Jacobson是目前作为互联网技术基础的TCP/IP协议栈的主要起草者，他以其在网络性能的提升和优化的开创性成就而闻名。

> 2006年8月，他加入了帕洛阿尔托研究中心担任研究员，并在位于相邻的施乐建筑群的Packet Design公司担任首席科学家。在此之前，他曾是思科系统公司首席科学家，并在位于劳伦斯伯克利国家实验室的网络研究小组任领导者。

> 范·雅各布森因为在提高IP网络性能提升和优化所作的工作而为人们所知，1988到1989年间，他重新设计了TCP/IP的流控制算法（Jacobson算法），他因设计了RFC 1144中的TCP/IP头压缩协议即范·雅各布森TCP/IP头压缩协议而广为人知。此外他也曾与他人合作设计了一些被广泛使用的网络诊断工具，如traceroute，pathchar以及tcpdump 。

> 范·雅各布森于2012年4月入选第一批计算机名人堂，计算机名人堂简介：https://www.internethalloffame.org/inductees/van-jacobson

如图为Van Jacobson计算机名人堂的简介：

![图片][64911c0684ca9324e6faeea3b02b6684.png]

笔者找了Van Jacobson和Michael J. Karels在1988年11月发布的关于拥塞避免和控制的论文，总计25页，感兴趣的读者可以查阅：

> https://ee.lbl.gov/papers/congavoid.pdf

我们常用的traceroute和tcpdump也是van-jacobson大神的杰作，作为互联网时代的受益者不由得对这些互联网发展早期做出巨大贡献的开拓者、创新者、变革者心生赞叹和敬意。

海尔兄弟一样的算法：**流量控制和拥塞控制**，这也是我们今天的主角。

![图片][0ee22edf9c9a6634a54bcda25f3d72e8.png]

流量控制和拥塞控制从汉语字面上并不能很好的区分，本质上这一对算法既有区别也有联系。

维基百科对于流量控制Flow Control的说明：

> In data communications, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver.

> It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node.

> 在数据通信中，流量控制是管理两个节点之间数据传输速率的过程，以防止快速发送方压倒慢速接收方。它为接收机提供了一种控制传输速度的机制，这样接收节点就不会被来自发送节点的数据淹没。

> 可以看到流量控制是通信双方之间约定数据量的一种机制，具体来说是借助于TCP协议的确认ACK机制和窗口协议来完成的。

窗口分为固定窗口和可变窗口，可变窗口也就是滑动窗口，**简单来说就是通信双方根据接收方的接收情况动态告诉发送端可以发送的数据量，从而实现发送方和接收方的数据收发能力匹配**。

这个过程非常容易捕捉，使用wireshark在电脑上抓或者tcpdump在服务器上抓都可以看到，大白在自己电脑上用wireshark抓了一条：

![图片][e0855efb1b5a4329c4bbfbcd18c6f382.png]

我们以两个主机交互来简单理解流量控制过程：

![图片][a3725d22954b931b9ff3f7a0a4caaf96.png]

接收方回复报文头部解释：

![图片][23c9c7961cba7e13cb08924fbd78e8d8.png]

> 图中RcvBuffer是接收区总大小，buffered data是当前已经占用的数据，而free buffer space是当前剩余的空间，rwnd的就是free buffer space区域的字节数。

> HostB把当前的rwnd值放入报文头部的接收窗口receive window字段中，以此通知HostA自己还有多少可用空间， 而HostA则将未确认的数据量控制在rwnd值的范围内，从而避免HostB的接收缓存溢出。

可见**流量控制是端到端微观层面的数据策略**，双方在数据通信的过程中并不关心链路带宽情况，只关心通信双方的接收发送缓冲区的空间大小，可以说是个速率流量匹配策略。

**流量控制就像现实生活中物流领域中A和B两个仓库，A往B运送货物时只关心仓库B的剩余空间来调整自己的发货量，而不关心高速是否拥堵**。

### 4.2 为什么需要拥塞控制 ###

前面我们提到了微观层面点到点的流量控制，但是我们不由地思考一个问题：**只有流量控制够吗？答案是否定的**。

我们还需要一个宏观层面的控去避免网络链路的拥堵，否则再好的端到端流量控制算法也面临丢包、乱序、重传问题，只能造成恶性循环。

![图片][cd1adcf5483f930f9f236313b7c7958f.png]

我们从一个更高的角度去看大量TCP连接复用网络链路的通信过程：

![图片][ac128127c72e51c3a1e8b4fb3ff1218e.png]

所以拥塞控制和每一条端到端的连接关系非常大，这就是流量控制和拥塞控制的深层次联系，所谓每一条连接都顺畅那么整个复杂的网络链路也很大程度是通畅的。

![图片][b1bddf41e5f9f80d6f283b1104beb0df.png]

在展开拥塞控制之前我们先考虑几个问题：

*  **如何感知拥塞**

TCP连接的发送方在向对端发送数据的过程中，需要根据当前的网络状况来调整发送速率，所以感知能力很关键。

在TCP连接的发送方一般是基于丢包来判断当前网络是否发生拥塞，丢包可以由重传超时RTO和重复确认来做判断。

![图片][fd576cc9875bd0a260460ef410d631fe.png]

*  **如何利用带宽**

诚然拥塞影响很大，但是一直低速发包对带宽利用率很低也是很不明智的做法，因此要充分利用带宽就不能过低过高发送数据，而是保持在一个动态稳定的速率来提高带宽利用率，这个还是比较难的，就像茫茫黑夜去躲避障碍物。

*  **拥塞时如何调整**

拥塞发生时我们需要有一套应对措施来防止拥塞恶化并且恢复连接流量，这也是拥塞控制算法的精要所在。

### 4.3 拥塞控制的细节 ###

前面我们提了拥塞控制的必要性以及重要问题，接下来一起看下前辈们是如何设计实现精彩的拥塞控制策略的吧！

4.3.1 拥塞窗口cwnd

从流量控制可以知道接收方在header中给出了rwnd接收窗口大小，发送方不能自顾自地按照接收方的rwnd限制来发送数据，因为网络链路是复用的，需要考虑当前链路情况来确定数据量，这也是我们要提的另外一个变量cwnd，笔者找了一个关于rwnd和cwnd的英文解释：

> Congestion Window (cwnd) is a TCP state variable that limits the amount of data the TCP can send into the network before receiving an ACK.

> The Receiver Window (rwnd) is a variable that advertises the amount of data that the destination side can receive.

> Together, the two variables are used to regulate data flow in TCP connections, minimize congestion, and improve network performance.

笔者在rfc5681文档中也看到cwnd的定义：

![图片][b3e565f22786fe82e1a58cfa8d519793.png]

这个解释指出了cwnd是在发送方维护的，**cwnd和rwnd并不冲突**，发送方需要结合rwnd和cwnd两个变量来发送数据，如图所示：

![图片][1869861cea6ec9101020375f8586d9f2.png]

cwnd的大小和MSS最大数据段有直接关系，MSS是TCP报文段中的数据字段的最大长度，即MSS=TCP报文段长度-TCP首部长度。

4.3.2 拥塞控制基本策略

**拥塞控制是一个动态的过程**，它既要提高带宽利用率发送尽量多的数据又要避免网络拥堵丢包RTT增大等问题，基于这种高要求并不是单一策略可以搞定的，因此TCP的**拥塞控制策略实际上是分阶段分策略的综合过程**：

![图片][a9956ce5fd6c8dc2e05c766fab2a78a3.png]如图为典型的包含4个策略的拥塞控制：

![图片][4510a5790241d2ae4f491b8acc2326ab.png]

如图为发生超时重传RTO时的过程：

![图片][94c4d20582c300106605c285183578c9.png]

### 4.4 拥塞控制过程详解 ###

我们以典型**慢启动、拥塞避免、快速重传、快速恢复**四个过程进行阐述。

*  **慢启动**

慢启动就是对于刚启动的网络连接，发送速度不是一步到位而是试探性增长，具体来说：连接最初建立时发送方初始化拥塞窗口cwnd为m，之后发送方在一个RTT内每收到一个ACK数据包时cwnd线性自增1，发送方每经过一个RTT时间，cwnd=cwnd\*2指数增长，经过一段时间增长直到cwnd达到慢启动阈值ssthresh。

之后cwnd不再呈指数增长从而进入拥塞避免阶段(注cwnd增长的单位是MSS)，当然如果在慢启动阶段还未到达阈值ssthresh而出现丢包时进入快速重传等阶段，需要注意的是如果网络状况良好RTT时间很短，那么慢启动阶段将很快到达一个比较高的发送速率，所以将慢启动理解为试探启动更形象。

![图片][069a78c6f89505d9def737b1642cd45b.png]

*  **拥塞避免**

当慢启动阶段cwnd的值到达ssthresh时就不再疯狂增长，进入更加理性的线性阶段直至发送丢包，本次的阈值ssthresh是上一次发生丢包时cwnd的1/2，因此这是一个承上启下的过程。

本次发送丢包时仍然会调整ssthresh的值，具体拥塞避免增长过程：发送方每收到一个ACK数据包时将cwnd=cwnd+1/cwnd，每经过一个RTT将cwnd自增1。

*  **超时重传和快速重传**

TCP作为一个可靠的协议面临的很大的问题就是丢包，丢包就要重传因此发送方需要根据接收方回复的ACK来确认是否丢包了，并且发送方在发送数据之后启动定时器，如图所示：

![图片][cd8f1dc4507453b34c86b7f304561ade.png]

RTO是随着复杂网络环境而动态变化的，在拥塞控制中发生超时重传将会极大拉低cwnd，如果网络状况并没有那么多糟糕，偶尔出现网络抖动造成丢包或者阻塞也非常常见，因此触发的慢启动将降低通信性能，故出现了快速重传机制。

所谓快速重传时相比超时重传而言的，重发等待时间会降低并且后续尽量避免慢启动，来保证性能损失在最小的程度，如图所示：

![图片][4677157ce111f37c5f8eeb1aa3ac7f6a.png]

快速重传和超时重传的区别在于cwnd在发生拥塞时的取值，超时重传会将cwnd修改为最初的值，也就是慢启动的值，快速重传将cwnd减半，二者都将ssthresh设置为cwnd的一半。

从二者的区别可以看到，快速重传更加主动，有利于保证链路的传输性能，但是有研究表明3个ACK的机制同样存在问题，本文就不做深入阐述了，感兴趣的读者可以自主查阅。

快速重传是基于对网络状况没有那么糟糕的假设，因此在实际网络确实还算好的时候，快速重传还是很有用的，在很差的网络环境很多算法都很难保证效率的。

*  **快速恢复**

在快速重传之后就会进入快速恢复阶段，此时的cwnd为上次发生拥塞时的cwnd的1/2，之后cwnd再线性增加重复之前的过程

### 4.5 TCP算法版本和拥塞控制 ###

实际上TCP算法有很多版本，每个版本存在一些差异，在这里简单看一下维基百科的介绍：

*  **算法命名规则**

TCP+算法名的命名方式最早出现在Kevin Fall和Sally Floyd1996年发布的论文中。

*  **TCP Tahoe 和TCP Reno**

> 这两个算法代号取自太浩湖Lake Tahoe和里诺市，两者算法大致一致，对于丢包事件判断都是以重传超时retransmission timeout和重复确认为条件，但是对于重复确认的处理两者有所不同，对于超时重传RTO情况两个算法都是将拥塞窗口降为1个MSS，然后进入慢启动阶段。

> TCP Tahoe算法：如果收到三次重复确认即第四次收到相同确认号的分段确认，并且分段对应包无负载分段和无改变接收窗口的话，Tahoe算法则进入快速重传，将慢启动阈值改为当前拥塞窗口的一半，将拥塞窗口降为1个MSS，并重新进入慢启动阶段。

> TCP Reno算法：如果收到三次重复确认，Reno算法则进入快速重传只将拥塞窗口减半来跳过慢启动阶段，将慢启动阈值设为当前新的拥塞窗口值，进入一个称为快速恢复的新设计阶段。TCP New Reno

> TCP New Reno是对TCP Reno中快速恢复阶段的重传进行改善的一种改进算法，New Reno在低错误率时运行效率和选择确认SACK相当，在高错误率仍优于Reno。

*  **TCP BIC 和TCP CUBIC**

> TCP BIC旨在优化高速高延迟网络的拥塞控制，其拥塞窗口算法使用二分搜索算法尝试找到能长时间保持拥塞窗口最大值，Linux内核在2.6.8至2.6.18使用该算法作为默认TCP拥塞算法。

> CUBIC则是比BIC更温和和系统化的分支版本，其使用三次函数代替二分算法作为其拥塞窗口算法，并且使用函数拐点作为拥塞窗口的设置值，Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法。

*  **TCP PRR**

> TCP PRR是旨在恢复期间提高发送数据的准确性，该算法确保恢复后的拥塞窗口大小尽可能接近慢启动阈值。在Google进行的测试中，能将平均延迟降低3~10%恢复超时减少5%，PRR算法后作为Linux内核3.2版本默认拥塞算法。TCP BBR

> TCP BBR是由Google设计于2016年发布的拥塞算法，该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法。

> Google在YouTube上应用该算法，将全球平均的YouTube网络吞吐量提高了4%，BBR之后移植入Linux内核4.9版本。

其中比较有名的Vegas算法是大约在1995年由亚利桑那大学的研究人员拉里·彼得森和劳伦斯·布拉科夫提出，这个新的TCP拥塞算法以内华达州最大的城市拉斯维加斯命名，后成为TCP Vegas算法。

关于基于RTT的TCP Vegas算法的详细介绍可以查阅文档：

> http://www.cs.cmu.edu/~srini/15-744/F02/readings/BP95.pdf

文档对Vegas算法和New Reno做了一些对比，我们从直观图形上可以看到Vegas算法更加平滑，相反New Reno则表现除了较大的波动呈锯齿状，如图所示：

![图片][1dcbd5ae434d0b3e7137b0051d850e08.png]

实际上还有更细粒度的分类，由于不是今天的重点，就不再深入展开了，当前使用的拥塞控制算法还是基于丢包Loss-Based作为主流。

## 五.复杂的网络环境和拥塞控制 ##

我们知道在网络链路中连接的数量是动态变化且数量巨大的，每一条连接都面临着一个黑盒子式的网络环境，这并不像我们平时出行时看看地图就知道哪里堵了，为了维护一个好的网络环境，每一条连接都需要遵守一些约定。

如果连接端都无所顾忌地发生数据包，那么网络链路很快就到了瓶颈了，数据通信完全无法保障，所以要到达一个稳定高效的网络环境还是需要费很大心思的，这其中有两个重要的概念：**公平性和收敛性**。

说来惭愧笔者在网络上找了很多资料去理解TCP拥塞控制的公平性和收敛性，但是仍然没有获得一个很好的权威解释，所以只能结合一些资料和自身的理解去阐述所谓的公平性和收敛性。

### 5.1 AIMD特性 ###

笔者认为公平性是相对于网络链路中的所有连接而言的，这些共享链路的连接启动和结束的时间不同，在实际的交互过程中每条连接占有带宽的机会是均等的，并且由于带宽限制连接双方通信的数据量是动态调整并且近似收敛于某个值，也就是呈现一个锯齿状或者更加平滑的波动曲线，对于基于丢包的拥塞控制算法而言AIMD线性增乘性减策略起了关键控制作用。

接下来我们来重点看下**AIMD特性**，先来贴一张经典的图，直观看AIMD的过程：

![图片][e0dce948dc41e14dc6d7475c9662346a.png]

看看维基百科对于AIMD的定义：

> The additive-increase/multiplicative-decrease(AIMD) algorithm is a feedback control algorithm best known for its use in TCP congestion control.

> AIMD combines linear growth of the congestion window with an exponential reduction when congestion is detected.

> Multiple flows using AIMD congestion control will eventually converge to use equal amounts of a shared link.

> The related schemes of multiplicative-increase/multiplicative-decrease (MIMD) and additive-increase/additive-decrease (AIAD) do not reach stability.

简单翻译一下：**线性增加乘性减少算法是一个反馈控制算法**，因其在TCP拥塞控制中的使用而广为人知，AIMD将线性增加拥塞窗口和拥塞时乘性减少窗口相结合，基于AIMD的多个连接理想状态下会达到最终收敛，共享相同数量的网络带宽，与其相关的乘性增乘性减MIMD策略和增性加增性减少AIAD都无法保证稳定性。

AIMD相比MIMD和AIAD在连接进入拥塞避免阶段使用试探线性加策略而不是乘性加策略更加安全，在探测丢包时则大幅度乘性减少到1/2这样对于缓解拥塞会有比较好的效果更加快速，相反如果探测到丢包时采用线性减少AD可能拥塞持续的时间会更长，总体来说**AIMD算是一个比较简单实用的工程版本的反馈控制，也具备可工程收敛性**，因而被广泛实用。

### 5.2 弱网络环境下的AIMD ###

时间拉回20多年前，在互联网早期几乎所有的设备都是通过有线网络进行连接通信的，这也是拥塞控制在设计之后一直都起到不错作用的重要因素，有线连接的网络稳定性比较好，因此把丢包作为网络拥堵的一个特征也很正常。

再拉回到现在，从2010年之后移动互联网蓬勃发展，移动终端的持有量已经可以称为海量，无线网络的引入让网络环境变得更加复杂，因此不稳定丢包变得更加频繁，但是这时的丢包就不一定是网络拥堵造成的了，因为整个数据包经过多重路由、交换机、基站等基础通信设备每个环节都可能发生异常。

在弱网环境下，尤其是**移动互联网中之前的基于AIMD的拥塞控制策略可能会由于丢包的出现而大幅降低网络吞吐量**，从而对网络带宽的利用率也大大下降，这时我们采用更加激进的控制策略，或许可以获得更好的效果和用户体验。

恶意丢包的情况下，基于AIMD的拥塞控制确实就相当于被限速了，因为AIMD确实有些保守谨慎了，这个其实也很好理解的哈。

我们都知道在移动网络环境下是由终端以无线形式和附近的基站交互数据，之后数据传输至核心网，最后落到具体的服务器所在的有线网络，其中最后一公里的区域属于高延时场景，有线网络属于低延时高带宽场景。

在国外有相关实验证明弱网环境下RTT的变化对于使用传统拥塞控制算法下网络吞吐量的影响，数据和曲线如图所示：

![图片][a0718cf34613f691a61f381d7d0d25ac.png]

![图片][178c56cc0557ded787871a3e6b6a36d6.png]

实验含义：RTT的增大影响了比如CUBIC这类拥塞控制算法的慢启动等阶段，我们知道慢启动阶段每经过1个RTT周期拥塞窗口cwnd将加倍，但是更大的RTT就意味着发送方以很低的速率发送数据，更多的时间是空闲的，发包的加速度极大将低了，所以整个吞吐量就下降很明显。

看下实验者的原文表述：

> The delay before acknowledgment packets are received (= latency) will have an impact on how fast the TCP congestion window increases (hence the throughput).

> When latency is high, it means that the sender spends more time idle (not sending any new packets), which reduces how fast throughput grows.

## 六.强悍的BBR算法 ##

**BBR算法是个主动的闭环反馈系统**，通俗来说就是根据带宽和RTT延时来不断动态探索寻找合适的发送速率和发送量。

看下维基百科对BBR算法的说明和资料：

> 相关文献：https://queue.acm.org/detail.cfm?id=3022184

> TCP BBR(Bottleneck Bandwidth and Round-trip propagation time)是由Google设计，并于2016年发布的拥塞算法，以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR基于模型主动探测。

> 该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。

> 该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法例如CUBIC。

> Google在YouTube上应用该算法，将全球平均的YouTube网络吞吐量提高了4%，在一些国家超过了14%。BBR之后移植入Linux内核4.9版本，并且对于QUIC可用。

### 6.1 丢包反馈策略存在的问题 ###

基于丢包反馈属于被动式机制，根源在于**这些拥塞控制算法依据是否出现丢包事件来判断网络拥塞做减窗调整**，这样就可能会出现一些问题：

*  **丢包即拥塞**  
    现实中网络环境很复杂会存在错误丢包，很多算法无法很好区分拥塞丢包和错误丢包，因此在存在一定错误丢包的前提下在某些网络场景中并不能充分利用带宽。
 *  **缓冲区膨胀问题BufferBloat**  
    网络连接中路由器、交换机、核心网设备等等为了平滑网络波动而存在缓冲区，这些缓存区就像输液管的膨胀部分让数据更加平稳，但是Loss-Based策略在最初就像网络中发生数据类似于灌水，此时是将Buffer全部算在内的，一旦buffer满了，就可能出现RTT增加丢包等问题，就相当于有的容量本不该算在其中，但是策略是基于包含Buffer进行预测的，特别地在深缓冲区网络就会出现一些问题。
 *  **网络负载高但无丢包事件**  
    假设网络中的负载已经很高了，只要没有丢包事件出现，算法就不会主动减窗降低发送速率，这种情况下虽然充分利用了网络带宽，同时由于一直没有丢包事件出现发送方仍然在加窗，表现出了较强的网络带宽侵略性，加重了网络负载压力。
 *  **高负载丢包**  
    高负载无丢包情况下算法一直加窗，这样可以预测丢包事件可能很快就出现了，一旦丢包出现窗口将呈现乘性减少，由高位发送速率迅速降低会造成整个网络的瞬时抖动性，总体呈现较大的锯齿状波动。
 *  **低负载高延时丢包**  
    在某些弱网环境下RTT会增加甚至出现非拥塞引起丢包，此时基于丢包反馈的拥塞算法的窗口会比较小，对带宽的利用率很低，吞吐量下降很明显，但是实际上网络负载并不高，所以在弱网环境下效果并不是非常理想。

### 6.2 TCP BBR算法基本原理 ###

前面我们提到了一些Loss-Based算法存在的问题，TCP BBR算法是一种主动式机制，简单来说BBR算法不再基于丢包判断并且也不再使用AIMD线性增乘性减策略来维护拥塞窗口，而是分别**采样估计极大带宽和极小延时，并用二者乘积作为发送窗口**，并且BBR引入了Pacing Rate限制数据发送速率，配合cwnd使用来降低冲击。

说起BBR算法总让我想起一款小游戏flappy bird：

![图片][50fa7c09c303e88ab7b848eb6a211700.png]

我们需要不断调整bird的飞行高度，但是过高过低震荡太多就很容易挂掉，所以如果能够平滑一些或许会飞得更远哦！

在开始BBR算法之前，我们先来了解几个有用的术语：

*  **BDP带宽延时积**

BDP是Bandwidth-Delay Product的缩写，可以翻译为带宽延时积，我们知道带宽的单位是bps(bit per second)，延时的单位是s，这样BDP的量纲单位就是bit，从而我们知道BDP就是衡量一段时间内链路的数据量的指标。这个可以形象理解为水管灌水问题，带宽就是水管的水流速度立方米/s，延时就是灌水时间单位s，二者乘积我们就可以知道当前水管内存储的水量了，这是BBR算法的一个关键指标，来看一张陶辉大神文章中的图以及一些网络场景中的BDP计算：

![图片][783ec40fff1384b7723f67f10ef32a59.png]

*  **长肥网络**

我们把具有长RTT往返时间和高带宽的网络成为长肥网络或者长肥管道，它的带宽延时积BDP很大大，这种网络理论上吞吐量很大也是研究的重点。

*  **TCP Pacing机制**

可以简单地理解TCP Pacing机制就是将拥塞控制中数据包的做平滑发送处理，避免数据的突发降低网络抖动。

6.2.1 TCP带宽和延时的测量

BBR算法的一些思想在之前的基于延时的拥塞控制算法中也有出现，其中必有有名的是TCP WestWood算法。

> TCP Westwood改良自New Reno，不同于以往其他拥塞控制算法使用丢失来测量，其通过对确认包测量来确定一个合适的发送速度，并以此调整拥塞窗口和慢启动阈值。其改良了慢启动阶段算法为敏捷探测和设计了一种持续探测拥塞窗口的方法来控制进入敏捷探测，使链接尽可能地使用更多的带宽。

TCP WestWood算法也是基于带宽和延时乘积进行设计的，但是带宽和延时两个指标无法同时测量，因为这两个值是有些矛盾的极值，要测量最大带宽就要发送最大的数据量但是此时的RTT可能会很大，如果要测量最小的RTT那么久意味着数据量非常少最大带宽就无法获得。

TCP BBR算法采用交替采样测量两个指标，取一段时间内的带宽极大值和延时极小值作为估计值，具体的实现本文就不展开了。

6.2.2 发送速率和RTT曲线

前面提到了**BBR算法核心是寻找BDP最优工作点**，在相关论文中给出了一张组合的曲线图，我们一起来看下：

![图片][3bb488e54e5bdbc48ad19b35d3345b33.png]

**1. 曲线图示说明：**  
这张图是由两个图组合而成，目前是展示\[数据发送速率vs网络数据\]和\[RTTvs网络数据\]的关系，横轴是网络数据数量。

两个纵轴从上到下分别为RTT和发送速率，并且整个过程分为了3个阶段：**应用限制阶段、带宽限制阶段、缓冲区限制阶段**。

**2. 曲线过程说明：**

*  **app limit应用限制阶段**  
    在这个阶段是应用程序开始发送数据，目前网络通畅RTT基本保持固定且很小，发送速率与RTT成反比，因此发送速率也是线性增加的，可以简单认为这个阶段有效带宽并没有达到上限，RTT是几乎固定的没有明显增长。
 *  **band limit带宽限制阶段**  
    随着发送速率提高，网络中的数据包越来越多开始占用链路Buffer，此时RTT开始增加发送速率不再上升，有效带宽开始出现瓶颈，但是此时链路中的缓存区并没有占满，因此数据还在增加，RTT也开始增加。
 *  **buffer limit缓冲区限制阶段**  
    随着链路中的Buffer被占满，开始出现丢包，这也是探测到的最大带宽，这个节点BDP+BufferSize也是基于丢包的控制策略的作用点。

**3. 一些看法**

网上有一些资料都提及到了这张图，其中的一些解释也并不算非常清晰，结合这些资料和自己的认识，笔者认为在网络链路的缓存区没有被使用时RTT为最小延时MinRTT，在网络链路缓冲区被占满时出现最大带宽MaxBW(链路带宽+链路缓存)，但是此时的MaxBW和MinRTT并不是最优的而是水位比较高的水平，有数据表明按照2ln2的增益计算此时为3BDP，整个过程中MinRTT和MaxBW是分开探测的，因为这二者是不能同时被测量的。

6.2.3 BBR算法的主要过程

BBR算法和CUBIC算法类似，也同样有几个过程：StartUp、Drain、Probe\_BW、Probe\_RTT，来看下这几个状态的迁移情况：

![图片][239d6aca0125169fdce33b21aef375a9.png]

*  **StartUp慢启动阶段**
    
    BBR的慢启动阶段类似于CUBIC的慢启动，同样是进行探测式加速区别在于BBR的慢启动使用2ln2的增益加速，过程中即使发生丢包也不会引起速率的降低，而是依据返回的确认数据包来判断带宽增长，直到带宽不再增长时就停止慢启动而进入下一个阶段，需要注意的是在寻找最大带宽的过程中产生了多余的2BDP的数据量，关于这块可以看下英文原文的解释：

> To handle Internet link bandwidths spanning 12 orders of magnitude, Startup implements a binary search for BtlBw by using a gain of 2/ln2 to double the sending rate while delivery rate is increasing. This discovers BtlBw in log2BDP RTTs but creates up to 2BDP excess queue in the process.

*  **Drain排空阶段**  
    排空阶段是为了把慢启动结束时多余的2BDP的数据量清空，此阶段发送速率开始下降，也就是单位时间发送的数据包数量在下降，直到未确认的数据包数量<BDP时认为已经排空，也可以认为是RTT不再下降为止，排空阶段结束。
 *  **ProbeBW带宽探测阶段**  
    经过慢启动和排空之后，目前发送方进入稳定状态进行数据的发送，由于网络带宽的变化要比RTT更为频繁，因此ProbeBW阶段也是BBR的主要阶段，在探测期中增加发包速率如果数据包ACK并没有受影响那么就继续增加，探测到带宽降低时也进行发包速率下降。
 *  **ProbeRTT延时探测阶段**  
    前面三个过程在运行时都可能进入ProbeRTT阶段，当某个设定时间内都没有更新最小延时状态下开始降低数据包发送量，试图探测到更小的MinRTT，探测完成之后再根据最新数据来确定进入慢启动还是ProbeBW阶段。

我们来看一下这四个过程的示意图：

![图片][640c1c2a4818fa1f0a691a5d47ca1754.png]**曲线说明**：这两个坐标给出了10Mbps和40msRTT的网络环境下CUBIC和BBR的一个对比过程，在上面的图中蓝色表示接收者，红色表示CUBIC，绿色表示BBR，在下面的图中给出了对应上图过程中的RTT波动情况，红色代表CUBIC，绿色代表BBR。

6.2.4 BBR算法的一些效果

有一些文章认为BBR有鲜明的特点，把拥塞控制算法分为BBR之前和BBR之后，可见BBR还是有一定影响，但是BBR算法也不是银弹，不过可以先看看BBR算法在谷歌推动下的一些应用效果，其中包括吞吐量、RTT、丢包率影响：

![图片][7e0e6a6ba4948b5c93430c098036cc5b.png]

![图片][11b472bff2286291e7a7e53ceea6e4e7.png]

![图片][749a466a833c883e11827af05db85950.png]

从图中我们可以看到在YouTube应用BBR算法之后，就吞吐量普遍有4%左右的提升，特别地在日本的提升达到14%，RTT的下降更为明显平均降低33%，其中IN(猜测是印度地区)达到50%以上，在丢包率测试中BBR并不想CUBIC那么敏感，在丢包率达到5%是吞吐量才开始明显下降。

## 写在最后 ##

TCP/IP协议内容非常多，同时也带有年代感，**所以个人建议不要总拘泥于网上的那些俗套问题，可以多看看当前的新趋势**，比如HTTP3.0、SDN、DPDK这些新鲜的东西，而且很多书籍也比较早，有条件的同学可以看一些最新的外文资料来了解前沿信息，尤其是对于做音视频或者通信领域的同学还是很有好处的。

[e5792a39bf3204fa0c100f10df58e274.png]: /images/20220829/efcdf986b9594d56afd173e7148fbb27.png
[042d3ca31878fa91f31f22410ac98691.png]: /images/20220829/0ef895d1b6bb40c29daabb6b655b2d07.png
[ecd7f4561c482e996e94fb7793353c9a.png]: /images/20220829/5475c25a45b5482f962f8544b43a8462.png
[9d8dba2727cdb6e057c781a5445da958.png]: /images/20220829/495b5b8608db4e59ba6ff2d12802ff6e.png
[f1cbc7f49c67104028122c10be86623e.png]: /images/20220829/8028cf62762c447f84d747ce8edeb6d7.png
[36b27b6f8788de49a228c0e71ce3d8ac.png]: /images/20220829/7f9f56ab1b1b4cc28b94b4c8e7118458.png
[a08a8624dd933fb80a8d7e0400e55c01.png]: /images/20220829/21bee0ec0e894d3181e3fe686c8e1127.png
[64911c0684ca9324e6faeea3b02b6684.png]: /images/20220829/616cb0064661437495f8ec842f8a7227.png
[0ee22edf9c9a6634a54bcda25f3d72e8.png]: /images/20220829/05979372a214498396573f8c357eb8aa.png
[e0855efb1b5a4329c4bbfbcd18c6f382.png]: /images/20220829/36b8152d607b49b2b0a094944792529f.png
[a3725d22954b931b9ff3f7a0a4caaf96.png]: /images/20220829/2be31f9caac947b187e32ab4d330cbf7.png
[23c9c7961cba7e13cb08924fbd78e8d8.png]: /images/20220829/8339859b4c2448ce9fd14bc71ded5aee.png
[cd1adcf5483f930f9f236313b7c7958f.png]: /images/20220829/2e7a4f22308b44daaba68d7a7e33b55c.png
[ac128127c72e51c3a1e8b4fb3ff1218e.png]: /images/20220829/300b35c86abc41fa8d0cb3a42796ff43.png
[b1bddf41e5f9f80d6f283b1104beb0df.png]: /images/20220829/25d866026a634c10bb1f300a8c18318c.png
[fd576cc9875bd0a260460ef410d631fe.png]: /images/20220829/fdb85c48dd4140709056a55847553262.png
[b3e565f22786fe82e1a58cfa8d519793.png]: /images/20220829/b8cfcefa930b44afb1c537e308f4bfe4.png
[1869861cea6ec9101020375f8586d9f2.png]: /images/20220829/c50c95d4e362454ebbe5ac5bb990d346.png
[a9956ce5fd6c8dc2e05c766fab2a78a3.png]: /images/20220829/682038a4ae0f445fa7c2d325c003d083.png
[4510a5790241d2ae4f491b8acc2326ab.png]: /images/20220829/12710aa99618402c9fd49c419e1aae43.png
[94c4d20582c300106605c285183578c9.png]: /images/20220829/4f076fd6632441e3a8c6181476d08a85.png
[069a78c6f89505d9def737b1642cd45b.png]: /images/20220829/703afb4785244cd0858c03704242a493.png
[cd8f1dc4507453b34c86b7f304561ade.png]: /images/20220829/04d82ce5bb3c4b80a3c2e9c03a59813c.png
[4677157ce111f37c5f8eeb1aa3ac7f6a.png]: /images/20220829/8cee1cae58b14579a1d68e2d3c986523.png
[1dcbd5ae434d0b3e7137b0051d850e08.png]: /images/20220829/3cee3bd4717b4615bad28e2a4226ebe1.png
[e0dce948dc41e14dc6d7475c9662346a.png]: /images/20220829/b5bf63de4b4e4ba2b5fde52c0250bd8d.png
[a0718cf34613f691a61f381d7d0d25ac.png]: /images/20220829/30d1195645e94bbeb5899fc4920e521d.png
[178c56cc0557ded787871a3e6b6a36d6.png]: /images/20220829/8ba9bfff4f9f42fda863bf0026692262.png
[50fa7c09c303e88ab7b848eb6a211700.png]: /images/20220829/00bab3fb57894fbab8e0b65ce7f6a790.png
[783ec40fff1384b7723f67f10ef32a59.png]: /images/20220829/0db7b2eaa6e3479caf7523d1a548a06b.png
[3bb488e54e5bdbc48ad19b35d3345b33.png]: /images/20220829/70df46cdfa924acba021406ff23cfeec.png
[239d6aca0125169fdce33b21aef375a9.png]: /images/20220829/2be53d1ce20b430b8ad06b24706cbe49.png
[640c1c2a4818fa1f0a691a5d47ca1754.png]: /images/20220829/17cd4b2d69184b818a2c35f28b220f34.png
[7e0e6a6ba4948b5c93430c098036cc5b.png]: /images/20220829/f381b2f982504a7a8a1a4965aadef5f6.png
[11b472bff2286291e7a7e53ceea6e4e7.png]: /images/20220829/4d8b0c51e4e945058832ac0342e213cf.png
[749a466a833c883e11827af05db85950.png]: /images/20220829/2b225b128afd4d4c993883ce58ed2ee5.png