【探索Linux】P.40（传输层 —— TCP滑动窗口 | 快重传 | 流量控制 ）

阅读导航

引言

在网络通信的世界里，TCP（传输控制协议）以其可靠性和顺序性而著称，成为互联网上数据传输的基石。上一篇文章中，我们深入探讨了TCP协议的两个关键机制：三次"握手"和四次"挥手"，它们确保了数据传输的建立和终止过程的稳定性和可靠性。现在，让我们进一步探索TCP协议的另外三个高级特性：滑动窗口、快重传和流量控制。

在本文中，我们将详细解析这些机制是如何协同工作，以确保TCP协议在各种网络环境下都能提供高效、可靠的数据传输服务。通过深入理解这些特性，我们可以更好地把握网络通信的复杂性，并利用它们来优化我们的应用程序和网络服务。让我们开始这段探索之旅，一窥TCP协议的精妙之处。

一、TCP滑动窗口

1. 为什么要用滑动窗口

（1）逐个确认

正如我们前面所说每个发送的数据段都进行单独确认（称为“逐个确认”或“延迟确认”）。这种方法确保了数据的可靠性，但也存在一些性能上的缺陷，尤其是在数据往返时间较长的情况下。

🔴逐个确认的缺点

1. 增加延迟：因为每个数据段都需要等待一个单独的确认，这会增加数据传输的总延迟。
2. 降低吞吐量：如果网络条件不佳，或者接收方处理速度较慢，发送方可能需要等待较长时间才能收到确认，这会限制数据的发送速率。
3. 增加网络负载：每个数据段都需要一个确认包，这会增加网络中的数据包数量，特别是在高带宽环境下，可能会造成不必要的网络负载。

（2）优化逐个确认（滑动窗口）

既然这样一发一收的方式性能较低, 那么我们发送多个数据段而不是单个数据段，可以有效地减少等待确认的时间，从而提高整体的传输性能。这种方法允许数据传输在等待确认的过程中继续进行，实现时间上的重叠，优化了网络资源的利用。

上图的窗口大小就是4000，窗口大小设置为4000这意味着发送方可以连续发送4000字节的数据，而不需要等待接收方对这些数据的确认应答。

2. TCP滑动窗口的工作原理

1. 初始发送：发送方一开始可以发送四个数据段，而无需等待任何确认应答（ACK）。
2. 窗口滑动：一旦接收方发送了第一个ACK，表明已成功接收到数据，发送方的滑动窗口就会向后移动，允许发送方继续发送下一个数据段。
3. 连续发送：这个过程会一直持续，每当收到一个ACK，窗口就会滑动，发送方就可以继续发送更多的数据段。
4. 发送缓冲区：操作系统内核使用发送缓冲区来跟踪哪些数据已经被发送但还没有收到确认应答。
5. 数据删除：只有当数据被确认应答后，它们才会从发送缓冲区中删除。

二、快重传的引入

在讨论了TCP滑动窗口的工作原理之后，接下来我们来探讨数据丢包的问题。
✅情况一：当数据包成功到达接收方，但对应的确认应答（ACK）却未能到达发送方。

在TCP通信中，即使某些ACK丢失，也不会导致严重问题，因为TCP的确认机制允许使用后续的ACK来确认丢失ACK所对应的数据段。这是因为TCP在发送ACK时，实际上是确认了所有之前序列号的数据都已经成功接收。

🔴情况二：数据包就直接丢了

在TCP通信中，如果数据段丢失，发送方会通过连续收到相同序列号的ACK得知这一点。例如，如果发送方收到三次序列号为1001的ACK，它会立即重传丢失的数据段（1001到2000）。

接收方在收到并确认这些重传的数据后，会更新ACK，发送一个更大的序列号（如7001），表示之前丢失的数据段已经补齐，并且更多的数据已经准备好接收。

这个过程称为’快重传’，它优化了数据传输，减少了等待时间，提高了网络通信的效率。

三、快速重传详细介绍

快速重传（Fast Retransmit）是TCP协议中的一种重要机制，旨在提高数据传输的效率，尤其是在发生数据包丢失的情况下。以下是对快速重传机制的详细介绍：

1. 机制原理

快速重传基于这样一个事实：如果接收方收到一个失序的数据包，这通常意味着前一个数据包已经丢失。因此，接收方会立即发送一个重复的ACK（对最后一个成功接收的数据包的确认），而不是等待接收到期望的数据包后再发送ACK。

2. 触发条件

