TcpClient无法连接 [英] TcpClient unable to connect

问题描述

嗨

是否存在过多使用短暂的TCP连接的方式，从而有效地导致到给定端口/主机组合的所有网络连接都停止的问题，除非您终止创建这些连接的应用程序?这是我们正在运行的一些代码 全部10秒钟(或更确切地说，运行……一次，完整等待10秒钟，然后再次运行).与此同时，有多个WCF连接到同一主机/端口(这是一个Web服务器)...

Is there a way too much use of short lived TCP connections could effectively result in any and all network connectivity to a given port/host combination to cease unless you terminate the app that creates those connections? Here's a bit of code we're running all 10 seconds (or rather... run...once complete wait 10 seconds, then run again) At the same time, there's a number of WCF connections to the same host/port (it's a webserver)...

using (TcpClient myClient = new TcpClient())
                    {
                        System.Threading.WaitHandle wh = null;
                        try
                        {
                            logger.write("Starting connectivity check for " + ip4Address.ToString(), 5);
                            IAsyncResult ar = myClient.BeginConnect(ip4Address, myUri.Port, null, null);
                            wh = ar.AsyncWaitHandle;
                            if (!ar.AsyncWaitHandle.WaitOne(10000, false))
                            {
                                logger.write("Unable to connect to " + ipHost + ": " + myUri.Port + " using tcpclient - connection attempt timed out", 2);
                                myClient.Close();
                                //myClient.Close();
                                return false;
                            }
                            else
                            {
                                myClient.EndConnect(ar);
                                //myClient.Close();
                            }
                        }
                        catch (Exception e)
                        {
                            logger.write("Unable to connect to " + ipHost + ": " + myUri.Port + " using tcpclient: " + e.Message, 2);
                            return false;
                        }
                        finally
                        {
                            if (wh != null)
                                wh.Close();
                        }
                    }

一段时间后，没有规律性，我们开始看到无法连接."我们日志中的消息.一旦发生这种情况，所有那些WCF连接将都不起作用(例外消息是没有端点在...监听").那样的话 从受影响的主机到Web服务器的常规http连接不再可能，远程登录(当然也没有端口80)也不再可用.

After a while, with no regularity, we start seeing "Unable to connect to.." messages in our log. Once that happens, all those WCF connections won't work either (exception message being "No endpoint listening at ...."). When that happens, regular http connections are no longer possible from the affected host to the webserver, neither is telnet (to port 80 of course).

有趣的是，该网络服务器还提供HTTPS，并且仍然可以通过webbrowser，cli telnet和我们的应用程序连接到HTTPS.

Interestingly though, the webserver also provides HTTPS, and connections to HTTPS are still possible from webbrowser, cli telnet and our app.

由于这已经工作了好几个月了，所以您会想..发生了什么变化".问题的两边都没有补丁，问题发生在不同的操作系统(Win7/8和2008 R2 Server)上，我们陷入困境，开始嗅探.

Since this has been working just fine for months, you'd think.. "what has changed". No patches on either side of the problem, the problem occurrs on different OS (Win7/8 and 2008 R2 Server), and we've gone down and dirty and started sniffing.

发件人显示出SYN数据包出去了，但它们没有到达防火墙，因此也从未到达目标(我们也正在嗅探的目标)..因此，它们要么被丢弃在主机和防火墙之间的某个位置或它们似乎是由 Wireshark，但切勿将其插入电线.由于我只能设置一个跨接端口，以查看下周是否有数据包进入网络，因此我想问一下这种重复和常规使用TcpClient的方式是否会自行导致问题，从而影响 整个操作系统.因此，我们可以排除目标主机阻塞/限制某些内容，防火墙也是如此(在问题开始之前已对其进行了更新……因此自然而然首先要归咎于此)

The sender shows SYN packets going out, but they don't make it to the firewall and consequently never make it to the target (where we're also sniffing).. so either they are being dropped somewhere between host and firewall or they may appear to be sent by Wireshark, but never make it to the wire. As I can only set up a span port to see if packets make it to the wire next week, I wanted to ask around if there's a way this repeated and regular use of TcpClient could be causing a problem on its own that affects the entire OS.So we can rule out the target host blocking / throttling something, and the same goes for the firewall (which was updated before the problem started... so naturally we blamed that first)

有时，这些WCF Web服务连接中的一个(大约20个)设法传输某些内容，但其他失败.如果发生问题时我更改了目标端口(因为网络服务器也执行https，我可以将其更改为是服务器 还活着"在应用程序运行时检查连接到端口443而不是80.如果这样做，很快就会恢复正常，直到端口443放弃为止.

Every now and then, one of those WCF webservice connections (there's about 20) manages to transmit something, but others fail. If I change the destination port when the problem occurs (as the webserver also does https, I can change that "is the server still alive" check to connect to port 443 rather than 80) while the app is going. If I do that, soon enough things start going back to normal until port 443 gives up.

所以-这种远端是否还活着并很好"?检查我们的操作方式，可能会在主机上引起问题，如果是这样，是否有其他方法可以减少错误发生?自从对ping做出响应以来，无法选择ICMP 并不意味着远端的Web服务器已启动(检查与端口80的连接只是进度的一部分，而其余部分是对我未显示的Web服务的调用..也没有问题).

So - is this kind of "is the remote end still alive and well" check the way we do it something that could cause issues on the host proper, and if so, is there an alternative that's less error prone? ICMP is not an option since responding to a ping doesn't mean the webserver in the remote end is up (checking connection to port 80 is only part of the progress but the rest is a call to a webservice that I'm not showing.. and that has not been problematic either).

顺便说一句...此代码是 替换为使用HttpWebRequest ，因此我的肚子有点that，也许毕竟是代码.

By the way... this code is a replacement of using HttpWebRequest so I have a nagging feeling in the pit of my stomach that perhaps it's the code after all.

谢谢

Stephan

推荐答案

感谢您的信息.

我正在尝试让熟悉此主题的人进一步研究这个问题.可能会有一些时间延迟.感谢您的耐心.

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

最好的问候.

这篇关于TcpClient无法连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！