拥塞控制，图文并茂（挺丰富，借鉴较多大佬的思想）

背景：

为了方便解释，假设我们主机A向主机B传输数据

我们知道，两台主机在传输数据包的时候，如果发送方迟迟没有接收方反馈的ACK，那么发送方就会认为它发送的数据包丢失了，进而会重新传输这个丢失的数据包。

然而实际的情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了，而A发送的数据包被堵在了半路，迟迟没有到达B。这个时候A误以为发生了丢包情况，会重新传输这个数据包。

结果是又发一个重复包，又去占用信道资源，使网络更加拥塞。因此我们要进行拥塞控制。

如何知道网络拥塞？

A与B建立连接后，就可以向B发送数据了，但是A并不知道一次连续发送多少个数据包合适，我也把一次发送多少个数据包称为拥塞窗口，用N代表此时拥塞窗口的大小吧。

我们一般采用慢开始+拥塞控制去探测网络情况，出现超时现象，说明网络有问题了就需改善：

慢开始：指数增加拥塞窗口大小

拥塞避免：线性增加拥塞窗口大小

背景：

为了方便解释，假设我们主机A向主机B传输数据

结果是又发一个重复包，又去占用信道资源，使网络更加拥塞。因此我们要进行拥塞控制。

如何知道网络拥塞？

我们一般采用慢开始+拥塞控制去探测网络情况，出现超时现象，说明网络有问题了就需改善：

慢开始：指数增加拥塞窗口大小

拥塞避免：线性增加拥塞窗口大小

cwnd:拥塞窗口大小

ssthresh:指数增长阈值，达到这个阈值，窗口数量增加规律从指数变为线性

如果发生了超时现象(没有收到ACK，定时器到了)，那么会从1开始一个一个传(打回原形)，并且把指数增长的阈值设置为刚才发生超时的拥塞窗口数量的一半。

超时现象不一定是网络拥塞导致

超时现象可能是因为确认报文中途损坏了。因此防止这种情况出现，我们是通过冗余ACK来处理的。我们知道数据包是有序号的，如果A向B发送M1，M2，M3，M4等数据包，如果B收到了M1，M2，M4,..一直没有收到M3，这个时候接受方会重复确认M2，为了告诉发送发M3还没有收到，可能丢失了。

当A连续收到了三个确认M2的ACK，且M3超时事件还没有发生。A就知道M3可能丢失了，这个时候A不用等到M3设置的计时器过期，而直接快速重传M3，并把指数增加的阈值(7)设置当前拥塞窗口大小（14）的一半，并从这个阈值的时候开始继续传输。

这就是快重传与快恢复的过程

总结

其中我们包含了两种情况，因为重传计时器到期导致超时与三次重复确认的情况，过程图为下：

这种情况是TCP其中一个版本A。

另一TCP版本B，这两种情况下，都是从1开始重传，没有快恢复这种情况。

发送方让自己的发送窗口大小取为为拥塞窗口和接收方的接受窗口中较小的一个。

接受窗口又设计到流量控制：请转入下文

https://blog.csdn.net/qq_40262372/article/details/115787319

借鉴地址：

https://mp.weixin.qq.com/s?__biz=Mzg2NzA4MTkxNQ==&mid=2247485204&idx=1&sn=27daef390eec05b3d5db7cebcdcb4b7c&source=41#wechat_redirect