主页 / server / 问题 / 561241
Accepted
pQd
Asked: 2013-12-14 11:02:15 +0800 CST

偶尔 Windows / .net 应用程序会忽略 tcp fin 标志

  • 772

我遇到了无法解决的网络问题。在一些运行 Windows 8.1 并与 linux http 服务器通信的计算机上，tcp 连接在 Windows 端悬空，而不是被正确关闭。

在响应 [分成几个，由 windows 确认，tcp 数据包] linux 服务器 - 10.14.11.59 - 发送一个包含 FIN 和 ACK 标志集的 tcp 数据包。 在此处输入图像描述

这是由 Windows 机器确认的 - 10.14.10.195 - 数据包只设置了 ACK 标志。 在此处输入图像描述

linux在windows机器上多次重新发送带有FIN和ACK标志的数据包——由于某种原因仍然保持连接打开；windows机器永远不会发送带有RST标志的数据包。 在此处输入图像描述

如果发生这种情况，Windows 应用程序会等待并最终超时。这在 10-50% 的尝试中随机发生。

两台机器之间的流量未经过滤；基于主机的防火墙已关闭。为了避免潜在的问题，我在 linux 和 windows 上禁用了 tcp 卸载。另外在 Windows 上运行以下程序并重新启动机器：

netsh int tcp set global chimney=disabled
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global rss=disabled

数据包捕获：这里。

任何想法将不胜感激！

tcp

2 个回答

  1. Best Answer

    我们发现在客户端机器上运行的 eset 端点安全是罪魁祸首。

    禁用防火墙功能是不够的；但卸载它完全解决了这个问题。

    我的同事在这里找到了类似问题的描述；显然升级到最新版本的 eset 也解决了这个问题。

    • 3

  2. 我假设您的 tcpdump 中的第一段前面是FIN来自客户端的 a。

    我相信这是正确的客户端行为，如原始 RFC 中的 ASCII 图表所示

    关闭的客户端，在收到FIN,ACK来自服务器的 a 后，套接字从FIN-WAIT1to转换TIME-WAIT并在此状态下保持 2 倍于网络中的 Maximum Segment Lifetime，此时它发送FIN回一个以关闭连接。

    TIME-WAITWindows使用注册表值名称TcpTimedWaitDelay覆盖持续时间，最初使用默认值 240 秒（MSL 默认为 120 秒）实现。在 Windows XP/Server 2003 及更高版本中，默认值降低到 120 秒。

    我相信您可以通过在提供响应后关闭服务器上的底层套接字来解决此问题，但请务必阅读此答案，大致相同的问题，但从服务器的角度来看

    • 2

相关问题