FIN、ACK 之后的 TCP 连接 RST

Question

我有一个情况想和这里的专家澄清一下。我不是网络专家，所以这也许很正常，但我宁愿问。

我们正在尝试诊断两台服务器之间的问题，它们都是虚拟服务器，一个是 Windows，另一个是 Linux。

我觉得奇怪的是，查看两台服务器之间的流量（如使用 Wireshark 在 Windows 虚拟服务器上看到的那样），是以下特定的 TCP 数据包序列：

1. Linux 服务器发送 FIN、ACK
2. Windows 服务器以 ACK 响应
3. Windows 服务器发送 FIN、ACK
4. Linux 服务器以 RST 进行响应

在 3 到 4 之间，Windows 服务器发送 ARP 广播，询问 Linux 服务器（谁有“linux ip”？告诉“windows ip”）。

我还可以提到：

1. Linux 虚拟服务器在 Linux 主机上运行，​​该主机具有提供给 Linux 虚拟服务器的绑定接口
2. Windows 虚拟服务器在 VMWare 平台上运行
3. Windows 和 Linux 服务器均位于同一 VLAN

所以问题是：这种行为正常吗？或者我们应该调查什么？

这是日志文件的图像；.46 是 Linux 服务器，.167 是 Windows 服务器。 Wireshark 捕获

Answer 1

您应该检查您的 Linux TCP 设置，特别是：net.ipv4.tcp_fin_timeout。默认值为 60 秒。您的系统可能有不同的值。在步骤 2) 之后，Linux 会将此连接标记为“FIN-WAIT-2”，并在 60 秒后自动关闭它（基于 tcp_fin_timeout）。如果您的步骤 3) 晚于 60 秒，Linux 服务器将无法返回 ACK 以正常关闭连接，因为它已被关闭，因此将返回 RST。

Answer 2

最后，我们没有发现这种行为存在问题，我们查看了用例的完整捕获，发现这种情况只出现在测试结束时，而不是测试期间。所以我想这只是奇怪，而不是真正的问题。

我们最终将 Wireshart 捕获的内容导出到 PDML 文件，然后使用我们构建的程序对其进行解析，以使用 TCP 流分析和关联信息。这样，我们就能知道服务器响应 HTTP 请求需要多长时间，这对深入了解问题的根源很有帮助。