bbr算法路由器

‘壹’ 协议确认机制TACK的通俗解析

搞计算机网络研究的人都知道，传输层协议最经典的问题就是怎么做 拥塞控制 （Congestion Control）。这玩意做了三十多年还是经久不衰，新人老人前赴后继，近年来又如雨后春笋般出现了BBR，Copa，PCC， Indigo等算法，在不同的场景和目标中各显神通。

在数据传输的过程中，人们通常关注正向的数据报文传输性能，却很少关心反向路径上确认报文ACK的传输。然而，高吞吐和低时延往往与ACK的机制设计息息相关。例如，发生拥塞时，我们依赖ACK及时、准确地反馈连接状态，从而调整发送速率；发生丢包时，我们依赖ACK通知包到达信息，从而进行丢包重传。

拥塞控制已经“杀”成了一片红海，而作为协议的另一个重要模块 协议确认机制 ，却还是一片处女地。

今年我们在SIGCOMM2020上提出了一种新型的传输协议确认机制（ACK Scheme）： TACK ，今天我想通过这篇博文给大家简单地对TACK机制进行通俗化的解析，算作导读。

进入正题。

作为万物互联 “最后100米”的通信网络技术，无线局域网（WLAN）技术催生了各式各样新型的移动应用。无论是通过无线路由器把手机、平板、电脑和电视等智能化设备接入到互联网，还是通过WiFi直连技术架起设备与设备之间的捷径，WLAN为生活数字化和新型应用（如4K无线投屏、AR/VR交互式游戏等）的涌现，提供了无限可能。​

WLAN最常用的技术就是WiFi。WiFi通常工作在非授权公共频段（2.4GHz或5GHz），非常容易受到“外部干扰”。这种干扰将造成网络质量突发性劣化和间歇式丢包，导致用户体验下降，例如视频应用可能出现花屏、卡顿，甚至业务中断。

​业界针对无线传输协议的优化，通常更关注“外部干扰”，即采取某种算法应对网络抖动或丢包。然而，无线传输过程中还存在所谓的“内部干扰”——同一连接中ACK报文对数据报文的干扰。

传统传输协议TCP因为要保证可靠，在发送数据报文的同时，难以避免地频繁发送ACK报文。另一方面，WiFi的半双工特性和冲突避免机制，造成ACK报文与和数据报文形成了直接的资源竞争，在传统TCP的ACK机制下，控制报文（ACK）几乎要占用将近一半的可用频谱资源。而且，带宽越大，“内部干扰”越严重。

在这种情况下，减少ACK报文的数目从而降低“内部干扰”，不仅可以提高无线传输的有效带宽利用率，而且还可以在弱网下将有限的宝贵传输资源留给数据报文。

然而，传统TCP依赖于高频度的ACK进行传输控制，简单粗暴地减少ACK的数目，却又可能造成滑窗效率低下、缓冲区压力倍增、以及应用响应时延增加。具体表现为数据突发、窗口更新缓慢、时延评估不准确、丢包恢复鲁棒性下降等。

另外，注意到，无线网络同时面临“外部干扰”和“内部干扰”，传输协议如果只强化抗“内部干扰”的手段，就不可避免会降低其抗“外部干扰”的能力。

以上这些矛盾点都使得问题极具挑战。

这篇文章提出“TACK”(Tame ACK，驯服的确认机制)机制，不仅可以最小化ACK的数目，而且还保证传输控制过程的井然有序，正所谓“鱼与熊掌兼得”。

TACK机制颠覆了传统协议确认机制的“简单粗暴”和固有设定，赋予了ACK报文更多的智能和灵活性。其设计原理，可以简单地理解成三点： 1）多ACK种类适应不同场景需求；2）ACK按需携带更多必要的信息；从而实现：3）更少但足够的ACK数目。

具体来说，引入一种“即时ACK”报文加快传输控制对即时事件（例如丢包）的反馈和响应，同时，引入一种高度自适应的“周期ACK”报文保证反馈的鲁棒性和可靠性。这种“周期ACK”报文是以时钟周期触发的，而并非以包接收或者超时等事件触发，这种ACK的数量不会跟吞吐成比例，也就不会造成“内部干扰”随着吞吐增大而增大。

“即时ACK”报文和“周期ACK”相辅相成、互相补充和高效协同，加上基于TACK机制的丢包恢复、时延探测和速率控制算法，可以保证丢包恢复的鲁棒性、时延探测的准确性以及速率控制高效性。

