Tcp 在很短的时间内重新传输超时？

Question

我有两台 Windows 2012 R2 机器（122 和 115），它们托管在同一个 VMWare 主机上。这两台机器之间在应用层有心跳，有时会发生 TCP 重新传输。根据 wireshark 日志，重新传输似乎发生在 12-45 毫秒内，并且重新传输可能发生在 122 或 115 上。例如，最新的日志之一（此日志是在 122 机器上捕获的）如下所示：

1. 在 10:30:42.654764 115 发送到 122：PSH+ACK Seq=28457 Ack=26914 Win=524032 Len=59
2. 在 10:30:42.668642 122 发送到 115：ACK Seq=26914 Ack=28516 Win=524800 Len=0
3. 在 10:30:42.668764 115 发送到 122：[Tcp 重传] PSH+ACK Seq=28457 Ack=26914 Win=524032 Len=59
4. 在 10:30:42.668787 122 发送到 115：ACK Seq=26914 Ack=28516 Win=524800 Len=0 SLE=28457 SRE=28516

因此，看起来 115 认为 122 在 34 毫秒后超时（即使 122 实际上响应的时间略早于此），然后尝试重新传输。我试图在注册表中找到此重新传输超时，但没有成功。（我正在寻找类似 InitialRtt 的东西）我的问题：

1. 34毫秒是标准做法吗？
2. VMWare 与此有关系吗？
3. 为什么 ACK 中的 122 很慢？（两端的软件都是我们编写的，但我们认为我们从未尝试调整过这个值，我可能是错的，因为我个人没有编写代码）。

Answer 1

对于已建立的 TCP 连接，将根据客户端和服务器之间的连接的 RTT 动态计算重传超时。本质上，TCP 将尝试计算出它应该合理等待多长时间才能收到已发送数据包的 ACK。如果该计时器到期，它将触发重传。

因此，根据您的示例，我们可以假设 122 从 115 接收到一个数据包。122 为该数据包发送一个 ACK​​，但它实际上从未到达 115。115 认为 122 从未收到过它的原始数据包，因此在重传计时器到期后重新传输它。122 接收到此重传并发送另一个 ACK​​。

希望有所帮助。