0x00。前言这是TCP/IP协议栈系列的第三篇文章，之前的一个采访热点|理解TCP/IP传输层拥塞控制算法，讲述了传统拥塞控制算法的基本原理，今天我们来学习一下添加在TCP/IP协议栈中的拥塞控制算法最新的Linux内核：TCPBBR算法。鉴于TCP拥塞控制算法背后复杂的数学理论和控制策略，本文只能做简要的探讨。通过本文，你将了解到以下内容（温馨提示：文章较长，需要一定的耐心，阅读前也可以收藏一下）：回顾传统拥塞控制算法概述TCPBBR算法BBR算法原理介绍端到端的窗口控制已经不能满足要求，导致了1986年的一次大规模网络瘫痪。这时候应该提到一个重量级人物：VanJacobson。这个力挽狂澜的人物入选了互联网名人堂。大师VanJacobson提出并设计并实现了TCP/IP拥塞控制，解决了当时最大的问题。简单看一下VanJacobson的维基百科介绍（作者做了部分删减）：VanJacobson是目前作为互联网技术基础的TCP/IP协议栈的主要起草人。他以在网络性能改进和优化方面的开创性成就而闻名。2006年8月，他作为研究员和PacketDesign的首席科学家加入了帕洛阿尔托研究中心，该中心位于相邻的施乐公司。在此之前，他是思科系统公司的首席科学家，也是劳伦斯伯克利国家实验室网络研究小组的负责人。VanJacobsen以其在提高IP网络性能和优化方面的工作而闻名。1988-1989年间，他重新设计了TCP/IP流量控制算法（Jacobson算法）。他因设计RFC1144中的TCP/IP报头压缩协议而广为人知，被称为vanJacobsenTCP/IP报头压缩协议。此外，他还参与设计了一些广泛使用的网络诊断工具，如traceroute、pathchar和tcpdump。VanJacobson于2012年4月入选第一批计算机名人堂计算机名人堂介绍：https://www.internethalloffame.org/inductees/van-jacobson图为VanJacobson计算机介绍HallofFame：作者找到了VanJacobson和MichaelJ.Karels在1988年11月发表的关于拥塞避免和控制的论文，共25页。感兴趣的读者可以参考：https://ee.lbl.gov/papers/congavoid。pdf我们常用的tracetoute和tcpdump也是van-jacobson大师的杰作。作为互联网时代的受益者，不禁对互联网早期发展做出巨大贡献的开拓者、创新者、改革者表示敬仰和敬仰。0x02。传统拥塞控制算法回顾2.1算法目的看到一篇文章说TCP传输层拥塞控制算法不是计算机网络的简单概念，也属于控制论的范畴。我觉得这个观点很有道理。TCP拥塞控制算法的目的可以简单概括为：公平竞争、充分利用网络带宽、减少网络延迟、优化用户体验。然而，就目前而言，为了实现这些目标，不可避免地需要权衡取舍。然而，当前网络通信基础设施水平一直在迅速提高。我相信这些目标可以在未来的某个时候实现。孩子才选择，我们大人都想要！2.2算法分类在理解拥塞控制算法之前，我们需要明确一个核心思想：听说有一阶技术和特化。笔者认为这是一个非常重要的共识问题。把A踩在土里把B吹上天，这可不是什么好办法。实际的网络环境非常复杂，变化很快，没有一种拥塞控制算法可以应对所有这些情况。每个算法都有自己特定的适用领域，每个算法都是几个关键点的权衡。在一定条件下，有的算法选择带宽利用率，有的算法选择通信时延等。明确了这个共识问题之后，我们就应该以更加温和的态度对待每一种拥塞控制算法，不要过多考虑谁是最好的。几十年前的网络形势与现在完全不同，我们永远站在巨人一边。它也是科学和文明进步的原动力。传统的拥塞控制算法不是一蹴而就的。复杂的网络环境和用户的高要求促进了拥塞控制算法的优化和迭代。下面我们看一下传统的基于丢包策略的拥塞控制算法的几个迭代版本，如图：同时，还有一类算法是基于RTT延迟策略进行控制的，但是这一类算法在发包速率上可能不够激进，竞争性能不如其他算法，所以在共享网络带宽的时候是不公平的，但是算法的速率曲线很平滑，所以我们把这种类型的算法暂时作为君子！其中，比较有名的Vegas算法是由亚利桑那大学的研究人员LarryPeterson和LawrenceBrakoff于1995年左右提出的。这种新的TCP拥塞算法以内华达州最大的城市拉斯维加斯命名，后来成为TCPVegas算法。关于RTT-basedTCPVegas算法的详细介绍可以参考文档：http://www.cs.cmu.edu/~srini/15-744/F02/readings/BP95.pdf文档已经做了Vegas算法和NewReno上的一些工作对比，从直观的图形我们可以看出Vegas算法更流畅。相反，NewReno的性能除了波动较大外，其他都是参差不齐的，如图：其实还有更细粒度的分类。由于不是今天的重点，就不展开了。目前的拥塞控制算法还是以丢包Loss-Based为主流。2.3算法原理我们知道网络链路中的连接数是动态变化的并且数量庞大，而且每个连接都面临着一个黑盒网络环境，不像平时看地图就知道在哪里流量是有的，为了保持良好的网络环境，每个连接都需要遵守一些约定。如果在连接端毫无顾忌地产生数据包，网络链路很快就会达到瓶颈，数据通信根本得不到保障。因此，要获得一个稳定高效的网络环境，需要付出很大的努力。其中有两个：两个重要的概念：公平和收敛。说来惭愧，笔者在网上找了很多资料来了解TCP拥塞控制的公平性和收敛性，但还是没有得到很好的权威解释，所以只能结合一些资料和自己的理解来解释所谓的公平和收敛。笔者认为，公平性是相对于网络链路中的所有连接而言的。这些共享链接的连接开始和结束时间是不同的。在实际交互过程中，每个连接都有均等的机会占用带宽，并且由于带宽限制连接两侧通信的数据量是动态调整的，近似收敛到某个值，即呈现锯齿状或更平滑的波动曲线。对于基于丢包的拥塞控制算法，AIMD线性乘减策略起关键控制作用。接下来，让我们重点介绍一下AIMD的特点。先贴一张经典图片看看AIMD的流程：看维基百科对AIMD的定义：Additive-increase/multiplicative-decrease(AIMD)algorithmisafeedbackcontrolalgorithmbosebestknownforitsusedinTCPcongestioncontrol.AIMD结合线性当检测到拥塞时，拥塞窗口的增长会呈指数减少。使用AIMD拥塞控制的多个流最终会收敛以使用等量的共享链路。相关的乘法增加/乘法减少(MIMD)和加法增加/加法-减少(AIAD)未达到稳定。简单翻译：线性增加乘法减少算法是一种反馈控制算法，由于其在TCP拥塞控制中的作用广为人知，AIMD将拥塞窗口的线性增加和拥塞窗口的乘法减少相结合。理想情况下，基于AIMD的多个连接最终会融合并共享相同数量的网络带宽。相关的乘增减MIMD策略和增增减AIAD都不能保证稳定性。与MIMD和AIAD相比，当连接进入拥塞避免阶段时，使用试探性线性加法策略比乘法加法策略更安全。在检测丢包时，倍数大大降低到1/2，有利于缓解拥塞。效果更快。相反，如果在检测到丢包时使用线性减少AD，拥塞可能会持续更长时间。总的来说，AIMD是一种比较简单实用的反馈控制的工程版，同时也具有工程收敛性，因此被广泛应用。实际的。2.4弱网环境下的AIMD回到20多年前，互联网初期几乎所有的设备都是通过有线网络连接和通信的。网络的稳定性比较好，所以用丢包作为网络拥塞的一个特征是很正常的。回到现在，从2010年开始，移动互联网蓬勃发展，移动终端的数量变得海量起来。无线网络的引入使得网络环境更加复杂，因此不稳定的丢包也变得更加频繁，但是此时的丢包并不一定是网络拥塞造成的，因为整个数据包在基本的每一个链路上都可能出现异常多路由、交换机、基站等通信设备。在弱网络环境下，尤其是在移动互联网中，以往基于AIMD的拥塞控制策略可能会因为丢包而大大降低网络吞吐量，从而大大降低网络带宽的利用率。这时候，我们采用更激进的控制策略，或许能够获得更好的效果和用户体验。在恶意丢包的情况下，基于AIMD的拥塞控制确实相当于限速，因为AIMD确实是保守谨慎的，这个其实很好理解。我们都知道，在移动网络环境中，终端以无线的形式与附近的基站交换数据，然后数据传输到核心网络，最后落到特定服务器所在的有线网络。最后一公里区域属于高延迟场景。网络是低延迟高带宽的场景。国外的相关实验证明了传统拥塞控制算法在弱网络环境下RTT的变化对网络吞吐量的影响。数据和曲线如图所示：实验意义：RTT的增加影响CUBIC等拥塞控制算法我们知道拥塞窗口cwnd在慢启动阶段每个RTT周期都会加倍，但是更大的RTT意味着发送方以非常低的速率发送数据，更多的时间是空闲的，发送数据包的加速度会极低，因此整体吞吐量会明显下降。看实验者的原话：收到确认包之前的延迟（=latency）会影响TCP拥塞窗口增加的快慢（进而影响吞吐量）。当延迟很高时，这意味着发送方有更多时间空闲（不发送任何新数据包），这会降低吞吐量增长的速度。0x03TCPBBR算法简介BBR算法是一种主动闭环反馈系统。通俗的说就是根据带宽和RTT时延不断动态探索，找到合适的发送速率和发送量。看维基百科关于BBR算法的描述和资料：相关文献：https://queue.acm.org/detail.cfm?id=3022184TCPBBR（BottleneckBandwidthandRound-trippropagationtime）由Google设计，发表于The2016年发布的拥塞算法，之前的拥塞算法大多是以丢包为信号降低传输速率，而BBR则是基于模型主动检测。该算法使用网络最近出站数据包的当前最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成采样率，该采样率记录在数据包传输过程和确认返回之间的时间内传输的数据量。该算法认为，随着网络接口控制器逐渐进入千兆速率，丢包不应被认为是拥塞的主要决定因素，因此基于模型的拥塞控制算法可以具有更高的吞吐量和更低的延迟，可以使用BBR代替其他流行的拥塞算法，如CUBIC。谷歌将该算法应用到YouTube，使全球平均YouTube网络吞吐量提高了4%，在一些国家甚至提高了14%以上。BBR后来被移植到Linux内核4.9版本，并可用于QUIC。3.1基于丢包反馈策略可能存在的问题基于丢包反馈是一种被动机制，根本原因在于这些拥塞控制算法是根据是否有丢包事件来判断网络拥塞并调整窗口，所以一些问题可能出现：在拥塞的现实中，网络环境非常复杂，会出现错误丢包。许多算法无法区分拥塞丢包和错误丢包。因此，在一定错误丢包的前提下，在某些网络场景下无法充分利用带宽。BufferInflation问题在BufferBloat网络连接中，路由器、交换机、核心网络设备等都有缓冲区来平滑网络波动。这些缓冲区就像是输液管的扩张，让数据更加稳定，但是Loss-Based策略就像网络中数据的发生类似于泛洪。这时候，所有的Buffer都被统计了。一旦缓冲区满，可能会出现RTT增加、丢包等问题。相当于一些不应该包含在里面的容量，但是策略是基于包含Buffer的Prediction，特别是在deepbuffernetworks中，会造成一些问题。网络负载高，但没有丢包事件。假设网络中的负载已经很高。只要没有丢包事件发生，算法就不会主动减小窗口来降低发送速率。在这种情况下，虽然网络带宽得到了充分利用，但同时由于没有丢包事件，发送方仍在增加窗口，表现出很强的网络带宽攻击性，加剧了网络负载压力。在高负载丢包和高负载无丢包的情况下，算法不断增加窗口，从而可以预测即将发生丢包事件。一旦发生丢包，窗口会呈现成倍减少，高比特发送速率的快速减少会引起整个网络的瞬时抖动，一般呈现较大的锯齿波波动。低负载高延迟丢包在一些弱网络环境下，RTT会增加甚至不拥塞导致丢包。此时基于丢包反馈的拥塞算法窗口会比较小，带宽利用率很低，吞吐量急剧下降。很明显，但实际上网络负载并不高，所以在弱网环境下效果不是很理想。3.2TCPBBR算法的基本原理我们提到了Loss-Based算法的一些问题。TCPBBR算法是一种主动机制。简单的说，BBR算法不再基于丢包判断，不使用AIMD线性乘法。reductionstrategy用于维持拥塞窗口，但是samples用于估计最大带宽和最小延迟，两者的乘积作为发送窗口，BBR引入PacingRate来限制数据发送速率，并将其与cwnd一起使用以减少影响。3.2.1BDP一些术语BDP是Bandwidth-DelayProduct的缩写，可译为带宽延迟积。我们知道带宽的单位是bps（bitpersecond），延迟的单位是s，所以BDP的量纲单位是bit，所以我们知道BDP是衡量一条链路上数据量的指标。一段时间。这可以形象地理解为水管灌溉的问题。带宽为水管的水流速度，单位为立方米/秒，延时为灌溉时间单位s。将两者相乘，我们就可以知道当前水管中储存的水量。这是BBR算法的关键。指标我们看陶辉文章中的一张图和一些网络场景下的BDP计算：LongFatNetwork我们把RTT往返时间长、带宽高的网络称为longfatnetwork或longfatpipeline。它的bandwidth-delayproductBDP非常大，这个网络理论上的大吞吐量也是研究的重点。TCPPacing机制可以简单理解为TCPPacing机制是在拥塞控制中平滑发送数据包，避免数据突发，减少网络抖动。3.2.2带宽和时延的度量BBR算法的一些思想也出现在以往的基于时延的拥塞控制算法中，其中最著名的就是著名的TCPWestWood算法。TCPWestwood由NewReno改进而来。不同于以往其他的拥塞控制算法使用loss来衡量，它通过测量确认报文来确定合适的发送速度，并据此调整拥塞窗口和慢启动阈值。改进了敏捷检测的慢启动阶段算法，设计了连续检测拥塞窗口的方法来控制进入敏捷检测，使链路能够使用尽可能多的带宽。TCPWestWood算法也是基于带宽和时延的乘积来设计的，但是带宽和时延这两个指标不能同时衡量，因为这两个值是有些矛盾的极值。要测量最大带宽，必须发送最大量的数据。但是此时的RTT可能会非常大。如果要测这么长时间的最小RTT，说明数据量很小，拿不到最大带宽。TCPBBR算法采用交替采样的方式衡量两个指标，取一段时间内带宽的最大值和时延的最小值作为估计值。具体实现本文不展开。3.2.3发送速率和RTT曲线如前所述，BBR算法的核心是寻找BDP的最优工作点。相关论文中给出了组合曲线。下面我们一起来看一下：1.曲线图解：这个图是由两个图组成的。目前显示的是【数据传输速率vs网络数据】和【RTTvs网络数据】之间的关系。横轴是网络数据量。两个纵轴从上到下分别是RTT和发送速率，整个过程分为三个阶段：应用限制阶段、带宽限制阶段、缓冲区限制阶段。2.曲线过程说明：applimit应用限制阶段。在这个阶段，应用程序开始发送数据。目前网络流畅，RTT基本固定，很小。发送速率与RTT成反比，所以发送速率也是线性增加的。可以简单的认为在这个阶段，有效带宽还没有达到上限，RTT几乎是固定的，没有明显的增长。在带宽限制阶段，随着发送速率的增加，网络中越来越多的数据包开始占用链路缓冲区。此时RTT开始增加，发送速率不再上升。有效带宽开始出现瓶颈，但是此时链路中的缓冲区还没有满，所以数据还在增加，RTT也开始增加。在bufferlimit阶段，由于链路中的buffer已满，开始出现丢包现象。这也是检测到的最大带宽。本节点的BDP+BufferSize也是基于丢包的控制策略的作用。3.一些看法网上有一些资料参考了这张图，有些解释的不是很清楚。结合这些资料和我自己的理解，笔者认为当网络链路的缓存区不被使用时，RTT为最小延迟MinRTT，最大带宽MaxBW（链路带宽+链路缓存）出现时networklinkbuffer已满，但此时MaxBW和MinRTT不是最优但水位比较高。数据显示此时按照2ln2的增益计算为3BDP，全程分别检测MinRTT和MaxBW，因为两者不能同时测。3.2.4BBR算法的主要流程BBR算法与CUBIC算法类似，也有几个流程：StartUp、Drain、Probe_BW、Probe_RTT。我们来看看这些状态的迁移情况：StartUp慢启动阶段BBR慢启动阶段和CUBIC的慢启动类似，也是进行探测加速。不同的是BBR的慢启动使用的是2ln2增益加速。即使过程中出现丢包，也不会造成速率下降，只是根据返回的确认包判断带宽。增加直到带宽不再增加，则停止慢启动，进入下一阶段。需要注意的是，在寻找最大带宽的过程中，会产生多余的2BDP数据量。对此，请参考英文原文解释：为了处理跨越12个数量级的Internet链路带宽，Startup通过使用2/ln2的增益对BtlBw进行二分查找，在递增速率的同时将发送速率提高一倍。这个发现log2BDPRTTs中的BtlBwbutcreatesupto2BDPinqueueex过程。Drain清空阶段清空阶段是在慢启动结束时清空多余的2BDP数据量。该阶段发送速率开始下降，即单位时间内发送的数据包数量不断减少，直到未确认的数据包数量ProbeBW带宽检测阶段慢启动清空后，发送端进入稳定状态发送数据.由于网络带宽的变化比RTT更频繁，ProbeBW阶段也是BBR的主要阶段。检测期间加包如果数据包ACK不受影响，速率会继续增加，当检测到带宽减少时，发包速率也会降低。ProbeRTT延迟检测阶段前三个进程在运行过程中可能会进入ProbeRTT阶段。当最小延迟状态在一定的设定时间内没有更新时，减少发送的数据包数量，尝试检测更小的MinRTT，检测完成。然后根据最新的数据，判断是进入慢启动还是ProbeBW阶段。我们来看看这四个过程的示意图：曲线说明：这两个坐标给出了在10Mbps和40msRTT的网络环境下CUBIC和BBR的对比过程。上图中蓝色表示receiver，红色表示CUBIC，绿色表示BBR，下图是上图过程对应的RTT波动，红色表示CUBIC，绿色表示BBR。0x04。TCPBBR算法的一些效果。一些文章认为BBR具有鲜明的特点。拥塞控制算法分为BBR前和BBR后。可以看出BBR还是有一定影响的，但是BBR算法也不是灵丹妙药，不过大家可以先看看。Google推广的BBR算法的一些应用效果，包括对吞吐量、RTT、丢包率的影响：从图中可以看出，YouTube应用BBR算法后，吞吐量普遍提升了4%左右，尤其是日本的增幅达到了14%，RTT的下降更为明显。平均下降33%，其中IN（猜测是印度）达到50%以上。在丢包率测试中，BBR不如CUBIC敏感。当丢包率达到5%时，就是吞吐量开始明显下降的时候。0x05。小结本文首先回顾了以CUBIC为代表的传统拥塞控制算法，然后对BBR算法进行了一些介绍。网上有很多关于BBR的文章。笔者也尝试对很多文章和外文资料进行理解和总结。但由于笔者的工作经验和水平，以上文字可能存在一些问题。对此我深表歉意，很多细节不详。展开，所以只能算是浅谈。0x06。巨人的肩膀https://cloud.tencent.com/developer/article/1369617https://www.cnblogs.com/codingMozart/p/9497254.htmlhttps://blog.csdn.net/dog250/article/details/57072103https://my.oschina.net/piorcn/blog/806997https://my.oschina.net/piorcn/blog/806994https://my.oschina.net/piorcn/blog/806989https://accedian.com/enterprises/blog/measuring-network-performance-latency-throughput-packet-loss/https://mp.weixin.qq.com/s/BGWkvLl0AAx9slI1lSZMgwhttps://www.zhihu.com/question/53559433https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-fasterhttps://cloud.tencent.com/developer/article/1383232https://queue.acm.org/detail.cfm?id=3022184https://juejin.im/post/5e0894a3f265da33d83e85fehttps://zhuanlan.zhihu.com/p/63888741
