☰

有时 windows / .net 应用程序会忽略 tcp fin 标志

tag-icon • tag-icon tcp tcpip windows
有时 windows / .net 应用程序会忽略 tcp fin 标志

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

响应后[分成几个，由 Windows 确认，TCP 数据包] Linux 服务器 - 10.14.11.59 - 发送一个包含 FIN 和 ACK 标志设置的 TCP 数据包。 在此处输入图片描述

这已由 Windows 计算机 - 10.14.10.195 - 确认，并且数据包仅设置了 ACK 标志。 在此处输入图片描述

Linux 多次重新发送带有 FIN 和 ACK 标志的数据包，而 Windows 机器由于某种原因仍保持连接打开；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

数据包捕获：这里。

任何想法都将受到赞赏！

答案1

我们发现客户端计算机上运行的 ESET 端点安全软件是罪魁祸首。

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

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

答案2

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

我认为这是正确的客户行为，因为原始 RFC 中的 ASCII 图表说明了这一点

关闭的客户端在收到FIN,ACK来自服务器的 后，套接字将从 转换为FIN-WAIT1，TIME-WAIT并在网络中保持此状态 2 倍最大段生命周期，此时它会发送一个FIN回复，以关闭连接。

WindowsTIME-WAIT使用注册表值名称覆盖持续时间TcpTimedWaitDelay，最初实现的默认值是240秒（MSL默认为120秒）。在Windows XP/Server 2003及以上版本中，默认值降低为120秒。

我相信你可以在提供响应后通过关闭服务器上的底层套接字来解决这个问题，但一定要阅读这个答案也是如此，大致相同的问题，但从服务器的角度来看

相关内容