networking - tcp连接在什么情况下需要等待ACK？

Question

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

这里，在数据包 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白皮书。

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