Windows 7 或 Vista TCP 行为更改
某种解决方案
显示此问题的客户端计算机安装了趋势科技安全软件。该安全套件在系统中的每个网络适配器之上放置了一个服务或驱动程序。一旦这个遗留应用程序再次开始工作,我就懒得进一步调试。
更新1
我在Win7上禁用了TCP窗口缩放自动调整。
在 Windows 7 上,如果我拔掉直接连接到服务器的以太网电缆,大约 5 秒后就会断开连接,但客户端进程会崩溃。服务器上的 netstat 报告到客户端的两个 TCP 连接不再有效,因为客户端进程没有正常关闭连接。
在物理断开连接后将服务器置于这种奇怪的状态后,如果我重新启动客户端进程,它会在连接到服务器时挂起(正如原文中所述)
如果我在 XP 端执行物理断开连接,则断开连接会发生得更快比Win7。 XP 上的某种保活值或行为有所不同。虽然 ssh(通过 Putty)在 XP 上比 Win7 上的 ssh 连接断开得更快。
原始
我有一个旧版 TCP 客户端/服务器应用程序,仅当客户端是 Windows 7 计算机时,该应用程序似乎才会扰乱服务器。
服务器是运行 2.6.11 的 OpenEmbedded Linux。
Windows 7 客户端连接一段时间,最终达到客户端在一两秒后断开连接的状态。
一旦服务器处于这种状态,如果我立即连接Windows XP客户端,XP客户端也无法连接。
我似乎无法通过单独连接 XP 客户端来使服务器进入错误状态。
我想知道从 Vista 或 Windows 7 开始对 TCP/IP 堆栈进行了哪些更改,以便我可以更好地调试旧代码。
我还想知道可以在 Linux 服务器上运行哪些命令,这些命令可以更好地帮助我理解连接失败的原因。
Resolution, of sorts
The client computer that was showing this problem had Trend Micro Security installed. This security suite placed a service or driver on top of each network adapter in the system. I did not bother to debug further once this legacy app started working again.
Update 1
I disabled TCP window scale auto-tuning on Win7.
On Windows 7 if I unplug the ethernet cable directly connected to the server, the disconnection happens after about 5 seconds but the client process crashes. netstat on the server reports two TCP connections to the client that are no longer valid, because the client process did not gracefully shutdown and close the connections.
After putting the server in this strange state after the physical disconnect, If I restart the client process it hangs while connecting to the server (just as described in the original)
If I perform a physical disconnection on the XP side, the disconnect happens more quickly than on Win7. Some sort of keep alive value or behavior is different on XP. While ssh'd (via Putty) the ssh connection dies more quickly on XP than Win7 as well.
Original
I have a legacy TCP client/server app that appears to foul up the server only when the client is a Windows 7 machine.
The server is OpenEmbedded Linux running 2.6.11.
A Windows 7 client connects for a bit, and eventually gets to a state where the client disconnects after a second or two.
Once the server is in this state, If I immediately connect a Windows XP client, the XP client cannot connect either.
I cannot appear to get the server into the buggy state by connecting with an XP client alone.
I'd like to know what changes were made to the TCP/IP stack starting with Vista or Windows 7 so I can better debug the legacy code.
I'd also like to know what commands I can run on the Linux server that might better help me understand why the connections are failing.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
也许您能做的最好的事情就是在 Linux 下启动
tcpdump
或wireshark
并分析 Windows XP 和 Windows 7 发送的 TCP SYN。Wireshark 可以让您突破逐位发送 TCP 选项...例如,这是您从建立 TCP 连接的 debian lenny 盒子中看到的内容:我怀疑您会看到 RFC 1323 窗口缩放中的差异,但我不知道t有一台 XP 机器来验证这一点。
我详细回复了如何使用
tcptrace
分析 TCP 连接 在这个答案的Linux下...如何我测量服务器代码的性能和 TCP RTT?
Perhaps the best thing you can do is to fire up
tcpdump
orwireshark
under linux and analyze the TCP SYN sent by both Windows XP and Windows 7. Wireshark allows you to break out bit-by-bit what TCP options are sent... for example, this is what you see from a debian lenny box making a TCP connection:My suspicion is that you'll see differences in RFC 1323 Window Scaling, but I don't have an XP machine handy to validate this.
I gave a detailed response of how to analyze TCP connections using
tcptrace
under linux in this answer...How can I measure the performance and TCP RTT of my server code?
我还怀疑窗口缩放问题。我现在找不到链接,但是当 Vista 首次推出时,有人抱怨说某些路由器出现了问题(贝尔金斯,如果我记得的话)。他们将其追溯到 Vista(以及 Windows 7)默认更改的窗口大小之一的问题。路由器会挂起,需要每隔几分钟重置一次。
您可以发出一些命令来关闭窗口缩放,看看您的问题是否消失。
从这里:
编辑:
尝试在 Windows 7 上禁用 IPv6。链接了解如何执行此操作。对于 IPv4,它的行为应该与 Windows XP 相同。在两个系统上加载wireshark并比较差异
I also suspect a Window Scaling issue. I cannot find a link just at the moment, but there were complaints when Vista first came out reporting that that something was screwing with some routers (belkins If I recall). They traced it down to a problem with one of the window sizes that Vista (and thereby Windows 7) changes by default. The routers would get hung up and need to be reset every few minutes.
You can issue some commands to turn off window scaling, see if your problem goes away.
From Here:
Edit:
Try disabling IPv6 on windows 7. Link on how to do that. With IPv4, it should act the same as windows XP. Load up wireshark on the two systems and compare the differences