应用程序级心跳比 TCP keepalives 更可取吗？答案

【问题标题】：Is application level heartbeating preferable to TCP keepalives?应用程序级心跳比 TCP keepalives 更可取吗？
【发布时间】：2015-08-20 20:15:27
【问题描述】：

鉴于我们的设置中只涉及 Windows 和 Linux 机器，我是否应该使用应用程序级心跳而不是 TCP keepalives 来检测陈旧连接？

【问题讨论】：

不知道你在问什么，更多信息？
您如何检测到连接已失效？意思是，它不再连接到另一端（但没有收到 RST 数据包）。 ZeroMQ 文档详细介绍了克服此问题的应用程序级别技巧，但我不明白为什么在套接字级别设置 TCP 保持活动选项还不够。

标签： sockets zeromq

【解决方案1】：

在 Windows 或 OSX 上似乎无法基于每个套接字设置 TCP keepalive 参数，这就是原因。

编辑：除了keepalive重传次数之外的所有参数实际上也可以在Windows（2000年以后）上设置：http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220%28v=vs.85%29.aspx

我试图用 zeromq 来做这件事，但似乎 zeromq 在 Windows 上不支持这个？

【讨论】：

【解决方案2】：

来自 John Jefferies 的回复：ZMQ Pattern Dealer/Router HeartBeating

“心跳不是保持连接活动的必要条件（TCP 套接字有一个 ZMQ_TCP_KEEPALIVE 套接字选项）。相反，双方都需要心跳才能知道对方仍然处于活动状态。如果任何一方检测到另一个是不活动的，它可以采取替代行动。”

【讨论】：

【解决方案3】：

TCP keepalive 提供与应用程序级心跳完全不同的功能。 keepalive 就是这样做的，它使 TCP 会话保持活动状态，而不是让它在长时间的静默后超时。这很重要而且很好，并且（如果合适的话）你应该在你的应用程序中使用它。但是由于不活动而导致 TCP 会话死亡只是在一对 ZMQ 套接字之间切断连接的一种方式。一个端点可能会断电 90 分钟并处于离线状态，在这种情况下，TCP keepalives 不会为您做蹲点。

应用程序级心跳不是旨在保持 TCP 会话处于活动状态，希望您尽可能依赖 keepalives 来实现该功能。心跳可以告诉您的应用程序连接实际上仍然处于活动状态并且对等套接字仍然正常工作。这将告诉您您的对等方不可用，因此您可以通过缓存消息、抛出异常、发送警报等来适当地行事。

简而言之：

TCP keepalive 旨在保持连接活动（但不能防止所有断开连接情况）
应用级心跳旨在告诉您的应用程序如果连接处于活动状态

【讨论】：

我不同意。您说如果端点断电 90 分钟，TCP keepalives 不会蹲下？那会怎样，因为离线端点将不再响应 TCP keepalive，并且连接将被视为已死。这正是我使用 TCP keepalives 的场景，而且效果很好。
你强迫我做一些阅读 - 我只使用 keepalive 来避免空闲超时，但看到它是旨在实际提供断开连接的信息，如果他们也发生。也就是说，答案仍然是 ZMQ 不使用 TCP keepalives 的这一特性，并且不为您的应用程序提供断开连接事件数据，因此它减少了仅执行其防止闲置的作用。这是设计师的一个有意识的决定，他们的推理归结为他们抽象的一个目标是使断开和重新连接更加无缝。
是的，底层 TCP 连接会中断，但 ømq 流会保持连接。这正是我在这里所追求的。但是，ømq 4.0 为应用程序提供了一种检测传输级别断开连接并对其做出反应的方法。一些像 IRC 这样的协议实现了协议级别的心跳，而不是使用 TCP keepalives。这让我困惑了一段时间。