TCP特性的滑动窗口，流量控制

目录

一、TCP特性滑动窗口

二、TCP特性流量控制（作为滑动窗口的补充）

---

一、TCP特性滑动窗口

提高传输效率（更准确的说，让TCP在可靠传输的前提下，效率不太拉跨）

当然你要是想让TCP媲美UDP，也是痴人说梦，只能说减小差距。

一次性发一组数据，发数据的过程中，不需要等待ACK，就直接往前发，此时相当于“一份等待时间”等待四个ACK，把一次发多少数据，不用等待ACK这样的大小，称为窗口。 

窗口越大，此时批量发送的数据越多，效率越高，但是窗口不能无限大，如果是无限大，相当于完全不必等待ACK，此时就和不可靠传输差不多了，如果你无限大，接收方是否可以处理过来，中间设备是否可以承受住，都是未知数

那么为什么要叫“滑动窗口”，哪里有滑动呢

当前A给B发送了1001——2000，2001——3000，4001——5000这样的数据，需要等4个对应的ACK，这四个ACK到达顺序，也会有先有后，如2001->3001->4001->5001这种顺序到达。

那么问题来了，大家觉得 2001到达主机B的时候A是否继续往下发下一条信息？还是等待5001到了，才继续发下一组消息。

当然是2001到达主机B的时候，A可以继续往下发下一条信息（要不等到5001，那不是一样的慢吗）

收到2001这个ACK之后，于是A就立即发送5001-6000这个数据，此时A等待ACK，3001->4001->5001->6001，仍是等待4条ACK，还是窗口一样的大，但是往后挪动了一个格子，直观来看：窗口往后挪了一步

滑动窗口是一个“形象的比喻”，实际本质批量发送数据（可以缩短时间，但是还需要等待）

批量传输的方式传输，中间丢包了咋办。

对于TCP来说，必然不会影响他的可靠性啊

两种情况：

1.数据丢了

2.ACK丢了

首先ACK丢了：不用做任何处理，也是正确的，2001确认序号，表示2001之前的数据都收到了！！也包含1——1000。

虽然A没有收到1001这个ACK，但是2001这个ACK涵盖了1001的含义，（就相当于，有对象，结婚，有娃娃，小哥哥加你微信，你说我都有娃娃了，不就相当于你有结婚的伴侣了）

其次数据丢了：

此时必须要重传，啥时候重传，具体怎么重传。

在1001-2000丢失之后，2001-3000这个数据到达了B，B返回的ACK确认序号仍是1001，B仍然再向A索要1001这个数据～，虽然A后续给B的数据都会顺利的传递过去，但是如果只要是1001这个数没有，B始终会向A索要这个1001的数据，返回ACK确认序号，都是1001。

(返回ACK确认序号，都是1001）。

3次的重复应答（已经接收1-1001字节的数据），收到了3个同样的确认应答时，则选择重发。

接收方，有个缓冲区在接收数据

如果接收缓冲区，这一块是少了的，返回的ACK，就会始终索要1001这个数据报～一旦1001这个数据报被补充上了，此时1001-2000后面的数据都不必重新传输了，（都在缓冲区等待呢），接下来，就看后面数据加哪里缺失，直接索要缓冲区最后一条数据的下一个即可～

此时，相当于用最小的成本，来完成这个重传数据的操作（只是把丢了的数据重新传输，其他的数据都没有重复操作）快速重传->超时重传+滑动窗口下，产生的变形操作（本质仍然是超时重传）

滑动窗口，也不是说使用TCP就一定涉及，如果你通信的双方大规模传输数据，肯定是滑动窗口（此时按照快速重传来工作），如果是传输通信数据规模小，此时就没有滑动窗口。仍然按照之前的超时重传来工作，滑动窗口的思想方法，非常实用。

二、TCP特性流量控制（作为滑动窗口的补充）

滑动窗口，窗口越大，传输的效率就越高，但是窗口无限大，可能会使接收方处理不过来了，或者使传输中间链路处理不过来，这样就会出现丢包···此时就要重新传输了，窗口大并没有提高效率，反而还会影响效率。

流量控制，给滑动窗口，踩刹车，避免窗口过大，导致处理不过来。

如何衡量接收方处理速度

此处就使用接收缓冲区剩余空间大小作为衡量指标->如果剩余空间越大，应用程序消费数据的速度越快

TCP报头中，这个字段只对ACK报文才有意义，这个数字表示当前缓冲区剩余空间大小，这个数字返回给发送方，就可以作为发送方下一轮发送的参考依据，这里的16位，是否意味着窗口大小就是64KB呢？

实际上下面有一个选项，这个是窗口大小的扩展因子，他可以实现位运算，也就是《这种，换句话说，此时能表示窗口的大小，实际是可以表示非常大的窗口。

虽然A不再发数据了，但是也不知道B这边啥时候可以腾出空间，就会周期发送窗口探测包（⚠️不涵盖任何数据），只是触发ACK，查看当前接收的情况。

一旦发现不是0了，就可以继续发送了，接收方就可以根据窗口大小，来反向限制发送方传输速度。