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

水深无声 2023-10-04 21:22 28阅读 0赞

#### 文章目录 ####

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

**TCP 工作机制**：

[确认应答机制][Link 1]

[超时重传机制][Link 2]

[连接管理机制][Link 3]

## 滑动窗口 ##

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

就比如说，做题目的时候如果写的比较快，虽然效率比较高，但是正确率会相对低一些。  
如果做题的比较慢，每一个过程都仔仔细细的计算，那正确率就会比较高，但是效率就会降低。  
这是一个道理的。  
  
**可靠性 和 效率 是冲突的**，因此，UDP 虽然没有可靠性，但是传输的效率要比 TCP 高。  
  
即使 TCP 的效率再怎么提高，也没有办法和 UDP 完全不考虑可靠性相比。所以说如果是只考虑效率不考虑可靠性的场景，  
UDP 会比 TCP 更加的适合。

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

滑动窗口通过批量发送，批量等待来把多分等待时间合并成一份来降低等待 ACK 消耗的时间。  
  
进行 IO 操作的时候，其实时间成本主要是有两个部分：

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

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

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

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

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

滑动窗口就相当于是一次发送一个窗口大小的数据量，然后等待对方的回复。  
  
只不过不是要等待所有的 ACK 到达后才能继续发送数据，而是到达一个 ACK 就可以继续发送下一条数据。  
这就会致使此处等待的 ACK 始终是 四条。  
  
这里的滑动窗口类似于帮室友带午饭，甲同学想吃炒面、乙同学想吃麻辣烫、丙同学想吃炒菜。  
我去买的时候，为了防止带回来的午饭晾了，就要先点一份炒面，在等待炒面出锅之前就去点麻辣烫和炒菜。  
每次点完一个就去点下一个，避免点一次点等待一次。窗口的大小始终不变，但是点的午饭会改变。（不可能每天都吃同样的）

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

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

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

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

1、**ACK 丢了**

![在这里插入图片描述][4d682fc388e8431b969660eb9d92fb75.png_pic_center]  
  
如果是返回的 ACK 丢了，则不需要做任何的处理。

这里的 1001 ACK 虽然丢包了，但是 下一个 2001 ACK 顺利的到达了，此时 2001 之前的数据都已经确认到达了。  
2001 这个 ACK 其实就包含了上一个 1001 这个 ACK 的信息。  
  
比如说，每个人几乎都是先从小学、初中、高中再到大学这样的求学顺序。  
如果张三上了大学就意味着他已经上过小学、初中和高中了，也就是说后面的会包含前面的。  
  
如上图所示，其实所有的 ACK 并不会全部都在发送，可能会故意商法一部分，这样既不会影响可靠性，也可以节省系统资源。  
ACK 也不会全部丢包，如果丢包的概率非常大，那就说明此时的网络出故障了。

2、**发送的数据丢了**  
  
![60741a39e579478282c2c882f373c34b.png_pic_center][]  
  
据上图可知 2001 ~ 7000 的数据都已经被 B 收到了，接下来 B 索要的数据就是 7001。

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

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

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

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

[Link 1]: https://blog.csdn.net/m0_63033419/article/details/128970343?spm=1001.2014.3001.5501
[Link 2]: https://blog.csdn.net/m0_63033419/article/details/128981959?spm=1001.2014.3001.5501
[Link 3]: https://blog.csdn.net/m0_63033419/article/details/129016700?spm=1001.2014.3001.5501
[cd8bd7d812594c4c9b5d8a235d22520c.png_pic_center]: https://img-blog.csdnimg.cn/cd8bd7d812594c4c9b5d8a235d22520c.png#pic_center
[099604423deb4ca9b3ed7b2620c6c16a.png_pic_center]: https://img-blog.csdnimg.cn/099604423deb4ca9b3ed7b2620c6c16a.png#pic_center
[6b6b86defa4f4f52a719be183547590d.png_pic_center]: https://img-blog.csdnimg.cn/6b6b86defa4f4f52a719be183547590d.png#pic_center
[4d682fc388e8431b969660eb9d92fb75.png_pic_center]: https://img-blog.csdnimg.cn/4d682fc388e8431b969660eb9d92fb75.png#pic_center
[60741a39e579478282c2c882f373c34b.png_pic_center]: https://img-blog.csdnimg.cn/60741a39e579478282c2c882f373c34b.png#pic_center