TCP拥塞控制

最新推荐文章于 2023-12-20 10:22:37 发布

荷西·H

最新推荐文章于 2023-12-20 10:22:37 发布

阅读量1.1k

点赞数 2

分类专栏： network

本文链接：https://blog.csdn.net/Hesy_H/article/details/89387543

版权

network 专栏收录该内容

22 篇文章 0 订阅

订阅专栏

本文介绍一些拥塞控制机制以及他们的迭代。

Tahoe

TCP最早的版本称之为Tahoe。TCP Tahoe 主要有三个机制去控制数据流和拥塞窗口: slow start (SS), congestion avoidance (CA), and fast retransmit(FS)。

SS（slow start）

MSS
(maximum segment size) [ 一般一个MSS是1500B，所以两个MSS就是3KB ]
cwnd窗口
有时候cwnd是按包的数量来刻画的，但实现的时候都是按照字节数来刻画，这里采用前者比较方便阐述，实际上大多数都是采用后者

当connection 建立时，把congestion window 的大小初始化，并设为1个MSS(也有设置成两个，4个或者10个的)，同时把ssthresh (slow start threshold)设为 64 KB。
收到一个ack，就增长一个cwnd窗口

CA ( congestion avoid )

只要有一个packet loss，Tahoe会 [MD]
- ssthrsh 设为目前的congestion window 的一半
- cwnd设置成1，重新开始SS阶段(即之后cwnd以指数速度增长)
当到达ssthresh 时cwnd会以线性成长来避免拥塞。[AI]

如何检测到packet loss --》三个ACK
是结合FS一起的

FS (fast retransmit)

收到三个重复的ack 时，不必等到Retransmit Timeout(RTO)，会认为包丢失，并且马上重传。（无论是超时还是快速重传，都会无条件将cwnd减为1个MSS，重传后重新进入SS阶段）

Reno

Reno增加了一个机制: 快速恢复Fast Recovery(FR)；

FR机制

跟Tahoe一样，当收到三个重复的ack 或是超过了RTO 且尚未收到某个数据报的ack，Reno 会认为有数据报遗失了，并且认定网络发生拥塞。

丢包时Reno 把ssthresh 设为目前cwnd的一半，但并不会回到SS的状态，而是设定cwnd为ssthresh，之后cwnd则维持线性成长。
（因为之前那样的重头回到1的惩罚太严重了）
收到一个包，cwnd就增长一个窗口(MSS) (在拥塞避免阶段是一个RTT只增加一个MSS)

NewReno

部分应答(partial ACK)、恢复应答(Recovery ACK)

Reno快速恢复算法中，发送方只要收到一个新的ACK就会退出快速恢复状态而进入拥塞避免阶段，NewReno算法中，只有当所有丢失的包都重传并收到确认后才退出。
NewReno大约每一个RTT时间可重传一个丢失的数据包，如果一个发送窗口有M个数据包丢失，TCP NewReno的快速恢复阶段将持续M个RTT

SACK

这个文章讲的不错！
实现在了RFC3571中

小总结

快重传(FS)是Tahoe中就有的，但是快速恢复(FR)是Reno才有的，NewReno改进的也是Reno的快速恢复阶段
cwnd就是根据pipe/inflight ( 也就是BDP )大小的一个调控，就是尽量控制链路中的包是合适的大小

降窗

之前的改进重点主要是如何恢复（其实对如何降窗也有一些改进，但是笔墨上，和我理解的文字上要叙述的重点都并不是那个）

DupThresh ：收到重复ACK的阈值
Pipe ：FlightSize，由自己发出的，链路中的数据

RFC3571

其实从NewReno开始，如何降窗就固定了(SACK和NewReno一样)，也就是发现拥塞(丢包)，ssthresh = cwnd /2，cwnd = cwnd /2+3。但实际linux实现中并不是这样，详情请见机器之心2020的梳理:TCP拥塞控制机制
原有的降窗方式缺点：
cwnd就是根据pipe/inflight ( 也就是BDP )大小的一个调控，就是尽量控制链路中的包是合适的大小，一下子陡降，导致inflight比cwnd大得多，那么很长一段时间内，就算接收到了ACK，还是不能发包的，然后就导致链路一下子变得很空。
linux的降窗方式rate halving的优缺点：
- 优点：在快速恢复期间，取消窗口陡降过程，可以更平滑的发送数据
- 缺点：降窗策略没有考虑 PIPE 的容量特征，考虑一下两点：
  - a.**【保守】**如果快速恢复没有完成，窗口将持续下降下去
  - b.**【激进】**如果一次性 ACK/SACK 了大量数据(快速恢复完成地快速)，in_flight 会陡然减少，窗口还是会陡降，这不符合算法预期。【看到没，这里降窗和ACK绑定死了，那么也出了问题…还是得跟ACK脱离，跟绝对时间绑定上（BBR的想法）】

