tcp连接在哪些情况下需要等待ACK？
In which situations a tcp connection needs to wait for ACK?
据我所知，等待 ACK 的唯一原因与传输 window 耗尽有关。或者慢启动。但是，这个通过预先存在的 TCP 套接字转储的 Wireshark 片段对我来说没有意义：
这里，在数据包 38 和 40 之间，服务器 (45.55.162.253) 在继续发送之前等待完整的 RTT。我通过 Netem 更改了 RTT，以确保延迟始终等于 RTT，如您所见，没有应用程序数据从客户端流向服务器可能需要的服务器 "to continue working"。但是有一个来自客户端的非常明显的 ACK 数据包（数据包 39）没有任何有效负载。公布的 window 比 [SEQ/ACK 分析]/[飞行中的字节数] 大很多，即 1230。
我的问题是：TCP 中是否有什么东西触发服务器在数据包 38 和 40 之间等待 ACK？
TCP 根据两种不同的机制限制其传输速率：
Flow Control，这是为了确保发件人不会用数据淹没另一方。这就是接收 window 的用武之地。由于客户端在您的屏幕截图中宣传的接收 windows 很大，因此这不是暂停传输的原因。
Congestion Control, which tries to make sure that the network isn't overwhelmed. Slow Start, which you've mentioned, is part of this mechanism in some implementations of TCP，特别是 TCP Tahoe 和 TCP Reno，它们是网络课程中最常教授的变体，尽管在实践中很少使用。
由于我们知道流量控制不是暂停连接的原因，我们可以假设罪魁祸首是拥塞控制算法。然而，要找出确切原因，您需要深入研究 OS 使用的 TCP 的实现细节。对于windows，好像是个叫Compound TCP. With recent Linux kernels, it's something called TCP CUBIC, described in this白皮书的东西。
然而，需要注意的重要一点是，这两种机制都在连接的整个生命周期内运行，而不仅仅是它的开始。似乎你的发送者在发送了迄今为止最大的数据包后暂停了（至少在屏幕截图中显示的数据包中），所以这个数据包可能消耗了它剩余的空闲拥塞控制window，虽然流量控制window还是比较大，绑定前者。
据我所知，等待 ACK 的唯一原因与传输 window 耗尽有关。或者慢启动。但是，这个通过预先存在的 TCP 套接字转储的 Wireshark 片段对我来说没有意义：
这里，在数据包 38 和 40 之间，服务器 (45.55.162.253) 在继续发送之前等待完整的 RTT。我通过 Netem 更改了 RTT，以确保延迟始终等于 RTT，如您所见，没有应用程序数据从客户端流向服务器可能需要的服务器 "to continue working"。但是有一个来自客户端的非常明显的 ACK 数据包（数据包 39）没有任何有效负载。公布的 window 比 [SEQ/ACK 分析]/[飞行中的字节数] 大很多，即 1230。
我的问题是：TCP 中是否有什么东西触发服务器在数据包 38 和 40 之间等待 ACK？
TCP 根据两种不同的机制限制其传输速率：
Flow Control，这是为了确保发件人不会用数据淹没另一方。这就是接收 window 的用武之地。由于客户端在您的屏幕截图中宣传的接收 windows 很大，因此这不是暂停传输的原因。
Congestion Control, which tries to make sure that the network isn't overwhelmed. Slow Start, which you've mentioned, is part of this mechanism in some implementations of TCP，特别是 TCP Tahoe 和 TCP Reno，它们是网络课程中最常教授的变体，尽管在实践中很少使用。
由于我们知道流量控制不是暂停连接的原因，我们可以假设罪魁祸首是拥塞控制算法。然而，要找出确切原因，您需要深入研究 OS 使用的 TCP 的实现细节。对于windows，好像是个叫Compound TCP. With recent Linux kernels, it's something called TCP CUBIC, described in this白皮书的东西。
然而，需要注意的重要一点是，这两种机制都在连接的整个生命周期内运行，而不仅仅是它的开始。似乎你的发送者在发送了迄今为止最大的数据包后暂停了（至少在屏幕截图中显示的数据包中），所以这个数据包可能消耗了它剩余的空闲拥塞控制window，虽然流量控制window还是比较大，绑定前者。