这是我从 FTP 服务器下载 10Mb 文件时捕获的 TCP 会话。服务器的 ICW 为 10x MSS，因此这意味着服务器最初可以发送 10 个段而不会收到来自客户端的 ACK。
话虽如此，每两个段都被实时确认，服务器已将所有10个段发送给已经确认所有段的客户端。现在，服务器从 15:40:31:864 到 15:40:31:901 等待了超过 50 毫秒，直到它开始发送新段。
我想知道，为什么服务器暂停发送更多的段，尽管所有的段都已经被确认？我知道它在等待 RTO 值，但是为什么服务器在收到所有 ACK 后还要这样做呢？
更新1：
谢谢您的回答。但是，我需要在这里详细说明。
以上是流的 RTT，您可以看到第一部分（直到 SEQ# 2600000）的平均 RTT 约为 30 毫秒。因此，最初在服务器端，cwin 已经填充并填充了 10 个准备发送的段。
想必：
前两个数据包已在 -> 15:40:31.842 从服务器发送，并已在客户端（我正在捕获）在 -> 15:40:31.862 同时收到，客户端发送了一个在 -> 15:40:31.862 延迟到服务器的 ACK 并且大概在 -> 15:40:31.882 被服务器收到
这时候cwin会滑动，去掉旧的两个segment，腾出空间给客户端发送两个新的segment，除非cwin或者rwin的cwin已经准备好发送客户端已用尽，这不是我们的情况，或者服务器正在等待 ACK，这也是无效的。
因此，服务器有 10 个段，发送了 8 个，前 2 个得到 ACK，将 cwin 向右滑动，得到两个新段。现在 cwin 有 10 个段要再次进行，不可阻挡。我的问题是，为什么服务器在这个阶段暂停传输？
更新2：
您可以查看流的第一部分的以下 tcptrace：
斜率是放松的（不是陡峭的），你可以看到每大约 50 毫秒有一次无缘无故的停顿。
但是，在连接的中间部分：
坡度更陡，中间没有间隙，也没有停顿。考虑到两个部分的 RTT 相同，您可以通过 RTT 图确认这一点