javaEE 初阶 — 传输层 TCP 协议 中的滑动窗口

TCP 工作机制：

确认应答机制

超时重传机制

连接管理机制

滑动窗口

确认应答机制、超时重传机制、连接管理机制 都是给 TCP 的可靠性提供支持的。
虽然事变的比较可靠了，但是是有牺牲的，那就是传输的效率变低了。

就比如说，做题目的时候如果写的比较快，虽然效率比较高，但是正确率会相对低一些。
如果做题的比较慢，每一个过程都仔仔细细的计算，那正确率就会比较高，但是效率就会降低。
这是一个道理的。

可靠性 和 效率 是冲突的，因此，UDP 虽然没有可靠性，但是传输的效率要比 TCP 高。

即使 TCP 的效率再怎么提高，也没有办法和 UDP 完全不考虑可靠性相比。所以说如果是只考虑效率不考虑可靠性的场景，
UDP 会比 TCP 更加的适合。

滑动窗口的本质上就是降低了确认应答，等待 ACK 消耗的时间。

滑动窗口通过批量发送，批量等待来把多分等待时间合并成一份来降低等待 ACK 消耗的时间。

进行 IO 操作的时候，其实时间成本主要是有两个部分：

1、等待的时间
1、数据传输的时间（数据拷贝）

大多数情况下， IO 花的时间成本大部分都是在等待。
比如说坐高铁回家过年，真正花在路上上的时间可能只有两个小时，但是 这其中有不少候车的时间。

对于确认应答的情况来说，每发送一次数据都是需要等待 ACK 到了才会再发下一个数据。

比如说在和别人聊天的时候，我只有等对方回复我之后，我才可以继续发送消息和对方聊天。

滑动窗口的本质就是不等待的批量发送一组数据，然后使用一份时间来等待着一组数据的多个 ACK。
把不需要等待就能直接发送的数据的最大量，称为 “窗口大小”。
上述的图中展示的窗口大小就是 4000。

滑动窗口就相当于是一次发送一个窗口大小的数据量，然后等待对方的回复。

只不过不是要等待所有的 ACK 到达后才能继续发送数据，而是到达一个 ACK 就可以继续发送下一条数据。
这就会致使此处等待的 ACK 始终是 四条。

这里的滑动窗口类似于帮室友带午饭，甲同学想吃炒面、乙同学想吃麻辣烫、丙同学想吃炒菜。
我去买的时候，为了防止带回来的午饭晾了，就要先点一份炒面，在等待炒面出锅之前就去点麻辣烫和炒菜。
每次点完一个就去点下一个，避免点一次点等待一次。窗口的大小始终不变，但是点的午饭会改变。（不可能每天都吃同样的）

本来等待 ACK 是 1001~5000，接下来收到了 2001 这个 ACK ，说明 2001 之前的数据（1001 ~ 2000）已经接收到了。
此时就可以直接发送 5001~6000 的数据，此时意味着等待 ACK 的返回范围就是 2001 ~ 6000。（③的情况）

需要注意的是上述的情况前提是窗口大小是图中为4个段情况。

1 滑动窗口下如何处理丢包

这里分为 ACK 丢了 和 发送的数据 丢了两种。

1、ACK 丢了

如果是返回的 ACK 丢了，则不需要做任何的处理。

这里的 1001 ACK 虽然丢包了，但是 下一个 2001 ACK 顺利的到达了，此时 2001 之前的数据都已经确认到达了。
2001 这个 ACK 其实就包含了上一个 1001 这个 ACK 的信息。

比如说，每个人几乎都是先从小学、初中、高中再到大学这样的求学顺序。
如果张三上了大学就意味着他已经上过小学、初中和高中了，也就是说后面的会包含前面的。

如上图所示，其实所有的 ACK 并不会全部都在发送，可能会故意商法一部分，这样既不会影响可靠性，也可以节省系统资源。
ACK 也不会全部丢包，如果丢包的概率非常大，那就说明此时的网络出故障了。

2、发送的数据丢了



据上图可知 2001 ~ 7000 的数据都已经被 B 收到了，接下来 B 索要的数据就是 7001。

还可以根据上图发现，1001 ~ 2000 丢包了，接下来 2001 ~ 3000 到达主机 B 之后，B 给 A 返回的 ACK 确认序号仍然是 1001。
（此时和发来的数据序号是什么关系不大了）
也就是说，现在是在索要 1001 开头的数据。

接下来的几个数据，B 返回的确认序号都是 1001，此时站在 A 的角度就会发现自己已经发了不少的数据了，
但是 B 仍是在索要 1001 ，说明 B 没有收到 1001，此时就要重传了。

上述丢包重传的方式叫做 “快速重传”（只重传丢失的数据），这个操作可以视为超时重传机制在滑动窗口下的变形。

如果当前传输的数据密集，按照滑动窗口的方式来传输，此时按照快速重传来处理丢包。
如果当前传输数据稀疏，不再按照滑动窗口方式，此时还是按照之前的的超时重传来处理丢包。