在哪种情况下，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，它们是网络课程中最常教授的变种，尽管在实践中很少使用。

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

然而，重要的是要注意两种机制在连接的整个生命周期中运行，而不仅仅是它的开始。到目前为止，您的发送方似乎在发送了最大的数据包之后暂停了（至少在屏幕截图中显示的数据包中），因此该数据包可能会消耗其剩余的空闲拥塞控制窗口，尽管流控制窗口仍然很大，但它是前者的约束。