第16章 TCP拥塞控制
TCP的成块数据流、批量数据传输
典型的TCP通常是根据是否存在丢包,判断是否出现拥塞。
在TCP中,丢包被用作判断拥塞发生与否的指标,用来衡量是否实施相应的响应措施。
其他拥塞探测方法,包括时延测量和显示拥塞通知(ECN)
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
cwnd 拥塞窗口;awnd 接收端通知窗口;发送端实际窗口 W;cwnd初始值;W初始值;慢启动阈值ssthresh初始值 ========================================================================================================= cwnd 拥塞窗口:反映网络传输能力的变量(发送方的主动限流) cwnd:获得cwnd的最佳值的唯一办法就是以越来越快的速率不断发送数据,直到数据数据丢包(or网络拥塞) awnd 接收端通知窗口:(接收端对发送方的限流) awnd:通过一个数据包的交换,就可以获取awnd --------------------------------------------------------------------------------- 发送端实际窗口 W W = min(awnd,cwnd) 在外数据值:发送端已发送但还未收到ack的数据 在外数据值总是小于等于发送端实际窗口 W #问题:上面的公式看起来合理,但是因为网络和接收端的情况会随着时间变化,awnd、cwnd也会随着变化 --------------------------------------------------------------------------------- W的最佳窗口大小:带宽延迟积BDP(即速率*RTT) W反映了网络中可存储的待发送数据量大小,其计算值 = RTT与链路中最小通行速率的乘积(即传输路径中的瓶颈) --------------------------------------------------------------------------------- 初始窗口IW 发送方最大段大小SMSS(SENDER MAXIMUM SEGMENT SIZE) = min(接收方MSS,路径MTU) 当SMSS > 2190字节: IW = 2*SMSS 且小于等于2个数据段 当2190 >= SMSS > 1095字节: IW = 3*SMSS 且小于等于3个数据段 当1095字节 >= SMSS: IW = 4*SMSS 且小于等于4个数据段 ###为了简单,我们仅讨论IW = 1 SMSS的情况 即初始化情况下 cwnd = 1 SMSS IW = 1 SMSS --------------------------------------------------------------------------------- 慢启动阈值ssthresh 初始值可以任意设定,比如awnd或者更大。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
慢启动算法;拥塞避免算法;拥塞发生算法;快速恢复 ================================================================================================================= 慢启动算法 慢启动的目的:使tcp在用拥塞避免探寻更多可用带宽之前得到cwnd值,以及帮助tcp建立ack时钟 即在tcp连接之初、RTO超时导致的丢包、tcp发送端长时间处于空闲状态等情况下,tcp连接会启动慢启动;慢启动期间,cwnd快速增长,直到确定一个慢启动阈值; 慢启动算法: 接收到一个数据段的ack之后,cswn值++,接下来会发送2个数据段 如果还能成功收到相应的新ack,cwnd值会由2变4,由4变8,以此类推, 换个说法,每发送一个W窗口大小的数据,并接收到相应的ack,cwnd值翻倍,呈指数上升。 cwnd在慢启动过程中不断增大 W = min(awnd,cwnd) W也在不断增大 ------------------------------------------------------------------------------------------------------------------- 拥塞避免算法 拥塞避免期间,cwnd采用另一种算法增长,相比较慢启动会慢的多 慢启动启动,收到ack,cwnd增加1个SMSS 而在拥塞避免期间,收到ack,cwnd增加 1/k 个SMSS;或者换一种说法,收到了完整的W窗口大小的ack之后,cwnd才增加1个SMSS 拥塞避免算法假设了由比特错误导致丢包的概率很小(远小于1%),因此有丢包意味着出现了拥塞 或者换一种说法拥塞避免算法建立在链路ok的基础上(没有硬件故障因素导致的丢包),认为丢包意味着出现了拥塞 ------------------------------------------------------------------------------------------ 拥塞发生算法 发生超时重传时: ssthresh=cwnd/2 cwnd=1 SMSS 发生超时重传就意味着“一夜回到解放前”,之后就重新开始了慢启动。 发生快速重传时: 快速重传算法是当接收方发现丢了一个中间包时,发送三次前一个包的ACK,于是发送单就会快速重传,不必等待超时再重传。 TCP认为这种情况不严重,因为大部分没有丢失,于是ssthresh和cwnd变化如下: cwnd=cwnd/2 ssthresh=cwnd 进入快速恢复算法(快速重传和快速恢复算法一般同时使用) ------------------------------------------------------------------------------------------ 快速恢复 快速重传和快速恢复算法一般同时使用,快速恢复算法认为,你还能收到3个重复ACK说明网络也不那么糟糕嘛,所以没有必要像RTO超时那样强烈 1.拥塞窗口cwnd=ssthresh+3(意思是确认有3个数据包收到了) 2.重传丢失的数据包 3.如果再收到重复的ACK,那么cwnd+1(需要cwnd+1,才能继续发数据包) 4.如果收到新数据的ACK后,就把cwnd重设为ssthresh的值(取消cwnd的临时膨胀,也称为“收缩”),原因是该ACK确认了新的数据,说明从duplicated ACK的数据都已经收到,该恢复过程已经结束,可以回到恢复之前的状态了,也就是再次进入拥塞避免状态。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
慢启动阈值的计算;TCP Tahoe版本;TCP Reno版本 =========================================================================== 慢启动阈值ssthresh:在没有丢包的情况下,记住上一次"最好的"操作窗口预计值,即记录TCP最优窗口估计值的下界。 当发生重传时,ssthresh = max(在外数据值/2,2*SMSS)【无论超时重传还是快速重传】 在最近的微软下一代TCP/IP协议中,ssthresh = max(min(awnd,cwnd)/2,2*SMSS),即ssthresh = max(W/2,2*SMSS) cwnd < ssthresh,使用慢启动算法 cwnd > ssthresh,使用拥塞避免算法 相等时,两种算法都可以 ---------------------------------------------------------------------------------------------------------------- TCP Tahoe版本(个人总结) 1.TCP以慢启动开始,直至W = 慢启动阈值ssthresh, 2.开始拥塞避免算法 发生丢包(无论超时还是快速重传):cwnd置为1,重新开始慢启动 问题:链路利用率低 ---------------------------------------------------------------------------------------------------------------- Reno算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制 TCP Reno版本: 0.初始化:cwnd=IW,ssthresh取一个较大值(至少为awnd) 1.TCP以慢启动开始,直至W = 慢启动阈值ssthresh, 2.开始拥塞避免算法 发生重传: 快速重传:cwnd = cwnd/2;sshthresh = cwnd,进入快速恢复算法,快速恢复之后继续拥塞避免算法 超时重传:ssthresh=cwnd/2;cwnd=1 SMSS,重新开始慢启动
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
TCP 初始慢启动阈值 ================================================================================= TCP 初始慢启动阈值 第二次慢启动阈值是基于第一次拥塞窗口减半得到的。 初始慢启动阈值: 在具体的实现上,Linux(应该也包括其他 OS)的第一次慢启动阈值,实际上是“无穷大”。它被定义为: #define TCP_INFINITE_SSTHRESH 0x7fffffff #值为2147483647,也就是 2G #发送窗口是拥塞窗口和对方的接收窗口之间的较小值。由于接收窗口理论最大值也只有 1G,因而发送窗口的最大值也是 1G,那么拥塞窗口超过 1G 也已经没有意义了,所以这里的 2G,事实上就是无穷大。 在 Linux 的实现里,初始慢启动阈值肯定在第一个拥塞点之上。 这就造成一个现象:Linux 的 TCP 连接在慢启动后,先碰到的是拥塞点,而不是初始慢启动阈值。 从现象上看就是,TCP 的拥塞窗口在慢启动过程中不断爬升,直到遇到第一个拥塞点(发生丢包或者超时),此时这个拥塞窗口的一半,就是第二次慢启动阈值了。 所以首次慢启动过程中,是不存在拥塞避免阶段的 Linux 为什么会选择这样的初始慢启动阈值呢? 主要原因,是当今的网络条件比多年前好了很多,所以为了“压榨”网络性能,让传输的启动阶段尽可能快地达到理想的传输速度, Linux 在传输刚开始还没有网络质量信息的时候,直接用了“碰到拥塞再快速恢复”的方式。 这比预设一个折中的初始慢启动阈值的情况,会更快地达到理想的传输速度。 《网络排查案例课》答疑(三)| 第11~15讲思考题答案
=====================================================================================================================
《网络排查案例课》09 | 长肥管道:为何文件传输速度这么慢?
该案例涉及TCP/IP多个章节的知识点
RTT出现在第14章
WSopt窗口缩放因子(Window Scale)出现在第13章
带宽时延积出现在第16章"W的最佳窗口大小"
接收窗口、拥塞窗口、发送窗口 出现在第16章
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
案例:长肥管道传输速度慢 ====================================================================== 案例场景: 美国到欧洲需要传递一个95MB的文件,但是速度比较慢,只有400KB+;带宽是有10Gbps的 传输是 scp 拷贝,是基于 TCP 的。 美国到欧洲的时延在 134ms 左右 wireshark I/O Graph 统计的 Bytes 是二层帧的大小,速度在 480KB/s 上下 TCP Stream Graphs 关注的是四层 TCP 段的大小,计算出的结果在456KB/s左右 时延是 134ms,带宽是 10Gbps,那么带宽时延积就是 0.134×10Gb。转换为 Byte 需要再除以 8,得到约 168MB。 所以带宽时延积BDP并不是本次案例限制速度的因素。 这种说法很拗口啊。。。其实就是最大在途数据能够达到BDP,这种就是比较理想的情况 根据Bytes in flight ,发现发送方的窗口大小一直差不多稳定在64KB大小 传输速度 = 64KB/ 0.141s = 453KB/s 根因:限制速度的最大因素,既不是带宽,也不是丢包,而是窗口,确切地说就是接收端(POP 点)的接收窗口。因为这些接收端的设备比较特殊,沿用了老旧的配置,导致 TCP 接收窗口过小。 Window Scale 确实启用了,抓包数据中的接口窗口值有几次的值是 65728,明确超过了 65535。另外,在握手包里也可以看到 Window Scale 被启用的信息: 在某些情况下,这里的 Window Scale 虽然启用了,但无法充分工作,导致实际上这台设备的接收窗口一直被压制在 64KB 附近。 其实本案例还有美国传递到美国的需求,因为距离近,所以延迟小,所以计算出的速度更快,没有引起注意。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
RTT、在途数据、长肥网络、iRTT;带宽时延积BDP ============================================================================================== Round Trip Time(RTT),即往返时间,也叫时延 RTT 越长,报文在“空中”的时间就越长。这些报文就有了一个新的身份,叫做“在途数据”,它的大小,叫做在途字节数。英文是 Bytes in flight。 TCP 详情页的 SEQ/ACK analysis 部分就有 Bytes in flight 信息 在网络世界里,带宽很大、RTT 很长的网络,被冠以一个特定的名词,叫做长肥网络,英文是 Long Fat Network。在长肥网络中的 TCP 连接,叫做长肥管道,英文是 Long Fat Pipeline。 Wireshark在 TCP 详情的 SEQ/ACK analysis 部分,就有 iRTT 信息 iRTT 是 intial RTT 的缩写,Wireshark 就是从 TCP 握手阶段的报文里计算出这个值的。 对于客户端来说,就是发出 SYN 和收到 SYN+ACK 的间隔。(看了抓包文件,iRTT值确实不会变化) 对于服务端,就是发出 SYN+ACK 和收到 ACK 的间隔。 --------------------------------------------------------------------------------------------- 带宽时延积 Bandwidth Delay Product,缩写是 BDP;这是传输链路理论上一直处于传输的数据大小 带宽时延积= 带宽*往返时间(RTT) 但是这个实际大小还得取决于发送端的发送窗口大小 传输速递(带宽) = 发送窗口大小 / RTT 我的理解: 假设TCP的传输速度很稳定,且两端的处理也很稳定,那么同时能发送的数据大小取决于发送窗口大小,发送的速度则是数据大小/RTT,即发送窗口/RTT
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
接收窗口、拥塞窗口、发送窗口;Window Scale ============================================================================================= TCP 有 3 个窗口: 接收窗口:它代表的是接收端当前最多能接收的字节数。通过 TCP 报文头部的 Window 字段,通信双方能互相了解到对方的接收窗口。 拥塞窗口:发送端根据实际传输的拥塞情况计算出来的可发送字节数,但不公开在报文中。各自暗地里各维护各的,互相不知道,也不需要知道。 发送窗口:对方的接收窗口和自身的拥塞窗口两者中,值较小者。实际发送的在途字节数不会大于这个值。 接收窗口是明的,在抓包文件里就能看到;拥塞窗口和发送窗口是暗的,抓包文件里没有。 ---------------------------------------------------------------------------------------------- Window Scale 它是在RFC1323中引进的,使得 Window 值最大能达到 2 的 30 次方,即 1GB。(Window Scale值虽然占用了1个字节,但是最大值为14) Window Scale的作用是向对方声明一个Shift count,我们把它作为2的指数,再乘以TCP头中定义的接收窗口,就得到真正的TCP接收窗口。 接收的窗口=Window * Winsow size scaling factor,也就是304*2的7次方=38912 (wireshark已经帮助我们计算好了) TCP的 Calculated window size显示的是wireshark计算出的接收窗口大小 Calculated window size = window * windows size scaling factor = window * 2的window scale次方 Bytes in flight 就是wireshark计算出的发送方的在途数据大小,相当于发送窗口大小
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
小结: 传输速度的问题,可以说就是窗口和往返时间这两个大玩家在起作用。你只要抓住这两个主要矛盾,就能解决大部分传输速度的问题了。其他因素也可能有它的作用,但一般不是核心矛盾。 时延:也叫往返时间,是通信两端之间的一来一回的时间之和。 在途报文:发送端已经发出但还未被确认的报文,时延越长,发送窗口越大,在途报文可能越多,这两者是正比关系。 带宽时延积:带宽和时延的乘积,表示这个网络能承载的最多的在途数据量。 发送窗口:发送窗口是拥塞窗口和对方接收窗口两者中的较小值。 先获取时延,再定位发送窗口,最后用这个公式去得到速度的上限值。 Wireshark 的一些技巧,包括: 查看 I/O Graph 的方法,这个可以直观地展示数据传输的速度。 查看 TCP Stream Graphs 的方法,这个能看到 TCP 序列号随着时间的变化趋势,同时也可以经过简单计算推导出 TCP 载荷的传输速度(因为没有计入各种报文头部,这个值比 #1 的速度值要略低一些)。 查看 TCP Window Scale 是否启用,以及启用的话,Scale Factor 的值的查找方法。 如果tcp发送buffer也就是SO_SNDBUF只有16K的话,这些包很快都发出去了,但是这16K的buffer不能立即释放出来填新的内容进去,因为tcp要保证可靠,万一中间丢包了呢。 只有等到这16K中的某些包ack了,才会填充一些新包进来然后继续发出去。由于这里rt基本是20ms,也就是16K发送完毕后,等了20ms才收到一些ack,这20ms应用、内核什么都不能做,所以就是如前面第二个图中的大概20ms的等待平台。
超详细的wireshark笔记(3)-TCP窗口和TCP重传
=====================================================================================================================
《网络排查案例课》11 | 拥塞:TCP是如何探测到拥塞的?
该案例涉及TCP/IP多个章节的知识点
Spurious 重传、快速重传、超时重传、重复确认 《第14章》
拥塞窗口CW、接收窗口RW、发送窗口《第16章》
TCP 拥塞控制《第16章》
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
Spurious 重传、快速重传、超时重传、重复确认 ============================================================================= 乱序(Out-of-Order)和 TCP Previous segment not captured。这两者本质上都是乱序引起的现象。 Spurious 重传:这是已经被确认过的数据再一次被重传。 快速重传:收到 3 次及以上次数的重复确认后,不等超时就做出的重传。 超时重传:超时计时器到点而触发的重传。 重复确认:确认号重复的多个报文,重复确认是引发快速重传的原因。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
拥塞窗口CW、接收窗口RW、发送窗口 ======================================================================================================== 自身的拥塞窗口CW(Congestion Window) 拥塞窗口Congestion Window,缩写是 CWND,或者 CW 拥塞窗口是每个连接分开维护的,比如同一个主机有两个 TCP 连接在传输数据的话,那么这两个连接就各自维护自己的拥塞窗口 一个TCP连接有2个拥塞窗口,client端拥塞窗口、server端拥塞窗口 初始拥塞窗口,英文是 Initial Congestion Window(或者 Initial Window),缩写为 ICW(或者 IW)。 在 Linux 内核 3.0 以前,初始拥塞窗口的大小比较小,在 2 到 4 个 MSS。 Linux 内核 3.0 版本及以后的版本中,比如在 include/net/tcp.h 中,就定义了 TCP_INIT_CWND 的值为 10。 对端的接收窗口RW(Receive Window) 发送窗口 = min(CW,RW) 当CW>RW时,一般意味着传输过程中没有或者很少有“拥塞”发生,因而拥塞窗口能增长到较高的值。 此时传输速度的上限就是对端接收窗口值决定的。 所以也就容易在 Wireshark 里观察到 TCP Window Full 这样的现象。当然,也不是每次都一定有 TCP Window Full 当CW<RW时,一般意味着传输过程中遇到了“拥塞”,因而拥塞窗口进行了适配,也就是往下调整,这往往会使得拥塞窗口变得比较小。 --------------------------------------------------------------- 拥塞窗口(CW)和接收窗口(RW)是如何决定了传输速度上限的, 简单来说: 当 RW<CW 时,速度由 RW 决定; 当 RW>CW 时,速度由 CW 决定。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
TCP 拥塞控制主要有四个重要阶段:慢启动、拥塞避免、快速重传、快速恢复 ================================================================================================================== TCP 拥塞控制主要有四个重要阶段: 慢启动; Slow Start,是指 TCP 传输的开始阶段是从一个相对低的速度(“慢”一词的由来)开始的。事实上,在这个阶段,拥塞窗口会以翻倍的方式增长,所以从增长过程来看,叫“快启动”也未尝不可。 在这个阶段,每次 TCP 收到一个确认了数据的 ACK,拥塞窗口就增加一个 MSS。 确认数据的 ACK 报文,而不是重复的 ACK 报文。重复的ACK不会使拥塞窗口增加1个MSS 理论上,每发送一轮拥塞窗口大小的数据,拥塞窗口将会增大一倍;但是实际上由于接收端可能会每2个报文才回一个ack,所以拥塞窗口增大的速度会低于理论值 慢启动停止:1.遇到拥塞;2.达到慢启动阈值 拥塞避免; 慢启动阈值(也有人称之为慢启动门限),英文简称 ssthresh。 拥塞窗口的增长速度立刻就放缓了,变成了每过一个 RTT,拥塞窗口就只增长一个 MSS(此前是每个确认数据的 ACK,增长一个 MSS)。 拥塞避免这个阶段的特征是“和性增长乘性降低”,英文是 Addictive increase/mutiplicative decrease,缩写为 AIMD。 当探测到拥塞,拥塞窗口就要往下降。这个下降是直接减半的,所以叫乘性降低。 快速重传; 超时重传:TCP 每发送一个报文,就启动一个超时计时器。如果在限定时间内没收到这个报文的确认,那么发送方就会认为,这个报文已经在网络上丢失了,于是需要重传这个报文,这种形式叫做超时重传。 一般来说,TCP 的最小超时重传时间为 200ms。 快速重传:一旦发送方收到 3 次重复确认(加上第一次确认就一共是 4 次),就不用等超时计时器了,直接重传这个报文。 快速恢复。 这是 TCP Reno 算法引入的一个阶段,它是跟随快速重传一起工作的。 之前碰到拥塞之后,“慢启动 -> 拥塞避免 -> 慢启动 -> 拥塞避免” 在TCP Reno 算法下,在遇到拥塞点之后,通过快速重传,就不再进入慢启动,而是从这个减半的拥塞窗口开始,保持跟拥塞避免一样的线性增长,直到遇到下一个拥塞点。 哦哦哦,在TCP Reno 算法下,碰到拥塞有2种情况: 1.超时重传,拥塞窗口减半,传输速度降至一个很低的位置,开始慢启动。即"慢启动 -> 拥塞避免 -> 慢启动 -> 拥塞避免" 2.快速重传,拥塞窗口减半,传输速度降至拥塞窗口所在的位置,开始快速恢复,即以一个较高的速度继续拥塞避免阶段 ------------------------------------------------------------------------------------ 慢启动:每收到一个 ACK,拥塞窗口(CW)增加一个 MSS。 拥塞避免:策略是“和性增长乘性降低”,每一个 RTT,CW 增加一个 MSS。 快速重传:接收到 3 次或者以上的重复确认后,直接重传这个丢失的报文。 快速恢复:结合快速重传,在遇到拥塞点后,跳过慢启动阶段,进入线性增长。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
传输速度慢分析技巧 --------------------------------------------------------------------------- 个人理解:(理想状态下的最终速度上限) TCP的传输速度受接口窗口和拥塞窗口大小的限制;也收到RTT的限制;还受到接收端处理速度的限制 传输速度 = 接收端的处理速度/RTT 速度上限是由接收端的处理速度和接收窗口共同决定的 所以可以查看wireshark中的在途字节数,若在途数据等于最大的通告窗口,那么速度上限就取决于接收窗口大小or接收端的处理速度 反之则可能是带宽、发送端发送效率等因素影响发送速度 很多 TCP 实现里(比如 Windows 系统),确认报文是这样工作的:如果收到连续多个报文,确认报文是一个隔一个回复。 即每接收2个报文,回复一个ACK Wireshark 自动找到了被它确认的 16 号报文,也在它的左边打上了一个小小的勾。(wireshark细节)
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
案例:自有机房与公有云之间使用scp传输文件速度慢 ================================================================================================= 案例背景与现象: 客户自己的机房在上海,公有云上的资源则在北京 客户选择了使用公有云的专线产品,也就是在上海自有机房和北京公有云之间,打通了专线。 使用scp传输文件的时候,发现速度只有 200KB/s 左右,达不到购买的专线带宽值。 wireshark I/O Graph查看,发现传输速度忽高忽低,很不稳定,可以基本判断存在链路拥塞现象 分析专家信息,发现很多"out-of-order"和"previous segment not captured",存在数据包乱序的情况 进一步造成了TCP虚假重传,TCP快速重传,但更多的是TCP超时重传;同时也存在很多重复ACK 根因:专线上的限速设置失误造成的 猜测:这个限速应该是通过网络硬件设备完成的,它单位时间内只允许一定字节数的报文通过,如果超过限制,就会丢弃这些报文。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
实验 1:修改初始拥塞窗口;实验 2:改变 TCP 拥塞控制算法 ================================================================================================= 实验一下 拥塞控制机制对 TCP 传输十分重要,技术细节也很复杂,所以是由内核实现的。这也是内核实现 TCP 栈的巨大优势:应用程序可以集中于业务逻辑,而不需要操心传输和拥塞这种底层细节了。 实验 1:修改初始拥塞窗口 当你认为某条链路网络状况比较糟糕,用更低的 ICW 更合理时,可以修改初始拥塞窗口(ICW) 在 Linux 操作系统上,修改初始拥塞窗口的方法是这样的: 1.运行ip route命令,找到当前的路由条目,把整行都进行复制,记为 item: $ ip route default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100 2.运行ip route change item initcwnd n,把路由项 item 的初始拥塞窗口修改为 n,比如改为 2: $sudo ip route change default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100 initcwnd 2 ------------------------------------------------------------------------------------------------------------ 实验 2:改变 TCP 拥塞控制算法 在 Linux 里,我们可以通过 sysctl 命令,查看或者修改这个算法。比如,Linux 默认是用 cubic 算法 $ sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cubic 如果内核大于 4.9,Linux 里就已经默认带有 BBR算法 $ sudo sysctl net.ipv4.tcp_congestion_control=bbr #配置拥塞算法为BBR net.ipv4.tcp_congestion_control = bbr $ sudo sysctl net.core.default_qdisc=fq #调整缓存队列算法 net.core.default_qdisc = fq 把这些配置写入到 /etc/sysctl.conf,即使机器重启,配置也会保持不变。