流量控制

TCP协议会根据接收端的缓冲区大小来调整发送速度，剩余空间多则发送速度快，否则降低发送速度

接收端将⾃⼰可以接收的缓冲区剩余空间⼤⼩放⼊ TCP ⾸部中的 "窗⼝⼤⼩" 字段，窗⼝⼤⼩字段越⼤, 说明⽹络的吞吐量越⾼

接收端⼀旦发现⾃⼰的缓冲区快满了, 就会将窗⼝⼤⼩设置成⼀个更⼩的值通知给发送端

发送端接受到这个窗⼝之后, 就会减慢⾃⼰的发送速度，如果接收端缓冲区满了, 就会将窗⼝置为0; 这时发送⽅不再发送数据, 但是需要定期发送⼀个窗⼝探测数据段, 使接收端把窗⼝⼤⼩告诉发送端.

同时如果接收方的缓冲区腾出空间了，会发送窗口更新通知给发送端

窗口的初始大小由三次握手阶段的ACK包来确定

窗口的大小在TCP首部里是16位，但并不意味着最大只能有65535，首部里的选项还包含了⼀个窗⼝扩⼤因⼦M, 实际窗⼝⼤⼩是窗⼝字段的值左移 M 位

滑动窗口

对每⼀个发送的数据段, 都要给⼀个ACK确认应答. 收到ACK后再发送下⼀个数据段. 这样做有⼀个⽐较⼤的缺点, 就是性能较差. 尤其是数据往返的时间较⻓的时候

既然如此，一次发送多条数据而不等待应答就可大大提升效率

如上图，就是选择一次发送四条数据（这里先记住，TCP协议只能像这样一条发送有限字节的数据，图中就是1000字节，也就是一次只能发送1000字节，不能更多，主要是因为数据链路层的限制，一次性只能传输有限字节的数据）

发送前四个段的时候, 不需要等待任何ACK, 直接发送
收到第⼀个ACK后, 滑动窗⼝向后移动, 继续发送第五个段的数据，依次类推
操作系统内核为了维护这个滑动窗⼝, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只
有确认应答过的数据, 才能从缓冲区删掉;
窗⼝越⼤, 则⽹络的吞吐率就越⾼;

所谓窗口，就是你写算法题经常遇到的那个滑动窗口。。。这个窗口内所维护的就是待发送的数据段，窗口左边是确认收到应答的数据段，窗口右边就是以后再发的数据段

窗口大小的确定与TCP首部的16位窗口大小有关，先可以理解为那个字段就是窗口大小，根据上面流量控制的讨论，我们知道，这个大小完全取决于接收端的缓冲区剩余空间大小，由这个参数，滑动窗口就能实现流量控制

窗口具体如何移动，取决于TCP首部的确认应答号

确认应答号i+1表示从1~i序号的数据段全收到了，比如上面的图，如果2001~3000丢包了，只收到了1001~2000，不管后面的数据段接收端是否收到，确认应答号都是2001，注意窗口左边的是已经确认过应答的数据段

根据确认应答号i，可以确定窗口左边left = i;

根据16位窗口大小，确定窗口右边right = left + window;

这样滑动窗口就能向右移动起来，注意上面的计算方式只适用于没有丢包的情况

丢包重传

情况一：数据到达，应答丢失

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进⾏确认，比如上图1~1000的数据丢了无所谓，后续会收到1~2000的确认应答号2001，收到2001，根据确认应答好的定义，1~2000全收到了，不用管1~1000没收到应答

情况二：数据包丢失

接收端根本没收到数据包

对于这种情况，拿下图讨论一下

窗口内的数据段都有可能丢，我们不妨先来回忆一下确认应答号的定义，确认应答号为i表示1~i-1的数据全部收到了，把left赋值为i，表示1~i-1的数据全收到了，如果i <= right，可以看出丢包了，那么i~right的每一个数据段，都有可能丢包了，但是，我们只需要处理最左边的数据段，即以left为开头的第一个数据段，把它重发即可

做完之后，如果确认应答号i > right，直接left = i, right = left + window，否则说明仍有丢包的，假设刚才发的以left为开始的第一个数据段为丢包，那么确认应答号i肯定大于left，直接left = i，然后完全重复上面的工作即可

实际中可能不能根据i <= right来判断是否丢包，因为收到的确认应答号总是要更小的，以下图为例

判断是否丢包，一般根据是否收到3次重复的确认应答为准，不是两次是因为，数据包到达时间并不严格按照发送先后时间，可能3001~4000比2001~3000先到达，导致收到了两次重复的确认应答号，所以一般设置为3次，3次一般足够精确，再多又不好了