【inflight和cwnd相互影响，没能把窗口拉上来】
dog大佬对于halving和PRR的区别讲的很好
 这篇文章也很不错

PRR

机器之心2020的梳理:TCP拥塞控制机制
 dog大佬对于PRR提出了改进，which我觉得很有借鉴意义
[结合dog和这个的](https://blog.csdn.net/ljy1988123/article/details/51782310?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522159265367619724835839748%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall。 2522％257D＆request_id = 159265367619724835839748＆biz_id = 0＆utm_medium = distribute.pc_search_result.none-task-blog-2〜all〜first_rank_ecpm_v1〜rank_ctr_v4-5-51782310.ecpm_v1_rank_ctr_v4＆utm_term = prr) --》目前的理解:

prr_out决定了cwnd，但是为什么prr_out为0的时候，cwnd也为0，就不晓得了。另一方面，sshthresh以及prior_cwnd是不断在更新么？每个RTT更新一次？应该不至于是ACK更新！?
dog大佬的优化也很值得看一看。

这个总结得也很好:
Tahoe
Tahoe是早期包含在 BCD 4.2 中的一个TCP早期版本。它在连接之初处于慢启动阶段。若遇到丢包事件，无论是超时还是快速重传，都会无条件将cwnd减为1个MSS，重新开始慢启动阶段，将ssthresh减为当前拥塞窗口的一半。对于有较大BDP（带宽延迟积）的链路来说，该方法会使得带宽利用率低下。

Vaegas
Vegas算法试图在维持较好吞吐量的同时避免拥塞。它通过观察RTT来预测网络拥塞。当RTT增大时，Vegas认为网络正在发生拥塞，于是线性降低发送速率。利用RTT判断拥塞使得Vegas算法有较高的效率，但也导致采用Vegas的连接有较差的带宽竞争力。

Reno & NewReno
Reno算法相当于是Tahoe算法的改进。它综合了快速恢复机制，当检测到快速重传时，Reno算法将cwnd减为当前窗口的一半加上3MSS，并将ssthresh设置为当前窗口的一半，然后cwnd进入线性增长。Reno算法存在的问题是它不能有效解决同一窗口丢失多个分组的情况（局部ACK），可能会严重影响网络吞吐性能。NewReno算法对这一问题进行了改进。它记录了上一个数据传输窗口的最高序列号（ACK恢复点），当结束到的ACK序列号不小于恢复点序列号时才会停止快速恢复阶段。NewReno是目前比较常用的一个TCP版本。

BIC-TCP
BIC-TCP算法的主要目的在于，即使在拥塞窗口非常大的情况下也能满足线性RTT公平性。使用二分搜索增大和加法增大两种算法探测饱和点，通过最大值探测机制实现。Linux 2.6.8 至 2.6.17 内核版本中默认开启该算法。

CUBIC
CUBIC算法改进了BIC-TCP算法中在某些情况下（低速网络）增长过快的不足，并对窗口增长机制进行了简化。它通过一个三次函数来控制窗口的增长。除此之外CUBIC还有 TCP友好策略，确保在低速网络中CUBIC的友好性。从Linux 2.6.18 内核版本开始CUBIC成为了Linux默认的TCP拥塞控制算法。

BBR
BBR是goole在2016年下半年公开的一种开源拥塞控制算法，已经包含在了Linux 4.9 内核版本中。采用丢包作为拥塞信号的代价就是，在有一定错误丢包率的链路上，标准拥塞控制算法通常会收敛到一个比较小的发送窗口上，并没有占满网络带宽。BBR不再关注丢包作为拥塞信号，而是通过交替测量带宽和延迟，用一段时间内的带宽极大值和延迟极小值作为估计值的乘积作为窗口估计值，因此BBR可以更充分的利用带宽。目前对BBR的评价有褒有贬，有人说时黑科技，有人说其抢占带宽不道德，有人说这是TCP发展的一大进步也是拥塞控制的未来发展方向，还有人说大范围部署BBR将是一场灾难。。。我对TCP/IP的学习还很皮毛，就不贸然站队了。不过我在境外vps上部署了BBR之后，跑在vps上的ss速度提升非常显著，个人来讲还是很喜欢的:).