目录
一. 前言
二. 流量控制
三. 拥塞控制
一. 前言
TCP的可靠传输依靠确认应答机制，超时重传机制是对确认应答的一种补充，解决了丢包问题
为了提高传输效率，避免大量的时间都浪费在等待应答的过程，故引入了滑动窗口机制，将等待策略进行调整，一次性发送多个数据然后等待，滑动窗口的窗户大小决定了传输效率
通过流量控制和拥塞控制机制，共同决定窗口的大小
二. 流量控制
众所周知，窗口越大，一次携带的数据就越多，传输效率就越高，但是窗口不能无限增大，如果窗口过大，可能会影响传输的可靠性（TCP中可靠性最重要）
窗口过大
- 窗口过大，传输效率太快，可能会出现接收方处理不过来，那么可能会出现丢包问题
- 如果接收方缓冲区，已经满了，仍然传入数据，那么多出来的数据就会丢掉
- 丢包数据即使重传，依然没有意义，因为缓冲区还是满的
如果出现缓冲区满的问题，那就只能停下，等接收方处理一些数据之后，再发数据
这种缓冲区满了，就停下来的行为，肯定是不可取的，不如控制传输速度
只需要让发送方发送速度和接收方处理速度，步调一致即可，这个过程肯定不是静态的，是一直在变化的
让接收方反过来影响发送方的发送速度即可（流量控制）
接收方如何影响发送方？
接收方在返回ACK报文的时候，在报头中，有一个16位窗口大小，通过这个字段，反馈给发送方将窗口大小设置为多大合适
窗口大小的设置
接收方会根据自己接收缓冲区剩余的大小，作为ACK报文中的窗口大小数值，接收方拿到这个数值进行调整窗口大小
窗口大小最大不是65535字节（16位），可以通过TCP选项中的参数（窗口扩展因子），扩展窗口大小，通常窗口的大小为16位窗口大小*2^窗口扩展因子
接收方如何得知缓冲区满了？
如果接收方收到的ACK报文中，窗口大小为0，则表示接受缓冲区满了，需要停止发送
如何恢复发送？
发送方会周期性的发送窗口探测包（不携带载荷），只是为了触发ACK报文，如果报文中窗口大小不是0，说明又可以发送了
三. 拥塞控制
流量控制关注的是接收方的缓冲区，拥塞控制关注的是传输路况
接收方处理数据的速度很快，但是这会双方通信路况不好，数据不能到达，发送方发送再多的数据也没有用
如果根据某个窗口大小发送数据，但是出现了丢包问题，那么就可以认为通信路径发送了问题，那么就减少窗口大小，如果正常，那么就可以适当放大窗口
由于网络的复杂性和随机性，无法确定什么时候路况好，什么时候不好，窗口大小是一直变化的
经典版本
拥塞控制中如何得知窗口大小？（一个字“试！”）
- 慢启动：由于刚刚开始传输数据，无法准确判断传输的路况，不适合发送大量数据，也有可能传输路况很好，那么通过指数增长窗口大小，可以保证传输的效率
- 拥塞避免：指数增长达到一定的阈值，就会转变为线性增长
- 拥塞处理：这里涉及两种策略：超时重传/快速恢复
为什么指数增长变为线性增长？
一开始使用指数增长，可以让窗口大小快速变大，可以保证传输速率，到达一定的阈值（会变化），如果保持指数增长，会增长太快，可能导致网络拥堵，使用线性增长，可以使窗口持久保持在一个比较高的速率，并且也不容易丢包
为什么会产生拥塞？
线性增长也是一种增长，时间长了，也是会引起丢包问题，一旦出现丢包，就会直接将窗口大小设为较小的值，重新开始，也会重新设置指数增长的阈值
全新版本
这个全新的版本，相比经典版本，更适合现在的网络环境，现在网络环境相比之前不管是网络带宽还是通信质量都有很大的进步
当网络拥堵时，发生数据丢包情况，则会触发快速重传机制，TCP会立即重传丢失的数据包，而无需等待，窗口的大小会变为拥塞时的一半，后续就没有指数增长的过程，一直都是线性增长，下一次拥塞时，在变为原来的一半，线性增长，一直循环
好处
-
避免从慢启动开始，减少吞吐量波动。
-
更平滑地恢复传输速率。
滑动窗口的大小是依靠拥塞控制和流量控制共同实现的，取其中的的最小值
点赞的宝子今晚自动触发「躺赢锦鲤」buff！
