networking - tcp连接在哪些情况下需要等待ACK？

Question

据我所知，等待 ACK 的唯一原因与传输窗口耗尽有关。或者慢启动。但是，这个通过预先存在的 TCP 套接字进行的 Wireshark 转储片段对我来说没有意义:

这里，在数据包 38 和 40 之间，服务器 (45.55.162.253) 在继续发送之前等待完整的 RTT。我通过 Netem 更改了 RTT，以确保延迟始终等于 RTT，正如您所看到的，没有应用程序数据从客户端流向服务器可能需要服务器“继续工作”。但是有一个来自客户端的非常明显的 ACK 数据包(数据包 39)没有任何有效负载。广告窗口比 [SEQ/ACK 分析]/[传输中的字节数] 大很多，即 1230。

我的问题是:TCP 中是否有什么东西触发服务器等待数据包 38 和 40 之间的 ACK？

Answer 1

TCP 根据两种不同的机制限制其传输速率:

1. Flow Control ，这是为了确保发件人不会用数据淹没另一方。这就是接收窗口的用武之地。由于客户端在您的屏幕截图中公布的接收窗口很大，因此在您的案例中这不是暂停传输的原因。

2. Congestion Control ，它试图确保网络不会被淹没。您提到的慢启动是此机制的一部分 in some implementations of TCP ，特别是 TCP Tahoe 和 TCP Reno，它们是网络类(class)中最常教授的变体，但在实践中很少使用。

因为我们知道流量控制不是暂停连接的原因，我们可以假设罪魁祸首是拥塞控制算法。然而，要找出确切原因，您需要深入了解操作系统使用的 TCP 的实现细节。对于 Windows，它似乎是一个叫做 Compound TCP 的东西。 .在最近的 Linux 内核中，它叫做 TCP CUBIC。 ，描述于 this白皮书。

然而，需要注意的重要一点是，这两种机制都在连接的整个生命周期内运行，而不仅仅是它的开始。您的发送方似乎在发送了迄今为止最大的数据包后暂停了(至少在屏幕截图中显示的数据包中)，因此该数据包可能消耗了其剩余的空闲拥塞控制窗口，尽管流量控制窗口仍然很大，但它绑定(bind)了前者。