TCP之流量控制、拥塞控制

理想上，A 向 B 发送数据包，B 收到后回 ACK，可现实不会这样，往往是不等 B 回应，A 连续发送（比如给武汉运输口罩，不是等武汉人员回应我收到了口罩，才发第二车，往往是连续发好几车，能提高效率），那么，就会带来一个问题，那连续发多少量是合适的呢？发的太多，如果网络拥堵或者对方接收不了这么多，发的太少，效率低下，如何控制发送量的问题呢？
发送量的控制一般和网络情况和接收方的接收能力有关，那就从这两方面对发送量进行一个控制
接收方的能力—流量控制
网络情况—拥塞控制

流量控制—根据对方的接受能力调整发送量

目标：根据接收方的接受能力来调整发送方的发送量
准备：发送方如何知道接收方的接受能力—接收方怎么告诉发送方自己的接收能力

1. 什么是接收方的接收能力？

接收方的接受能力就是指还能在接收缓冲区中写入多少数据，站在发送方角度讲，就是发送方还可以发送且未被应答的数据

2. 接收方如何告诉发送方自己的接受能力？

通过 TCP 头部的 16 位窗口大小，发送方可以告诉接收方我的能力是多少，接收方也可以告诉发送发自己的接受能力

3. 发送发如何根据接收方的接受能力来控制发送量（怎样实现流量控制）？—通过滑动窗口

• 滑动窗口是什么?
  滑动窗口是一个类似于窗口一样的东西，是用来告诉发送端可以发送数据的大小
• 为什么会出现滑动窗口？
  在确认应答机制中，对每一个发送的数据必须等到应答以后才能再发下一个数据段，效率较低，使用滑动窗口，可以一次发送多条数据段，提高效率
• 怎么通过滑动窗口实现流量控制？
  
  假设发送缓冲区有这么几部分

1. 蓝色部分是已发送并且被 ACK 的部分，随着数据段逐渐到达接收方，1 号线会向右移，由于网络原因，最多不移动
2. 橙色部分是已发送未被 ACK的部分，随着接收方收到数据段，2 号线会向右移，最多不动
3. 粉色部分是根据接收方接收能力，最多可发的数据部分，随着时间的推移，也会向右移，最多不动
4. 紫色部分是应用层写入的其他数据，4号线是由应用层决定的，如果应用层写的数据多了，4 号线会向右移，如果不写，不移动
5. 在这个过程中，接收方一旦发现自己的接收缓冲区快满了，就会将自己的窗口大小设置为一个更小的值通知给发送方，发送方接收到这个指令后，就会减缓自己发送的速度
6. 如果接收缓冲区已经满了，接收缓冲区会把自己的窗口大小设置为 0，通知接收方，接收方收到这个消息后，会停止发送数据段，随着接收缓冲区的数据被应用层读走，接收缓冲区变大，接收方可能会主动告诉发送方自己现在的窗口大小，发送方又可以发数据段了，如果发送方等一段时间后接受方也没通知发送方自己的窗口大小，发送方会定时发一个空的窗口探测数据段，如果接收方回应了告知发送方自己现在可以接收数据了，两者就继续通信

拥塞控制—根据网络的承载能力调整发送量

怎么获取网络的承载能力？
根据确认应答机制—超时重传—评估重传频率来预估网络的承载能力
那么问题又来了，第一次的时候怎么估计网络的承载能力

慢启动

最开始无法评估重传的概率，TCP 采用谨慎的态度，刚开始采用慢启动，也就是图中满开始的点

指数规律增长

慢启动后，TCP 采用尽可能恢复的策略，采用指数增长

线性增长

TCP 很快能评估出一个稳定值，经过一个阈值（如图所示 16cwnd）后，线性增长

窗口抖动

增长到一定数值后，网络可能会出现拥挤的情况，出现了窗口抖动（丢包/重传频率变高了/网络质量变差了），TCP 再次采取谨慎的策略，将拥塞降为很低的一个值
现在网络比较不好，所以 TCP 采用指数增长到一定阈值（为变差之前拥塞窗口/2，如图 12cwnd）后，采用线性增长，从图中，可以明显看到，此时的线性增长比原来线性增长的慢了

发送方的发送能力 = MIN（接收方的接受能力，网络承载能力）；

流量控制和拥塞控制的区别

相同点：都是为了提高传输的可靠性
不同点：

• 流量控制的作用对象是接收方，怕发送方发的太快，使得接收方来不及处理，是端对端的
• 拥塞控制的作用对象是网络，怕发的太多，太快，造成网络拥堵，发生丢包，会涉及到网络 中所有的主机等