TCP拥塞控制
文章目录
一、前言
TCP除了可靠传输和流量控制机制，还有一个机制------拥塞控制~
二、梳理
- 可靠传输：保证传输过程中不丢包
- 流量控制：解决发送端和接收端处理速度不协调的问题
- 拥塞控制：网络集合之间的互相关系
三、拥塞控制
3.1 概念
在某段时间内，若对网络中某一资源的需求超过了该资源所提供的可用部分，网络性能就要变坏，这种情况就叫做拥塞（congestion）
网路层没有重传机制 ，一定会丢包。整个过程是类似交通堵塞的。
怎么解决呢？拥塞控制关注的是整体。
这里也采用窗口的方法，先试探，如果路不好走就降低速度或采取别的路。相比之下，流量控制是考虑端与端的传输，更讲究协商的方法。
- 计算机网络中的链路容量（带宽）、交换节点中的缓存和处理机等都是网络的资源
- 拥塞控制是一个全局性的过程
- 涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素
- 是需要靠所有节点共同努力的结果
- 防止过多的数据注入到网络中，使网络能够承受现有的网络负荷
- 相比而言，流量控制是点对点通信的控制
3.2 拥塞控制的常用算法
-
方法概述
慢开始（slow start，慢启动）、拥塞避免（congestion avoidance）、快速重传（fast retransmit）、快速恢复（fast recovery）
-
几个缩写
-
cwnd（congestion window）：拥塞窗口
试探出来的。一开始窗口很小，随着试探，窗口不断增大（但是不能超过接收窗口）
-
rwnd（receive window）：接收窗口
-
swnd（send window）：发送窗口，swnd = min(cwnd, rwnd)
发送窗口就是拥塞窗口和接收窗口的最小值
-
3.2.1 慢开始
MSS：最大段的长度，发送数据是按段发送的，尽管它的单位是字节，因此需要告知最大段是多少。
先发了100的数据包，进行试探。发M2和M3实际是确认1次
- cwnd的初始值比较小，然后随着数据包被接收方确认（收到一个ACK）
- cwnd成倍增长（指数级）
- 当增长到会丢包时开始往回调整（一直在试）
3.2.2 拥塞避免
-
ssthresh（slow strat threshold)）：慢开始阈值，cwnd达到与之后，以线性方式增加
不是到了阈值就丢包哦~
-
拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞
不会超过接收窗口的
-
乘法减小：只要网络出现拥塞，把ssthresh减为拥塞峰值的一半，同时执行慢开始算法（cwnd又恢复到初始值）
-
当网络出现频繁拥塞时，ssthresh值就下降的很快
3.2.3 快重传
如何出现快速丢包呢？
当M3丢包时，此时M4、M5等已经发送，正常来说，应该回一个SACK（选择确认）包，但是现在变了，继续重复确认M2（请求发送M3），当收到3个连续的M2重复确认，才会重传M3。而M4、M5、M6都会记录的（发送方有缓存），最后会确认M6。
-
接收方
- 每收到一个失序的分组后就立即发出重复确认
- 使发送方及时知道有分组没有到达
- 而不要等待自己发送数据时才进行确认
-
发送方
-
只要连续 收到3个重复确认（总共4个相同的确认 ），就应当立即重传对方尚未收到的报文段
在这里M3不属于超时重传，是快重传，不会调整cwnd（拥塞窗口）
-
而不必继续等待重传计时器到期后再重传
改进机制：对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞而错误地把拥塞窗口cwnd的值减为1。实践证明，使用快重传可以使整个网络的吞吐量提高约20%
-
3.2.4 快恢复
现在的主流方法
- 当发送方连续收到3个重复确认，说明网络出现拥塞
- 就执行"乘法减小"算法，把ssthresh减为拥塞峰值的一半
- 与慢开始不同之处是现在不执行慢开始 算法，即cwnd现在不恢复到初始值
- 而是把cwnd值设置为新的ssthresh值（减小后的值）
- 然后开始执行拥塞避免算法（"加法增大"），使拥塞窗口缓慢地线性增大
到底怎么界定出现3个重复确认是个别情况还是拥塞？
快重传 + 避免拥塞 + 慢开始 / 快恢复都是可以的，甚至阈值可以在编程时自己指定
四、小结
到此，滑动窗口才真正有了含义，并不单单取决于通信双方的约定，更考虑的是集合的通信，是不断地试探，才确定下来的。