检查TcpClient是否已实际连接

如何解决检查TcpClient是否已实际连接

我和许多人一样，一直在研究测试TCP会话是否活动/活跃的主题。过多的半有效解决方案似乎是一个不必要的难题。连接在进行自我测试之前一无所知。然后，尽管实际上丢失了连接，但发送尝试仍然可能成功。轮询似乎为连接带来了误报。某些服务器配置为不响应ping。唯一真正的考验似乎是在尝试建立新的连接并感测该尝试是否成功。这似乎不必要，但协议似乎没有一种轻量级的方法来回答“在特定的瞬间，是否有可能将数据从客户端传输到服务器并验证是否已接收到”，这似乎令人感到疯狂。 ？'

我正在使用.net框架及其中公开的TCP对象。断开网络电缆时，可以肯定会立即向所有用户发出信号，表明连接已断开。但是，情况并非如此，我对连接的任何感知都没有意识到这一损失。仅尝试重新建立连接会发现物理链接已断开。

我想念什么？

解决方法

TCP并不能像您认为的那样真正起作用，尽管我们可以做一些事情来使它更适合您。但是首先让我们更好地了解它的工作原理以及为什么会看到自己的行为。

当您打开TCP连接时，TCP使用3次握手来建立连接。客户端发送SYN，服务器以SYN + ACK响应，然后客户端发回ACK。如果双方均未尝试发送任何内容，则连接将闲置在那里。您可以从计算机上拔下电缆。一棵树可能倒下并破坏您的互联网服务。 Internet提供商可以来修理您的Internet服务，并且您可以将电缆插回以太网端口。然后，客户端可以写入套接字，并且应该将其传递给服务器。 （不幸的是，防火墙故意破坏了标准，并且防火墙 可能已决定在等待ISP修复服务时使连接超时。）但是，如果您尝试在电缆连接时建立另一个连接拔掉插头后，TCP会尝试发送SYN，并且很可能会发现“没有通往主机的路由”。因此它无法建立新的连接。

如果您在Internet服务中断时尝试写入套接字，则TCP将尝试发送数据并等待来自服务器的ACK。重传超时后，如果尚未收到ACK，它将再次尝试并以指数方式退避超时。通常经过15次尝试后，它就会放弃，这通常需要花费半小时到一个半小时的时间。

正如您所看到的，TCP试图在面对故障时保持弹性，而您想非常快速地了解故障。需要对连接故障做出快速反应的系统（例如通常在连接故障时会取消未结订单的电子证券交易所）通过定期发送心跳消息并在心跳足够过期时采取措施来将其作为高级协议的一部分来处理。 >

但是，如果您无法控制协议，则可以使用一些套接字选项来改善情况。 SO_KEEPALIVE导致TCP定期发送keepalive数据包，并且最终将超时，具体取决于TCP_KEEPIDLE，TCP_KEEPINTVL和TCP_KEEPCNT的设置。 TCP_USER_TIMEOUT允许您设置超时，以使写入套接字的数据可以保持多长时间不被确认。

这两个选项的确切工作方式和交互方式完全取决于实现，并且您必须考虑当没有未确认的数据，有未确认的数据以及缓慢的使用者导致零窗口时将发生的情况。通常，建议将它们与TCP_USER_TIMEOUT设置为（TCP_KEEPIDLE + TCP_KEEPINTVL * TCP_KEEPCNT）* 1000一起使用，以获得一致的结果。

我们的Cloudflair朋友对Blog entry的工作原理非常满意，但不幸的是，在Linux上。我不知道Windows可以提供的全面性。