TCP协议二 （滑动窗口，流量控制，拥塞控制）

滑动窗口

如果只是一发一收这种方式（如上图）虽然可靠性保证了，但是未免速度太慢了吧。。。为了改进这种方式，TCP协议加入了滑动窗口这个概念。
什么是滑动窗口呢？
说直白点吧。假如我去逛商场，想买杯COCO奶茶，也想买铁板牛筋，还想买点牛肉饼。店家接到订单后才会开始做，我不可能等一个做好再去买下一个吧，我肯定是在这边下完单再跑去其他两家店下单，目的就是为了重叠无用的等待时间。滑动窗口就是这个原理（如下图）。

那么有了滑动窗口怎么保证数据传输的可靠性呢？
场景一：丢ACK：

其实丢ack问题不是很大，我们都知道ack是接收方发送个发送方的一个应答报文段，加入我们丢了1001这个ack，发送方继续传输，如果下一个ack的序列号是2001，那么我们可以认为我们的1-1000的数据对方已经接收到了，只不过是ack丢了，问题不大。
场景二：丢包

当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001” 一样;
如果发送端主机连续多次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 -
2000 重新发送;
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;
这种机制被称为 “高速重发控制”(也叫 “快重传”)。

流量控制

什么是流量控制：
TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制
为什么会引入流量控制这个概念呢？
因为窗口的大小不是随意定的，太大的话相应的接受方的缓存也需要足够大，但是我们又不知道接收方的缓存区是多大。第二个原因是接收方的处理速度如果太慢，会造成丢包的后果，如果是这样的话，就得不偿失了。
流量控制图

接收端如何把窗口大小告诉发送端呢?
TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息，表示接收方还有多少缓存空间，每次通过告诉发送方还有多少剩余空间的方式就是流量控制。

拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实
际发送的窗口;

像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.
为了不增长的那么快， 因此不能使拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阈值，当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长。
当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案。