[TOC]
概述
拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。
流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。
拥塞控制和流量控制的区别
流量控制是点到点的问题，一对一，如果接收方的数据来不及接收那么就能直接找到发送方这个罪魁祸首，主要是因为接收方来不及接受发送方的数据；
拥塞控制是多对一，一个接收方 面对多个发送方出现了网络拥堵，接收方找不到具体的发送方，主要是因为网络发生了堵塞发送方数据迟迟到不了接收方。
接收窗口 rwnd 和发送窗口（min(rwnd，cwnd)）
接收窗口receiver window(即rwnd)，是接收方根据自己的承受能力设置的接收缓存值大小，反映了接收方的接收能力，来做流量控制。
拥塞窗口congestion window(即cwnd)，是发送方根据网络拥塞程度设置的网络窗口值，发送窗口=min(rwnd，cwnd)即是接收窗口和拥塞窗口的最小值，来做拥塞控制。
TCP 流量控制
停止等待协议，连续ARQ协议和滑动窗口协议
停止等待协议
停止等待协议是tcp保证传输可靠的重要途径,”停止等待”就是指发送完一个分组就停止发送,等待对方的确认,只有对方确认过,才发送下一个分组.
停止等待协议的优点是简单,但是缺点是信道的利用率太低,一次发送一条消息,使得信道的大部分时间内都是空闲的,为了提高效率,我们采用流水线传输,这就与下面两个协议有关系了.
连续ARQ协议和滑动窗口协议
这两个协议主要起到解决信道效率低的问题，增大了吞吐量,以及控制流量的作用.
- 连续ARQ协议:它是指发送方维护着一个窗口,这个窗口中不止一个分组,有好几个分组,窗口的大小是由接收方返回的win值决定的,所以窗口的大小是动态变化的,只要在窗口中的分组都可以被发送,这就使得TCP一次不是只发送一个分组了,从而大大提高了信道的利用率.并且它采用累积确认的方式,对于按序到达的最后一个分组发送确认.
- 滑动窗口协议:之所以叫滑动窗口协议,是因为窗口是不断向前走的,该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输,还可以控制流量的问题.
- 累积确认:如果发送方发送了5个分组,接收方只收到了1,2,4,5,没有收到3分组,那么我的确认信息只会说我期望下一个收到的分组是第三个,此时发送方会将3,4,5,全部重发一次,当通信质量不是很好的时候,连续ARQ还是会带来负面影响.
流量控制
所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。
TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。
原理这就是运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。
零窗口
只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段
TCP拥塞控制
在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫做拥塞。
拥塞控制的目的就是防止过多的数据注入到网络中，网络堵塞使得包一直到不了接收端。
因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即慢开始（Slow-start)，拥塞避免（Congestion Avoidance)，快重传（Fast Restrangsmit)和快恢复（Fast Recovery）。我们假定
数据是单方向传送，而另外一个方向只传送确认。
接收方总是有足够大的缓存空间，因为发送窗口的大小由网络的拥塞程度来决定。
拥塞控制算法有四种：
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
拥塞控制的流程
慢启动原理
- 当主机开始发送数据时，如果立即将较大的发送窗口的全部数据字节都注入到网络中，那么由于不清楚网络的情况，有可能引其网络拥塞。
- 比较好的方法是试探一下，即从小到达逐渐增大发送端的拥塞控制窗口数值。
- 通常在刚刚开始发送报文段时可先将拥塞窗口cwnd(拥塞窗口)设置为一个最大报文段的MSS的数值。在每收到一个对新报文段确认后，将拥塞窗口增加至多一个MSS的数值，当rwind（接收窗口）足够大的时候
- 为了防止拥塞窗口cwind的增长引起网络拥塞，还需要另外一个变量—慢开始门限ssthresh
拥塞避免
TCP连接初始化，将拥塞窗口设置为1
执行 慢开始算法：cwind按指数规律增长，直到cwind == ssthress开始执行 拥塞避免算法：cwnd按线性规律增长
当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，按照拥塞避免算法继续执行。
快重传和快恢复
从图可以看到，Reno版本相对 Tahoe版本，主要是调整了跳崖式降低发送速率这个地方，如果从0开始效率太低了，如果是男女朋友间在发送微信岂不是被折磨的心痒痒。
拥塞窗口cwnd每次指数增长一次都是在收到了确认报文的情况下增长的，比如A发送1，2，3，4，5，6这些报文段，2丢失了，1345都收到了那么每次345收到都会给A发送确认1收到了的确认报文，让他发2（这个地方上一篇有提到），这种算法就是在2的超时计时器到期之前收到了三个确认之后就马上重传2，接收方都催着要了哥，后面三个确认包都到了说明网络很好的嘛就是你迷路了，因此进行快速重传还是将新的ssthresh值调低为原来拥塞时候的一半又开始线性增长。
快重传
快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。
例如：M1，M2，M3 —–> M1,M3,缺失M2，则接收方向发送方持续发送M2重复确认，当发送方收到M2的三次重复确认，则认为M2报文丢失，启动快重传机制，重传数据，其他数据发送数据放入队列，待快重传结束后再正常传输。
快恢复
快恢复算法有以下两个要点：
- 当发送方连续收到接收方发来的三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半，这是为了预防网络发生拥塞。
- 由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd(拥塞窗口)值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，使拥塞窗口的线性增大。
超时重传（重传机制）
超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。
参考
https://my.oschina.net/manmao/blog/601585
https://cloud.tencent.com/developer/article/1632783
https://blog.csdn.net/weixin_43584807/article/details/93800480