使用tcp时我必须保持心跳吗？
我们的分布式应用程序之一使用心跳来检测对等方的断开连接（例如 LAN 线路损坏等）。 心脏有必要跳动吗？
one of the our distributed apps are using heart beat to detect the peer's disconnection(e.g. LAN line broken, etc) .
is the heart beating necessary?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
也许，如果你没有心跳，你会做什么？
如果您使用从服务器到客户端的回调，则需要一种客户端可以要求服务器重新发送所有丢失的回调的方法，这并不容易。
此外，如果您没有心跳，并不意味着消息稍后不会到达那里，因为可能存在各种网络延迟，重新发送消息是否安全？
Maybe, what will do you if you don't get the heart beat?
If you are using call-back from the server to the client, you need a way that the client can ask the server to resent all lost call-backs, this is not easy.
Also if you don’t get a heart beat it does not mean a message will not get there later, as there can be all sort of network delays, is it safe to just resent your messages?
是的。 TCP 只会显示物理连接仍然有效（即套接字没有被路由器或操作系统拆除）。但不会告诉任何有关应用程序可用性的信息。如果管道另一端的进程处于
while(1);循环中并且没有处理您的请求，则您并未真正连接到它。Yes. TCP would only show that the physical connection is still alive (ie. the socket was not teared down by routers or by OS). But will tell nothing about the application availability. If the process at the other end of your pipe is in a
while(1);loop and is not processing your requests, you aren't really connected to it.这是了解您仍然在“应用程序级别”连接到另一端并且应用程序仍然可以通信的好方法。否则，您将不得不假设“另一端”没有什么可“说的”，这很难与“另一端实际上在 35 秒前失去了网络连接”分开。
That is quite a good way to know that you are still connected to the other end at the "application level" and applications can still talk. Otherwise you would have to make assumptions that "the other end" has nothing to "say", which would be hard to separate from "the other end actually lost network connectivity 35 seconds ago".