计网 - TCP 的稳定性：滑动窗口和流速控制是怎么回事？

拼搏现实的明天。 2022-10-12 05:47 139阅读 0赞

### 文章目录 ###

*  Pre
 *  请求/响应模型
 *  排队（Queuing）机制 ？？？
 *  滑动窗口（Sliding Window）
 *   *  重传
     *  快速重传
     *  窗口大小的单位是 --- 字节数
 *  流速控制
 *  总结
 *  QA
 *   *  既然发送方有窗口，那么接收方也需要有窗口吗

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70_pic_center]

--------------------

# Pre #

[Internet - TCP 的封包格式：TCP 为什么要粘包和拆包？][Internet - TCP _TCP] 中提到了 **TCP 利用发送字节数和接收字节数，这个二元组的唯一性保证顺序**。

那接着来看下保证顺序的具体算法以及TCP是如何实现的吧。 ——**TCP 的滑动窗口算法**。

TCP 作为一个传输层协议，最核心的能力是传输。传输需要**保证可靠性**，还需要**控制流速**，这两个核心能力均由**滑动窗口**提供。

而滑动窗口中解决的问题，我们在今后的工作中可以长期使用的，比如设计一个分布式的 RPC 框架、实现一个消息队列或者分布式的文件系统等。

--------------------

# 请求/响应模型 #

**TCP 中每个发送的请求都需要响应。如果一个请求没有收到响应，发送方就会认为这次发送出现了故障，会触发重发**。

大体的模型，和下图很像。但是**如果完全和下图一样，每一个请求收到响应之后，再发送下一个请求，吞吐量会很低。因为这样的设计，会产生网络的空闲时间，说白了，就是浪费带宽**。带宽没有用满，意味着可以同时发送更多的请求，接收更多的响应。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70]  
**一种改进的方式，就是让发送方有请求就发送出去，而不是等待响应。通过这样的处理方式，发送的数据连在了一起，响应的数据也连在了一起，吞吐量就提升了**。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 1]

但是如果可以同时发送的数据真的非常多呢？比如成百上千个 **TCP 段**都需要发送，这个时候带宽可能会不足。像下图这样，很多个数据封包都需要发送，该如何处理呢？

![在这里插入图片描述][20210704103447763.png]

--------------------

# 排队（Queuing）机制 ？？？ #

在这种情况下，通常我们会考虑排队（Queuing）机制。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 2]  
考虑这样一个模型，如上图所示，在 TCP 层实现一个队列。

新元素从队列的一端（左侧）排队，作为一个未发送的数据封包。开始发送的数据封包，从队列的右侧离开。

思考一下，这个模型有什么问题吗？

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 3]

**这样做就需要多个队列，我们要将未发送的数据从队列中取出，加入发送中的队列。然后再将发送中的数据，收到 ACK 的部分取出，放入已接收的队列。而发送中的封包，何时收到 ACK 是一件不确定的事情，这样使用队列似乎也有一定的问题**。

--------------------

# 滑动窗口（Sliding Window） #

在上面的模型当中，我们之所以觉得算法不好设计，是因为用错了数据结构。有个说法叫作如果程序写复杂了，那就是写错了。这里其实应该用一种叫作滑动窗口的数据结构去实现。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 4]  
如上图所示：

*  深绿色代表已经收到 ACK 的段
 *  浅绿色代表发送了，但是没有收到 ACK 的段
 *  白色代表没有发送的段
 *  紫色代表暂时不能发送的段

下面我们重新设计一下不同类型封包的顺序，**将已发送的数据放到最左边，发送中的数据放到中间，未发送的数据放到右边。假设我们最多同时发送 5 个封包，也就是窗口大小 = 5。窗口中的数据被同时发送出去，然后等待 ACK。如果一个封包 ACK 到达，我们就将它标记为已接收（深绿色）**。

如下图所示，有两个封包的 ACK 到达，因此标记为绿色。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 5]

这个时候滑动窗口可以向右滑动，如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 6]

## 重传 ##

如果发送过程中，部分数据没能收到 ACK 会怎样呢？这就可能发生重传。

如果发生下图这样的情况，段 4 迟迟没有收到 ACK。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 7]

这个时候滑动窗口只能右移一个位置，如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 8]

**在这个过程中，如果后来段 4 重传成功（接收到 ACK），那么窗口就会继续右移。如果段 4 发送失败，还是没能收到 ACK，那么接收方也会抛弃段 5、段 6、段 7。这样从段 4 开始之后的数据都需要重发**。

--------------------

## 快速重传 ##

在 TCP 协议中，如果接收方想丢弃某个段，可以选择不发 ACK。发送端超时后，会重发这个 TCP 段。而有时候，接收方希望催促发送方尽快补发某个 TCP 段，这个时候可以使用**快速重传**能力。

例如段 1、段 2、段 4 到了，但是段 3 没有到。 **接收方可以发送多次段 3 的 ACK。如果发送方收到多个段 3 的 ACK，就会重发段 3。这个机制称为快速重传。这和超时重发不同，是一种催促的机制**。

**为了不让发送方误以为段 3 已经收到了，在快速重传的情况下，接收方即便收到发来的段 4，依然会发段 3 的 ACK（不发段 4 的 ACK），直到发送方把段 3 重传**。

![在这里插入图片描述][20210704113638816.png]

--------------------

## 窗口大小的单位是 — 字节数 ##

思考另一个问题，窗口大小的单位是多少呢？在上面所有的图片中，窗口大小是 TCP 段的数量。**实际操作中，每个 TCP 段的大小不同，限制数量会让接收方的缓冲区不好操作，因此实际操作中窗口大小单位是字节数**。

