TCP Keepalive是确定断开链接的唯一机制吗？

Question

我最近遇到了一个问题，即TCP服务器和客户端之间的中间链接已关闭。如果主服务器已关闭，则客户端需要连接到辅助服务器。当主服务器被购买时（例如，在终端上执行^ C），有TCP关闭序列通过，客户端成功检测到断开的链路并尝试辅助。但是，如果中间链路出现故障，客户端和服务器将不知道它。客户端可以检测到的唯一方法是当TCP bufferes填满失败的'send'操作时。

作为解决方案，已使用“TCP Keepalive”机制。这很令人满意。

我的问题是'TCP Keepalive'是唯一的解决方案吗？

-Prabhu

Answer 1

我总是在应用程序级别处理此问题，方法是在客户端和服务器之间通过TCP扩展协议，使用“Keep Alive”-Messages服务器和客户端发送此消息，例如每秒钟，如果他们没有“保持活跃” - 2秒内消息，连接可能会关闭。

TCP的Keep-Alive机制很好，但难以使用，尤其是在不同平台上工作时。

Answer 2

另一种解决方案是在单独的套接字上使用心跳。这样，如果连接断开，您几乎可以立即知道。当主连接发送没有消息边界的流数据时，这非常有用。

Answer 3

您可以使用TCP的带外功能发明并实现自己的保持活动，但我甚至不会考虑这一点，除非您已经为您构建了一个重要问题。

Answer 4

Keepalive旨在处理所谓的半开连接，当其中一方（通常是接收请求的服务器）不知道连接被破坏时。客户端通常知道它，因为尝试向服务器发送请求将返回错误。

另一个选择是让侦听器保持运行 - 当客户端检测到通信问题时，它只是尝试再次连接到服务器。服务器获取传入连接，检查是否来自同一IP地址，如果是这种情况，则关闭打开的连接并建立新连接。

但是如果客户端不知道连接断开而服务器需要发送内容，那么服务器无法重新建立连接，但TCP保持连接状态。

如果您不想使用keepalive，则可以使用应用程序级别的keepalive，例如：发送类似应用程序的回显消息。

Answer 5

即使没有设置SO_KEEPALIVE，如果您尝试沿死tcp连接发送数据，它通常会被重置，或者最终会超时 - 这些中的任何一个最终都会向应用程序发送错误。

SO_KEEPALIVE意味着可以在空闲连接上更快地检测到这一点。就是这样。