在 TCP 中检测到其他对等方已关闭

Posted 2023-02-17

【中文标题】在 TCP 中检测到其他对等方已关闭

【英文标题】：Detecting the other peer is down in TCP

【发布时间】：2013-02-25 09:27:37

【问题描述】：

我正在构建一个基于 TCP 的 APP，为了检测另一端宕机，我需要实现一个心跳机制，让客户端不断发送伪 ping 数据包。我做了一些测试，看到当另一端宕机时，读取的字节数为0。

所以我可以不这样吗？：

If  FD is set, then 
read from fd
if read bytes is 0 then
Assume socket is closed, close fd and do a reconnect.

这对我有用，所以我不明白需要保持活动状态，我对服务器有相同的逻辑，它对我有用。

我的想法是正确的吗？

【问题讨论】：

阅读tldp.org/HOWTO/TCP-Keepalive-HOWTO

是的，我知道TCP keepalive，但是我说keepalives时指的是APP心跳

您可能想致电poll(2) syscall。但我不明白你的问题。如果你想要一些应用程序级的“心跳”，让它像任何其他请求一样......

想象一下你只从你的套接字中读取。然后你拔掉向你发送数据的人的网络电缆。或者你用大锤砸碎它。或者中间的一些路由器着火了。您如何检测到对等方已消失？ read() 不会返回 0。如果您使用阻塞套接字，read() 将永远不会返回。该套接字上不会出现任何数据。除非你尝试在那个套接字上发送一些东西，否则你永远不会知道它已经消失了。 （请注意，在这种情况下有许多个极端情况，有些比我描述的要糟糕得多，有些更容易，有些你会收到对等点离开的通知）

***.com/questions/4345415/…

【参考方案1】：

读返回0的原因是对端发送了FIN。如果您和对等方之间存在某些网络问题（网线已拔出），您的应用程序如何在没有 keepalive 的情况下检测到它？读取会阻塞很长时间（取决于您的操作系统环境）。

【讨论】：

为什么我不能使用 tcp keepalives 而不是 APP heartbeats..TCP 不是设计来处理的吗？

***.com/questions/4345415/… 这里他们说不能使用 TCP keepalives

不，他们没有。他们说不应该使用它们。并不是说它们不能使用。当然，默认的 TCP keepalives 以小时为单位——这通常是不合适的，大多数健壮的应用程序应该对它们如何检测和响应中断有更多的控制（如果你使用 TCP keepalives，你几乎无法控制。）跨度>