文章目录
一、理论基础
1.1拥塞
是什么
- 太多主机，太快速度，传输太多数据
- 到网络中
- 超出网络处理能力
- 导致大量数据分组拥挤在网络中间设备(如路由器)队列中等待转发
- 网络性能显著下降的现象
后果
- 数据分组通过网络时延增长
- 由于队列满导致大量分组被丢弃
1.2拥塞控制
是什么
- 合理调度、规范、调整向网络中
- 发送数据主机数量、发送速率或数据量
- 避免或消除已有拥塞
方法
可以得出TCP的拥塞控制属于无需拥塞状态反馈
二、TCP的拥塞控制
是什么
端到端的角度，检测网络是否阻塞，如果是，立即将数据发送速率降下来
方法
AIMD(加性增长，乘性减少)
当网络不拥塞时，加性增长窗口大小，当网络拥塞时，乘性减少窗口大小，下面具体介绍
2.1TCP拥塞控制算法
(一)慢启动与拥塞避免算法
如图所示：
理解图的基础概念
RTT：定义从发送端发出一个报文段到收到对这个报文段的确认时间时间间隔的往返时间
CongWin变量： 发送端的拥塞窗口CongWin变量，单位字节，表示未收到接收端确认情况下，可以连续发送的字节数，大小随网络拥塞程度动态变化
Thershold: 拥塞窗口阈值Thershold，慢启动与拥塞避免的转折点
解释算法图过程
慢启动阶段
采用试探的方法，初始将CongWin设置为MSS(最大报文段长度)，在RTT时间内，每收到一个ACK，CongWin加一个MSS，当增加到拥塞窗口阈值Thershold时，进入
拥塞避免阶段
此阶段窗口大小缓慢增长，当前窗口所有报文段得到确认时，窗口大小增长一个MSS(不论收到几个ACK)，此时CongWin呈线性增长(加性增长)，当出现计时器超时时(网络拥塞)
如何解决网络拥塞
拥塞窗口CongWin值变为1(乘性减少)，进入慢启动阶段，此时拥塞窗口阈值Thershold变为网络拥塞时窗口大小的一半(如图Thershold的更新值为12)
难以理解的点
RTT一般时间比较长，可以将拥塞窗口所有报文段全部发送出去
所以在慢启动阶段，在RTT时间间隔内收到几个ACK则窗口大小增长几个，一般说RTT时间间隔中是成倍增长，如图
而在拥塞避免阶段，一个RTT时间间隔内不管收到几个ACK，只窗口大小增加1
(二)快速重传与快速恢复算法
为什么有这个算法？
区分计时器超时和三次重复确认情况
在上篇博客提过，计时器超时及三次重复确认ACK都被视为丢失，而在这里同样被视为网络拥塞，而发送端可以收到接收端的确认，事实上和真正的网络拥塞不一样，于是就有了这个算法
提一下三次重复确认
虽然seq=200的报文段没有超时，但经过三次重复确认依旧会重传
快速重传与快速恢复算法图
与上一个算法不同的是:
当收到3次重复ACK时，会将拥塞窗口CongWin直接调为拥塞窗口阈值Thershold，然后进入拥塞避免阶段，这也就是快速恢复，恢复的是CongWin值
三、流量控制与拥塞控制的区别
流量控制控制端到端的数据，拥塞控制控制全局网络的速率
假如网络拥塞的话，接收方有再大的缓存，数据也接收不到
两种控制的实现都通过动态改变发送窗口大小，发送窗口大小取两种控制的最小值
