这是我前一段时间遗弃的一个老问题因为我没有解决方案,它只影响了一台服务器(所以我只是将我的服务放在其他地方)。 This用户遇到与我相同症状的问题:
- C#.net synchronous Tcp server
- 通过使用AcceptTcpClient方法阻止TcpListener分配TcpClient对象
- 一旦有了一个TcpClient对象,我将它传递给一个线程,该线程调用客户端的GetStream方法来创建一个NetworkStream
- 这个NetworkStream循环,在每次迭代中执行networkStream.Read(someBuffer,0,4096)
- 现在客户端和服务器位于同一网络上,没有拥塞可言
- 我的服务器有足够的内存来备用
- 如果我将服务器软件加载到另一台计算机上,则问题就会消失
- 踢球者:来自网络Linux盒子的流量可以很好地按时完成
tcpClient.AcceptTcpClient()
方法一次阻塞大约一分钟,导致服务器不久后读取一大块字节,而不是它应该做的事情。它应该像发送它们一样频繁地执行networkStream.Read()小块字节(并且客户端每5秒发送一次,而不是每分钟发送一次)。
以前对其他用户的评论表明,低负荷网络或连接问题可能是罪魁祸首,这一点似乎是合理的。但事实并非如此。
我更进了一步,在客户端和服务器上安装了数据包分析器。结果:
环境:
如果有人有任何建议,我非常想知道它是什么。
答案 0 :(得分:1)
这可能是由于以下原因之一。
在其他情况下,已观察到该网卡模型在TCP卸载方面存在问题。您可以在设备驱动程序配置中禁用此功能。
如果卸载处理分段存在问题,那么您可能会发现它只出现在某些网络路由上,这可能会解释您在Linux客户端和Windows客户端之间观察到的差异。
路径MTU应该被自动发现,但如果干预路由器正在丢弃所有ICMP流量(包括“需要碎片”),那么您可能会看到挂起的连接。在你的情况下,连接最终成功,所以我不认为这是你的问题,但值得检查。 (如果需要,您也可以减少MTU并更改MTU发现算法,但除非这是您的问题并且无法修复路由器,否则您应该单独保留它。)
如果Windows机器在域中,它可能正在尝试并且无法建立IPSec关系。这取决于客户端和服务器的配置。通常这会很快失败,但是如果你阻止某些IPSec流量,你可能会看到它失败的速度很快。在网络分析仪中查找IKE和IPSec流量。