当发送方连续收到三个相同的ACK时，这表明接收方已经收到了一个数据包三次，但期望的数据包尚未到达。这时，发送方会认为丢失的数据包是紧接在最后一个成功接收的数据包之后的那个，从而触发快速重传机制。

3. 操作步骤

• 发送方在发送数据后，等待接收方的ACK。
• 如果发送方收到三个相同的ACK，表明有数据包丢失。
• 发送方立即重传丢失的数据包，而不必等待重传定时器（RTO）超时。

4. 与超时重传的区别

• 超时重传依赖于重传定时器，当定时器超时后，发送方才会重传数据。
• 快速重传不依赖于定时器，而是根据连续重复的ACK来确定何时重传。

5. 有了快重传可以不要超时重传吗？

🚨🚨答：不可以，尽管快速重传机制提高了TCP在处理数据包丢失时的效率，但它并不能完全替代超时重传。例如，在最后三个数据包同时丢失的情况下，由于无法触发连续三个重复ACK的条件，快速重传机制将无法被激活。因此，超时重传作为一种补充机制，仍然在TCP中发挥着重要作用。

四、流量控制

1. 概念

TCP协议通过流量控制机制来适应接收端的处理能力，避免因发送端发送数据过快而导致接收端缓冲区溢出和数据包丢失。当接收端的缓冲区接近满载时，如果发送端继续快速发送数据，可能会引发丢包和连锁的重传问题。流量控制允许接收端根据自己的处理速度动态调整发送端的发送速率，从而维持网络通信的稳定性和效率。

⭕下面这个是根据窗口大小控制流量过程的一个示例：

在提供的示意图中，我们可以看到，当接收端接收到编号从3001开始的数据段后，它的缓冲区被填满，因此不得不暂停接收新的数据。为了恢复数据传输，接收端需要等待发送端发出的窗口更新通知。但是，如果这个通知在传输过程中丢失，可能会导致通信中断。为了避免这种情况，发送端会定期发送窗口探测数据段，这个数据段只包含一个字节，用于获取接收端的最新窗口大小信息。

2. 流量控制的特点

1. 动态调整：- 接收方根据自身的缓冲区使用情况动态调整窗口大小。- 如果缓冲区接近满载，接收方会减小窗口大小，通知发送方减慢发送速率。
2. 发送端的响应：- 发送方根据接收方通告的窗口大小来控制数据的发送。- 如果窗口大小减小，发送方必须减少数据的发送量，以避免超过接收方的处理能力。
3. 零窗口通知：- 当接收方的缓冲区已满，它会将窗口大小设置为0，通知发送方停止发送数据。- 发送方接收到零窗口通知后，将暂停数据传输，但会定期发送窗口探测数据段，以检查接收方是否还有空间接收数据。
4. 窗口探测：- 发送方在接收到零窗口通知后，会定期发送小的数据段（通常只有1字节），以探测接收方的窗口大小是否已经更新。- 接收方响应这些探测，通告当前的窗口大小。
5. 流量控制的实现：- 流量控制的实现依赖于TCP的滑动窗口机制。- 发送方维护一个滑动窗口，其右边界由接收方通告的窗口大小决定。

3. 注意事项

• TCP协议通过在TCP头部的“窗口大小”字段中设置接收端的缓冲区容量来实现流量控制。
• 窗口大小的值越大，表示接收端能够处理更多的数据，从而可能提高网络的吞吐量。
• 当接收端的缓冲区接近满载时，它会减小窗口大小的值，通过ACK通知发送端减慢发送速率。
• 一旦接收端的缓冲区满了，它会将窗口大小设置为0，指示发送端暂停发送数据。此时，发送端虽然停止了数据传输，但会定期发送窗口探测数据段，以获取接收端关于窗口大小的最新信息，确保一旦缓冲区有空间，数据传输可以立即恢复。

流量控制是TCP协议中确保数据可靠传输的重要组成部分。通过动态调整发送速率以适应接收方的处理能力，流量控制机制有助于防止数据丢失和网络拥塞，从而提高网络通信的稳定性和效率。

温馨提示

感谢您对博主文章的关注与支持！如果您喜欢这篇文章，可以点赞、评论和分享给您的同学，这将对我提供巨大的鼓励和支持。另外，我计划在未来的更新中持续探讨与本文相关的内容。我会为您带来更多关于Linux以及C++编程技术问题的深入解析、应用案例和趣味玩法等。如果感兴趣的话可以关注博主的更新，不要错过任何精彩内容！

再次感谢您的支持和关注。我们期待与您建立更紧密的互动，共同探索Linux、C++、算法和编程的奥秘。祝您生活愉快，排便顺畅！