TACK机制作为一种创新的传输协议确认机制，可以在不同的协议载体（例如TCP/UDP/QUIC）上进行实现。我所在的华为计算机网络与协议LAB创新团队，依托其创新的用户态极简协议，为华为全场景生态提供了高效的连接通道。例如，自华为手机系统EMUI 9.1以来，华为、荣耀旗舰手机和智慧屏等多余款产品均采用了基于TACK的极简协议，使得其高清视频和游戏投屏体验得到显着改善。

在SIGCOMM的众多研究方向中，传输协议TCP优化是一个经典的课题，与TCP优化相关的工作必须达到一个极高的“阈值”才可能被录用。

笔者论文“TACK: Improving Wireless Transport Performance by Taming Acknowledgments”作为传输协议方向的文章成功入围，多年苦心钻研没有白费，努力有被看到，不禁备感幸运。

这篇文章除了得到谭焜博士和郑凯博士的指导外，还受到了清华大学徐恪教授也就是我博士导师的财力和学术上的大力支持，感激无法言表。这篇文章也受到了斯坦福大学Keith Winstein的指导和支持，Keith在自己的[个人主页](https://cs.stanford.e/~keithw/)是这么介绍我们的合作过程的：

更多的细节可以阅读论文： Tong Li, Kai Zheng, Ke Xu, Rahul Arvind Jadhav, Tao Xiong, Keith Winstein, Kun Tan. “TACK: Improving Wireless Transport Performance by Taming Acknowledgments.” Proceedings of the 2020 Conference of the ACM Special Interest Group on Data Communication (ACM SIGCOMM), pp. 15-30, 2020.

也可以访问我的主页，获取PPT和视频资料： https://leetong.weebly.com/

‘贰’ ipv6怎么开启bbr

ipv6开启bbr：买一个堪江出厂支持ipv4和ipv6双模式光猫，可以相互转换协议，只要Tcpip启动iptv6协议光猫路由器模式开启lenten英特尔连接就可以联网，iiptv4是32位，iptv6是128位，是iptv4的4倍。

1、 以管理员身份运行cmd命令，进入命令行模式。

2、 输入netsh。

3、 输入int ipv6 isatap，进入isatap配置模式。

4、 输入set router isatap.ahau.e.cn en，配置isatap路由器。

报文内容：

IPv6报文的整体结构分为IPv6报头、扩展报头和上层协议数据3部分。IPv6报头是必选报文头部，长度固定为40B，包含该报文的基本信息；扩展报头是可选报头，可能存在0个、1个或多个，IPv6协议通过扩展报头实现各种丰富的功能。

上层协议数据是该IPv6报文携带的上层数据，可能是ICMPv6报文、TCP报文、UDP报文或其他可能报文。

‘叁’ 路由重分布的概念

配置基本的路由重分布

配置基本的路由重分布

【实验目的】：
在本次实验中，在本次实验中，你将重分路RIPV2到OSPF协议，并且在RIPv2路由器提供缺省路由。
在完成本次实验之后，你需要完成下列任务：
• 在不同的路由协议之间重分布路由信息。
【实验拓扑】：

注意：图中x为所在机架编号，y为路由器编号。
【实验帮助】：
如果出现任何问题，可以向在值的辅导老师提出并请求提供帮助。
【命令列表】：
命令 描述
(config-router)#default-information originate 在RIP域内发布缺省路由
(config)#ip route 0.0.0.0 0.0.0.0 172.31.xx.4 创建一条静态路由
(config-router)#no auto-summary 在类路由边界关闭自动汇总功能
(config-router)#redistribute rip subnets 重分布RIP v2到OSPF。这个subnets关键字要求传送子网路由到OSPF域中。
(config-router)#version 2 运行RIP v2
【任务一】：配置路由协议。
实验过程：
第一步：你的导师已经把BBR2放置到OSPF区域0。
请配置边界路由器和内部路由器为下列情形：
边界路由器PxR1和PxR2运行OSPF和RIPv2两种路由协议。
在边界路由器上，放置s0接口到OSPF区域0。
因为BBR2是配置为点对多点接口，配置边界路由器的s0接口为点对多点网络类型。
内部路由器仅配置RIPv2。
你的显示应该如下列所示：
在边界路由器上：

在内部路由器上：

第二步：显示两个边界路由器的路由表。验证两个边界路由器是学习到了OSPF和RIPv2的路由。在RIPv2的路由器到你的路由器，那一个是最高RIP跳计数？

【任务二】：配置基本重分布
实验过程：
第一步：配置边界路由器传输缺省路由到RIPv2。记住：为了让其它RIPv2的路由器学习到缺省路由，RIPv2需要配置一条静态缺省路由。
测试内部路由器的路由表：
这里有缺省路由出现？
他的路由和度量值是多少？
第二步： 配置两个边界路由器重分布RIPv2路到OSPF，重分布路由时，不指定度量值。从RIPv2重分布的路由将在OSPF中缺省度量值是多少？记住在重分布路由时一定要使用subnets关键字。
第三步：TELNET到核心路由器BBR2测试OSPF数据库。
路由表中的哪一个路由是从你的实验机架重分布的？
它们是哪一种OSPF路由类型？
第四步：在两个内部路由器上测试IP路由表。你的显示应该与下列类似：

【任务三】：过滤路由更新
配置你的边界路由器过滤环回接口路由到达网络核心。因为网络核心与你的路由器进行OSPF交换路由，使用分布列表去阻止这条路由重分布到OSPF。
实验过程：
第一步：创建一条ACL区别四个环回接口地址。
第二步：使用分布列表去阻止这个ACL中的RIPv2路由被重分布到OSPF。
第三步：测试网络核心路由表，验证环回接口地址是没有被列表的。
第四步：网络核心能PING通你的环回接口地址吗？

【实验验证】：
成功完成整个实验，你需要完成下列任务：
• 你能够在边界路由器和核心路由之间建立OSPF邻接，并进行路由交换
• 你能够在边界路由器和内部路由器之间进行RIPv2更新和路由交换
• 你能配置从RIPv2重分布路由到OSPF
• 你能发布一条缺省路由并注入到RIPv2路由域中

‘肆’ ospf路由器，一个路由器可以是IAR,BBR,ASBR.各种角色之间都有哪种可以相互扮演，请高手回个话，谢谢

题目再问清晰点.ABR是连接区域0和其他区域,ASBR是连接外部自治系统的

‘伍’ 如何验证开启linux bbr

仅在Ubuntu，Arch，Manjaro 下测试过，其它发行版同理。
Arch/Manjaro

虽然 Arch/Manjaro 可以直接安装 linux49 包。但默认没有开启 BBR。需要手动编译。下载 manjaro/packages-corelinux49 包的所有文件，将 config 以及 config.x86_64 文件中的

# CONFIG_TCP_CONG_BBR is not setCONFIG_DEFAULT_CUBIC=y

改为

CONFIG_TCP_CONG_BBR=yCONFIG_DEFAULT_BBR=y

然后将 PKGBUILD 中第二三个 hash 改为 'SKIP'. 执行 makepkg -si 即可。

‘陆’ 路由重分布什么意思

重发布的意思就是比如说 RouterA和RouterB配两个不同的动态路由协议，他们之间是没有LSA的，要想在router上有对方的LSA就要做重发布。一般来说一个组织或者一个跨国公司很少只使用一个路由协议，而如果一个公司同时运行了多个路由协议，或者一个公司和另外一个公司合并的时候两个公司用的路由协议并不一样，这个时候该怎么办呢？所以必须重发布来将一个路由协议的信息发布到另外的一个路由协议里面去。
重发布只能在针对同一种第三层协议的路由选择进程之间进行，也就是说，OSPF，RIP，IGRP等之间可以重发布，因为他们都属于TCP/IP协议栈的协议

‘柒’ 如何实现自定义的可靠 UDP 协议--转载

既然已经有TCP了，为什么还需要UDP可靠？

TCP是强制的可靠性传输，其在IP协议的基础上，发送端对所有的数据进行定时重传，接受端对所有的数据进行排序，以此(当然还有很多其他的机制)来实现发送端是什么样子的，接受端就能接受到什么样子的数据。但是现实中有一些场景，我们并不需要如此固执的可靠性。

对于FPS游戏这种时效性要求非常高的游戏中，玩家最关心的是自己的射击结果和角色的存活与否，当有一个手雷扔过来时，对于被炸死的玩家而言，这颗手雷是必须要接收到的消息，而其他没有被炸到的玩家，仅需要看到手雷的爆炸动画或者是声音，其更关心的是自己现在的子弹，有没有将敌人爆头。我们不希望因为手雷的消息重传排队，而把射击玩家的结果确认消息延后，这对于TCP而言就力所不逮了。

我们看一张图：

在传输效率，传输代价和可靠性三个维度上，TCP在最左侧的这条线上，可靠性最高，但传输代价也很大，效率上不及UDP。UDP则在最右侧，只有传输效率，不保证可靠，传输代价也较低。我们如果需要在大约六角形的位置，选择一个折中的方案，那就是UDP可靠传输，即RUDP登场的时刻了。

如何实现？

首先，为了保证可靠性，我们需要在发送数据的时候添加 重传定时器 ，来保证丢失的数据会被重传。重传的定时器可以定时回调发送重传的数据，也支持将接收到ACK的数据从定时器中取出。

现在有了重传定时器，那每次发送数据的时候，应该给定时器设置多长的超时时间呢？最简单的可以设定一个固定的重传时间，最合理的应该针对每条传输链路的不同设置每个连接的合理时间--rto。为了找到rto时间，我们需要获取到每个数据包发送确认时间，即rtt时间，即数据从发送到接收到ACK确认之间的时间间隔。我们参照TCP的实现策略，可以给每个消息记录一个发送时间，当接收到ACK确认时，将此时的时间减去记录的发送时间就获取到了rtt时间。但这样有一个问题，当发生数据重传时接收到ACK，无法判断这个ACK是对初次发送数据的确认还是对重传数据的确认，此时只能将发生重传数据测量到的rtt时间丢弃。所以又有第二种rtt计算策略，我们可以将发送时间记录在数据头中发送出去，接受端在发送确认ACK时，将这个时间戳抄下来顺着ACK返回，这样发送端接收到ACK确认时，就能准确的知道要确认数据的发送时间，由此来计算rtt时间。有了rtt时间，我们按照TCP的标准方法《CP/TPxian详解卷一, P465》，计算rto时间。

当接受到ACK确认时，我们需要将确认的数据从定时器中移除。

为了提高网络链路利用率，接收端不能每次接收到数据时都立即发送ACK确认，为什么呢？传输的数据量越小，控制头占比越高，而且网络中到处都是只携带一个ACK的包在飞，会造成路由器排队。这里可以接着参考TCP的实现策略。一种是延时ACK，即接收端接收到消息时定制一个pending time，当超时时将这段时间内所有要发送的ACK组合在一起发送，还有一种是捎带ACK，即pending time未到，但恰好也有数据要发送给对端，那么就将ACK捎带在这个数据包中一起发送出去。由于接收端ACK发送都不是瞬时的，所以在上文说到的RTT计算时也需要考虑引起的计算误差。

有同学要问了，你这整半天UDP可靠，还不是TCP都一样的策略？那接下来就说点和TCP不一样的东西了。

我们之前都只说了一个数据包的发送接收策略，当大量数据到来时如何发送呢？不可能一下子将所有数据都发送出去。所以我们需要一个发送窗体来控制发送数据的个数，当允许发送时就拿出下一个数据包发送，这发生在接收到新的ACK确认或者发送窗体大小调整时。这里和TCP的实现不同，TCP将所有的数据平铺在一个buffer里，然后通过移动滑动窗体来控制发送数据流动。我在这里没有用到滑动窗体，而是将所有的数据包都放到一个权限队列中，按照发送两个高一级权限数据包一个低一级数据包的规则来调整发送顺序，发送窗体中只有inflight的数据包，当可以发送下一个数据包时，再从权限队列中获取。发送窗体负责对发送后的数据缓存，确认，权限队列负责给发送的数据按优先级排序。

对接收端而言，也需要一个接收队列对接收到的数据包进行整理，这里我们可以根据需求的不同实现多种排队策略。如果是想得到TCP的效果，数据即有序，又可靠，那我们需要给所有到达的数据包发送ACK确认且排队，只有前一个数据包排好队，无乱序时，才能将数据反回给上层；如果只实现可靠性，不需要有序，那可以接收到一个数据包时，直接反回给上层，但是要发送ACK确认。如果只需要有序性，不需要可靠性，那可以记录目前收到最大的数据包序号，比这个序号大的数据包返回给上层，比这个序号小的直接丢弃，也不需要发送ACK，因为发送端也不会重传数据。以上就是三种不同的可靠性传输。

前面我们说了很多，数据包即要携带时间戳，又要携带确认ACK，我们需要给上层发下来的数据添加一个自己的协议头以使双端来识别必要的消息，这里我们可以通过不同的控制标识组合来实现一个变长的协议头，有效利用数据包的传输数据量。

其中Flag是必须的，占用4字节的长度，通过位标识后面每个块是否携带，这可以通过手动二进制序列来实现。

现在对于一个传输连接而言，我们有了重传机制，确认机制，协议头封装，传输接收控制，但是网络是公共交通，我们如何遵守交通规则，不引起网络阻塞的同时有效利用网络带宽呢？这就要引入拥塞控制算法，我在这里目前使用的是BBR，还没有实现TCP的CUBIC。那为什么使用BBR算法呢？这可就是小孩儿没娘，说来话长了。简单来讲，常规的CUBIC算法通过检测丢包来判断网络拥塞，然后通过控制发送窗体的大小来控制传输在网络中的数据量。大家想一下网络中的传输情况：

CUBIC算法在第3阶段检测到丢包，开始减小发送窗体的大小，以收缩网络中传输的数据量，消化路由器排队队列，但是这时已经晚了！在没有发生丢包之前，链路中已经被数据包压的苦不堪言，发送数据的RTT时间已经非常慢。什么时候是链路利用率最高的时候呢？即在2阶段路由器即将有排队情况出现的时候，这时RTT时间最小，但是链路上已经有足够的数据在飞。CUBIC算法还有一个问题是其控制的输出变量只有发送窗体的大小，当发送窗体增大，应用层有数据到来时，会一股脑的将可发送的数据量全部发送出去。现实生活中的十字路口，大家都会遵守交通规则，通过红绿灯控制来保证每个路口都定时的可以让一些车辆通过，然而到了网络世界里一切都变的蛮不讲理，在此路口车很多的情况下，所有车都一个接一个的驶出，而不管交叉路口还有没有别的车等待，这是不对的。所以BBR算法不仅需要控制发送窗体的大小来控制发送的数据量，还通过RTT时间和传输的数据量来计算一个数据的发送速度，通过控制数据流发送的时间间隔，来实现按一定速率发送数据。具体BBR算法是如何实现的，那就是另外一篇长篇大论了，本文不再细说。

到目前为止，关于可靠性和传输效率的机制我们基本已经介绍完成，接下来说下传输的建立和连接。传输建立时并没有参考TCP的三次握手，依照UDP的简单粗暴，发送端只管发送数据，接收端能收到算建立了连接，没有接收到则发送端超时。因为我们的协议实现在应用层，没有进程启动的时候也无法发送RST给对端。连接断开时基本参考了TCP的四次挥手实现，继续保留了TIME_WAIT状态来保证网络中上一个连接的数据包不会发送到现任连接上。

关于实现的大体机制终于讲完，其他还有一些数据包序列号标识，随机首个序列号，flow queue，pacing实现等细节没有展开，但核心的可靠实现基本就是以上，接下来画一张数据流向图：

在socket上有一个Filters process，这是一个过滤器责任链，所有收发的数据都要通过这个过滤器责任链，其可以对传输的包体进行压缩，加密等处理，我在这里实现了snappy对传输数据的压缩过滤器，额外线程通知过滤器，和大数据包的拆分过滤器。通过双向链表管理所有的过滤器模块，可以很方便的嵌入额外的过滤器过程，在这里也可以实现一些熔断转发之类服务治理相关的过滤器。

‘捌’ BBR是什么意思

BBR是一个汽车模型品牌。

BBR是一个全球汽车模型的传奇品牌，其产品充满了超级汽车的激情和动感，同时也兼具了汽车模型产品特有的精细和巧夺天工。B.B.R品牌的诞生，来源于品牌创始团队：Balestrini、Barberis、Reali三人姓名的缩写。

1994年b.b.r.的车模被德国一家着名的模型杂志“model fan”评为“”modell des jahres”年度车模的荣誉. 这成为b.b.r发展历史上的重要里程碑，b.b.r的1：43汽车模型，成为全球汽车模型质量卓着、精致考究的代名词。

(8)bbr算法路由器扩展阅读：

BBR模型种类

1、黏土模型

黏土材料来源广泛取材方便价格低廉经过“洗泥”工序和“炼熟 过程 其质地更加细腻。黏土具有一定的粘合性 可塑性极强 在塑造过程中可以反复修改 任意调整、 修、 刮 、填，补比较方便。还可以重复使用是一种比较理想的造型材料。

2、石膏模型

石膏价格经济，方便使用加工，用于陶瓷、塑料、模型制作等方面。石膏质地细腻，成型后易于表面装饰加工的修补，易于长期保存，适用于制作各种要求的模型，便于陈列展示。

3、塑料模型

塑料是一种常用制作模型的新材料。塑料品种很多，主要品种有五十多种，制作模型应用最多的是热塑性塑料，主要有聚氯乙烯（PVC）、聚苯乙烯、ABS工程塑料、有机玻璃板材、泡沫塑料板材等。聚氯乙烯耐热性低，可用压塑成型、吹塑成型、压铸成型等多种成型方法。

4、木制模型

我们使用的木材一般都是经过二次加工后的原木材和人造板材。人造板材常有胶合板、刨花板、细木工板、中密度纤维板等。家具的模型制作常用木头制作。

‘玖’ 如何开启Linux BBR算法提升网络速度

仅在Ubuntu，Arch，Manjaro 下测试过，其它发行版同理。
Arch/Manjaro

虽然 Arch/Manjaro 可以直接安装 linux49 包。但默认没有开启 BBR。需要手动编译。下载 manjaro/packages-corelinux49 包的所有文件，将 config 以及 config.x86_64 文件中的

# CONFIG_TCP_CONG_BBR is not setCONFIG_DEFAULT_CUBIC=y

改为

CONFIG_TCP_CONG_BBR=yCONFIG_DEFAULT_BBR=y

然后将 PKGBUILD 中第二三个 hash 改为 'SKIP'. 执行 makepkg -si 即可。

Ubuntu

‘拾’ TCP拥塞控制及BBR原理分析

导语：TCP拥塞控制不仅仅是网络层的概念，可以将其归属于控制论的范畴。在TCP的演进过程中，出现了很多优秀的思想和算法，以实现网络传输过程中，在公平竞争性的前提下，尽可能地利用带宽资源。本文介绍TCP发展过程中出现的几种拥塞控制算法，并着重介绍BBR的原理。

TCP拥塞控制不仅仅是网络层的概念，可以将其归属于控制论的范畴。在TCP的演进过程中，出现了很多优秀的思想和算法，以实现网络传输过程中，在公平竞争性的前提下，尽可能地利用带宽资源。

公平性是在发生拥塞时各源端（或同一源端建立的不同TCP连接或UDP数据报）能公平地共享同一网络资源（如带宽、缓存等）。处于相同级别的源端应该得到相同数量的网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，争抢能力弱的数据流将受到更多损害。因此，没有拥塞，也就没有公平性问题。

TCP层上的公平性问题表现在两方面：

（1）面向连接的TCP和无连接的UDP在拥塞发生时对拥塞指示的不同反应和处理，导致对网络资源的不公平使用问题。在拥塞发生时，有拥塞控制机制的TCP会按拥塞控制步骤进入拥塞避免阶段，从而主动减小发送到网络的数据量。但对无连接的数据报UDP，由于没有端到端的拥塞控制机制，即使网络出现了拥塞，也不会减少向网络发送的数据量。结果遵守拥塞控制的TCP数据流得到的网络资源越来越少，没有拥塞控制的UDP则会得到越来越多的网络资源。

（2）TCP连接之间也存在公平性问题。产生问题的原因在于使用了不同的拥塞控制算法，一些TCP在拥塞前使用了大窗口尺寸，或者它们的RTT较小，或者数据包比其他TCP大，这样它们也会多占带宽。

拥塞控制主要包括四个过程：1）慢启动；2）拥塞避免；3）拥塞发生；4）快速恢复。

RTT ：数据包从发出去到收到对它的ack的来回时间，采用平滑方式计算RTT

RTO ：重传超时。简单的如RTO=n*RTT, n=3（或其他RTO计算方法）

SACK ：TCP Option携带多组ACK信息

FR ：Fast Retransmission，收到3个p ack后，即可认为发生了丢包。不需要等待RTO超时即可重传丢失的包。

ER ：Early Retransmission，无法产生足够的pack和没有新的数据包可以发送进入网络的情况下，减少触发FR的p ack数量，以达到触发FR的目的。

TLP ：如果发生了尾丢包，由于尾包后面没有更多的数据包，也就没有办法触发任何的pack。实际上，Google统计超过70%的RTO是尾丢包导致没有任何p

ack 。TLP算法是通过发送一个loss probe包，来产生足够的SACK/FACK的信息以触发RF。

Pacing ：控制发送速率，防止bursting

流控 ：Flow control站在单条TCP连接的维度，目的是让发送方发包的速度，不超过接收方收包的能力。所以流控解决的问题是，如何在接收方可承受的范围内，让单条 TCP 连接的速度最大化。通过滑动窗口机制实现。

拥塞控制 ：Congestion control站在整个互联网的维度，让网络里所有TCP连接最大化共享网络通道的同时，尽可能的少出现网络拥塞现象，让网络世界里的每一个参与者既公平又高效。

cwnd ：发送窗口，拥塞窗口；在拥塞控制过程中窗口大小值变化。

rwnd ：接收窗口，通知发送者能够发送的数据大小。

sliding window ：滑动窗口，只是一种抽象机制概念；在发送请求及收到ack的过程中滑动。

历史上出现的各种TCP拥塞控制算法，其本质是针对拥塞控制的四个过程做策略调整。按照算法依据的因素，可以简单的分为以下类型：

因为Reno等算法是后续算法的基础，这里详细的描述下Reno算法的过程。

（1）慢热启动算法 – Slow Start

（2）拥塞避免算法 – Congestion Avoidance
当cwnd >= ssthresh时，就会进入“拥塞避免算法”。算法如下：

（3）拥塞状态算法 – Fast Retransmit
Tahoe是等RTO超时，FR是在收到3个plicate ACK时就开启重传，而不用等到RTO超时。拥塞发生时：

（4）快速恢复 – Fast Recovery

Reno算法以其简单、有效和鲁棒性，应用最广泛。该算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制，是现有的众多算法的基础。从Reno运行机制中很容易看出，为了维持一个动态平衡，必须周期性地产生一定量的丢失，再加上AIMD机制--减少快，增长慢，尤其是在大窗口环境下，由于一个数据报的丢失所带来的窗口缩小要花费很长的时间来恢复，这样，带宽利用率不可能很高且随着网络的链路带宽不断提升，这种弊端将越来越明显。另外，丢包并不一定是网络拥塞，可能是网络常态，但是基于丢包的拥塞控制并不能区分。

vegas通过对RTT的非常重的监控来计算一个基准RTT。然后通过这个基准RTT来估计当前的网络实际带宽，如果实际带宽比我们的期望的带宽要小或是要多的活，那么就开始线性地减少或增加cwnd的大小。

中间路由器缓存数据导致RTT变大，认为发生拥塞；RTT不公平性，当不同的数据流对网络瓶颈带宽进行竞争时，具有较小RTT的TCP数据流的拥塞窗口增加速率将会快于具有大RTT的TCP数据流，从而将会占有更多的网络带宽资源。

在发送端做带宽估计，当探测到丢包时，根据带宽值来设置拥塞窗口、慢启动阈值。 那么，这个算法是怎么测量带宽的？每个RTT时间，会测量一次带宽，测量带宽的公式很简单，就是这段RTT内成功被ACK了多少字节。Westwood会根据RTT变化来判断丢包是否是网络拥塞造成的，还是网络常态的丢包。如果时延变化不明显，就认为是非网络拥塞，此时cwnd减少的比较小。

BIC-TCP是Linux 2.6.18默认拥塞控制算法，依赖丢包条件触发。BIC-TCP认为TCP拥塞窗口调整的本质就是找到最适合当前网络的一个发送窗口，为了找到这个窗口值，TCP采取的方式是(拥塞避免阶段)每RTT加1，缓慢上升，丢包时下降一半，接着再来慢慢上升。BIC-TCP的提出者们看穿了事情的本质，其实这就是一个搜索的过程，而TCP的搜索方式类似于逐个遍历搜索方法，可以认为这个值是在1和一个比较大的数(large_window)之间，既然在这个区间内需要搜索一个最佳值，那么显然最好的方式就是二分搜索思想。

BIC-TCP就是基于这样一个二分思想的：当出现丢包的时候，说明最佳窗口值应该比这个值小，那么BIC就把此时的cwnd设置为max_win，把乘法减小后的值设置为min_win，然后BIC就开始在这两者之间执行二分思想--每次跳到max_win和min_win的中点。

BIC也具备RTT的不公平性。RTT小的连接，窗口调整发生的速度越快，因此可能更快的抢占带宽。

CUBIC在设计上简化了BIC-TCP的窗口调整算法，在BIC-TCP的窗口调整中会出现一个凹和凸(这里的凹和凸指的是数学意义上的凹和凸，凹函数/凸函数)的增长曲线，CUBIC使用了一个三次函数(即一个立方函数)，在三次函数曲线中同样存在一个凹和凸的部分，该曲线形状和BIC-TCP的曲线图十分相似，于是该部分取代BIC-TCP的增长曲线。另外，CUBIC中最关键的点在于它的窗口增长函数仅仅取决于连续的两次拥塞事件的时间间隔值，从而窗口增长完全独立于网络的时延RTT，使得连接之间保持良好的RRTT公平性。

来看下具体细节：当某次拥塞事件发生时，Wmax设置为此时发生拥塞时的窗口值，然后把窗口进行乘法减小，乘法减小因子设为β，当从快速恢复阶段退出然后进入到拥塞避免阶段，此时CUBIC的窗口增长开始按照“凹”式增长曲线进行增长，该过程一直持续直到窗口再次增长到Wmax，紧接着，该函数转入“凸”式增长阶段。该方式的增长可以使得窗口一直维持在Wmax附近，从而可以达到网络带宽的高利用率和协议本身的稳定性。

CUBIC窗口的增长函数：W(t) = C * (t-K)3 + Wmax, 其中C和β为常量。

t为当前时间距上一次窗口减小的时间差，而K就代表该函数从W增长到Wmax的时间周期。

通俗一点讲，假如我们知道了Wmax，那么CUBIC的核心思想就是需要在连续两次拥塞期间执行完上面的三次函数增长曲线

BBR通过实时计算带宽和最小RTT来决定发送速率pacing rate和窗口大小cwnd。完全摒弃丢包作为拥塞控制的直接反馈因素。

传统的拥塞控制算法是计算cwnd值来规定当前可以发送多少数据，但是并不关注以什么样的速度发送数据。如果简单而粗暴地将窗口大小（send.cwnd、recv.cwnd的最小值）数据全部突发出去，这往往会造成路由器的排队，在深队列的情况下，会测量出rtt剧烈地抖动。bbr在计算cwnd的同时，还计算了一个与之适配的pacing rate，该pacing rate规定cwnd指示的一窗数据的数据包之间，以多大的时间间隔发送出去。

我们知道，网络工作的最优点是在物理链路延迟状态下，以最大速率传输数据。传统的拥塞控制算法思想是根据数据传输及ACK来确定RTT，但是这个RTT并不是物理链路延时，可能包含了路由器缓存耗时，也可能是拥塞状态下的耗时。传统的带宽计算也是在不断的试探逼近最优发送窗口，并在RTT或者统计周期内计算带宽。这种情况下，RTT并不是真正的物理链路延迟，带宽也有可能是在有路由缓存或丢包状况下计算得到，那么必然得到的不是精准的值。

BBR摒弃了丢包和实时RTT作为拥塞控制因素。引入BDP管道容量来衡量链路传输水平。BBR追求的是在链路最小RTT（物理链路延迟）的状态下，找到最大带宽。

首先我们认为网络最优点是可以达到的。下面描述RTT及收包速率与数据包投递速率的关系。

图中上半部分的过程可以描述为：随着数据包投递速率增加，如果没有超过最优带宽，则RTT不会变化，此时的RTT是物理链路延迟。随着投递速率继续增加，这时中间路由节点可能出现需要缓存数据包的情况，这会导致RTT变大。如果投递速率继续增加，超过路由缓存能力，则可能出现丢包。

图中下半部分的过程可以描述为：随着数据包投递速率增加，如果没有超过最优带宽，则发送方确认接收端收到的数据速率增加。随着投递速率继续增加，因为数据包缓存在中间路由，这些包并不能及时得到ACK，因此发送方得到的ACK速率，即发送发确认接收方收到数据的速率会维持不变。如果投递速率继续增加，超过路由缓存能力，则可能出现丢包。

1）应答了多少数据，记为delivered；
2）应答1）中的delivered这么多数据所用的时间，记为interval_us。
将上述二者相除，就能得到带宽：bw = delivered/interval_us；该计算方法不关注数据包ack及顺序，是纯粹的标量。

我们可以根据图示很容易算出从Delivered为7时的数据包被确认到X被确认为止，一共有12-7=5个数据包被确认，即这段时间网络上清空了5个数据包。我们便很容易算出带宽值了。

当10s内没有发现最小RTTProp时，就要进入ProbeRTT状态。在ProbeRTT状态，仅发4MSS/RTT(接近停止发送)，从而排空链路上的数据包，测量真实的RTTProp。这里带来的一个问题是，在一个RTT时间内以4MSS速率发送可能会造成抖动，特别是长RTT场景。具体的参考willko文章《GBN手札-BBR实时大数据传输之痛》。