--------------------

# 流速控制 #

发送、接收窗口的大小可以用来控制 TCP 协议的流速。窗口越大，同时可以发送、接收的数据就越多，支持的吞吐量也就越大。当然，窗口越大，如果数据发生错误，损失也就越大，因为需要重传越多的数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 9]  
举个例子：我们用 **RTT** 表示 Round Trip Time，就是**消息一去一回的时间**。

假设 RTT = 1ms，带宽是 1mb/s。如果窗口大小为 1kb，那么 1ms 可以发送一个 1kb 的数据（含 TCP 头），1s 就可以发送 1mb 的数据，刚好可以将带宽用满。

如果 RTT 再慢一些，比如 RTT = 10ms，那么这样的设计就只能用完 1/10 的带宽。 当然你可以提高窗口大小提高吞吐量，但是实际的模型会比这个复杂，因为还存在重传、快速重传、丢包等因素。

而实际操作中，也不可以真的把带宽用完，所以最终我们会使用折中的方案，在**延迟、丢包率、吞吐量**中进行选择，毕竟鱼和熊掌不可兼得。

--------------------

# 总结 #

为了提高传输速率，TCP 协议选择将多个段同时发送，为了让这些段不至于被接收方拒绝服务，在发送前，双方要协商好发送的速率。但是我们不可能完全确定网速，所以**协商的方式，就变成确定窗口大小**。

有了窗口，发送方利用滑动窗口算法发送消息；接收方构造缓冲区接收消息，并给发送方 ACK。滑动窗口的实现只需要数组和少量的指针即可，是一个非常高效的算法。像这种算法，简单又实用，比如求一个数组中最大的连续 k 项和，就可以使用滑动窗口算法。

--------------------

# QA #

Question: 滑动窗口和流速控制是怎么回事？

> **滑动窗口是 TCP 协议控制可靠性的核心**。

> **发送方将数据拆包，变成多个分组。然后将数据放入一个拥有滑动窗口的数组，依次发出，仍然遵循先入先出（FIFO）的顺序，但是窗口中的分组会一次性发送。窗口中序号最小的分组如果收到 ACK，窗口就会发生滑动；如果最小序号的分组长时间没有收到 ACK，就会触发整个窗口的数据重新发送**。

> 另一方面，在多次传输中，网络的平均延迟往往是相对固定的，这样 TCP 协议可以通过双方协商窗口大小控制流速。补充下，上面我们说的分组和 TCP 段是一个意思。

--------------------

## 既然发送方有窗口，那么接收方也需要有窗口吗 ##

我们一起思考下，接收方收到发送方的每个数据分组（或者称为 TCP Segment），接收方肯定需要缓存。举例来说，如果发送方发送了：1, 2, 3, 4。 那么接收方可能收到的一种情况是：1，4，3。注意，没有收到 2 的原因可能是延迟、丢包等。这个时候，接收方有两种选择。

**选择一：什么都不做**（这样分组 2 的 ACK 就不会发送给发送方，发送方发现没有收到 2 的 ACK，过一段时间就有可能重发 2,3,4,5）。 当然具体设计还需要探讨，比如不重发整个分组，只重发已发送没有收到 ACK 的分组。

这种方法的缺陷是性能太差，重发了整个分组（或部分）。因此我们可以考虑另一种选择。

**选择二：如果重发一个窗口，或部分窗口**，问题就不会太大了。虽然增加了网络开销，但是毕竟有进步（1 进步了，不会再重发）。

性能方面最大的开销是**等待超时的时间**，就是发送方要等到超时时间才重发窗口，这样操作性能太差。因此，TCP 协议有一个**快速重传的机制**——接收方发现接收到了 1，但是没有接收到 2，那么马上发送 3 个分组 2 的 ACK 给到发送方，这样发送方收到多个 ACK，就知道接收方没有收到 2，于是马上重发 2。

无论是上面哪种方案，接收方也维护一个滑动窗口，是一个不错的选择。接收窗口的状态，可以和发送窗口的状态相互对应了。  
![在这里插入图片描述][2021070411500196.gif_pic_center]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20221005/0d2abd838a3f4c5fa78696a0f001f552.png
[Internet - TCP _TCP]: https://blog.csdn.net/yangshangwei/article/details/118446613?spm=1001.2014.3001.5501
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70]: /images/20221005/543f9b843f724eae85760274cfc92cba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 1]: /images/20221005/1194816fb9a24f91b58fb5a2cacc2905.png
[20210704103447763.png]: /images/20221005/ec337b7be51e464bb0ecaa4378f588a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 2]: /images/20221005/0eb98bdf37af4cb5bfcd157f5838b39d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 3]: /images/20221005/ee223906344044c4ad201707f213c59e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 4]: /images/20221005/effbed310c11429786f59175396cc2fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 5]: /images/20221005/0a761a6d2549490abaf9a9ddd95c6c8f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 6]: /images/20221005/87732fe22b09497ca67c272be8823198.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 7]: /images/20221005/c65c163e1fd64aec9533abc5229186dc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 8]: /images/20221005/c295ea8504a645aa8366b7ad2f29f2da.png
[20210704113638816.png]: /images/20221005/9b3c06e36899413d8158a5ac47e11cc1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGFuZ3dlaQ_size_16_color_FFFFFF_t_70 9]: /images/20221005/4f2f52ee77f146e58fda912e90a8a27c.png
[2021070411500196.gif_pic_center]: /images/20221005/2be72ad63cb54f2ba977a927c86491fc.png