Networking 在哪些情况下，tcp连接需要等待ACK？

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

这里，在包38和40之间，服务器（45.55.162.253）在继续发送之前等待完整的RTT。我通过Netem更改了RTT，以确保延迟始终等于RTT，并且正如您所看到的，没有应用程序数据从客户端流向服务器，服务器可能需要“继续工作”。但是，有一个非常明显的ACK数据包从客户端（数据包39）发送，没有任何有效负载。播发的窗口比[SEQ/ACK analysis]/[Bytes in flight]大得多，后者为1230

---

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

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

，以确保发送方不会用数据压倒另一方。这就是接收窗口的作用。由于客户端在屏幕截图中公布的接收窗口很大，因此在您的情况下，这并不是暂停传输的原因

，它试图确保网络不被淹没。您提到的慢启动是这种机制的一部分，特别是TCP Tahoe和TCP Reno，它们是网络课程中最常用的变体，但在实践中很少使用

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

---

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

。这也是我所怀疑的，我调整了一些超时时间，使套接字在不活动后缓慢启动，而“热”套接字的问题就消失了。