网络流量控制网络流量监控工具( 三 ) _云知道

拥塞控制算法由于滑动窗口仅考虑接收方的接收能力不考虑网络因素，网络带宽是共享的，网络延时是抖动的，网络的变化带来的问题势必会造成整个系统的崩溃，这就像两个火车站运输货物，仅考虑火车站的容纳量，不考虑火车轨道的承载能力，火车车次发的再多可能也是堵在轨道上，还可能导致轨道系统瘫痪。
拥塞控制算法是发送方根据当前网络情况调整发包速率的流量控制机制，TCP中拥塞控制算法发展至今，从经典的reno到google近年来提出的bbr，期间不断有新的拥塞控制算法提出来，拥塞控制也形成了如下RFC 。
RFC5681
https://datatracker.ietf.org/doc/html/rfc5681
以linux内核为例，最新的内核版本内部实现了十多种拥塞控制算法实现，包括一些比较新的算法实现(比如bbr)，linux较早版本内核使用reno，linux 2.6.8以后默认采用bic算法，linux 2.6.19以后又默认使用了cubic算法，目前linux 5.x依然默认使用cubic算法，windows同样也是支持多种拥塞控制算法的，目前windows11默认也是使用cubic算法。
拥塞算法原理(reno为例)TCP拥塞算法整体框架基本一致，以经典的TCP reno拥塞控制算法(教科书通常讲的版本)进行简要介绍，TCP拥塞控制RFC5681规定都包含慢启动、拥塞避免、快重传、快恢复阶段，这又涉及到几个基本参数(cwnd、ssthresh)，cwnd指拥塞窗口的大小，决定了一次发送多少数据包，ssthresh指慢启动阈值。

慢启动

慢启动阶段分为两种，一种是流刚开始cwnd<ssthresh时cwnd初始为1MSS(随着硬件更新，Linux最新内核初始为10MSS)并随着RTT呈指数增长，一种是重传超时cwnd恢复初始值重新进入慢启动，慢启动并不表示发送速率增长慢(指数级增长)，个人理解是指从比较低的起始速率来试探网络能力，针对慢启动有提出了ABC(Appropriate Byte Count)算法对慢启动突发而造成超越网络承载能力进行修复，如下两篇关于ABC的RFC 。
RFC3465
https://datatracker.ietf.org/doc/html/rfc3465
RFC3742
https://datatracker.ietf.org/doc/html/rfc3742
首次慢启动最初初始ssthresh都是设置为一个很大的值，这样直到丢包才会进入拥塞避免，后又出现了hystart优化(混合慢启动)，比如预测出理想的ssthresh，从而让首次慢启动不至于丢包才进入拥塞避免(丢包代价太大) 。

拥塞避免

当cwnd>=ssthresh时会进入拥塞避免阶段，cwnd会随着RTT呈线性增长，这个起始是比较保守地试探最大网络能力，不至于网络崩溃。

快重传

【网络流量控制网络流量监控工具】拥塞避免阶段当收到3个连续ACK，表明可能出现了丢包，表明网络出现轻微拥堵，这个时候会进入快重传阶段，ssthresh会设置为0.5 * cwnd，cwnd会设置为ssthresh+3MSS，进行数据包重传进入快恢复阶段。

快恢复

快恢复阶段如果重传数据包后如果依然收不到新数据包ACK而且RTO超时了，表明网络并没有恢复，就会重新进入慢启动阶段，ssthresh会设置为0.5 * cwnd，cwnd会设置为初始值，如果收到了新数据的ACK包，表明网络已恢复，cwnd会设置为ssthresh，进入拥塞避免阶段。
reno拥塞控制算法状态图如下