关于心跳机制设计，我的一点想法

想法

忘了写哈，两年前的旧思想，今天放出来。

1、不要迷信TCP的保活机制，应用层不会知道的。

2、为什么一定要服务端向客户端发心跳包？两年前老师让我们这么写的时候我就提出了疑问，最后我毅然决然的选择了客户端向服务端发心跳。心跳机制对于服务器的意义是什么呢？在我的认知里，是服务器需要知道这个客户端是否还在线。如果客户端不在线了，就要做相应的资源回收或者标记工作。

那客户端呢？客户端心跳发不过去就知道自己挂了嘛，该重连就重连，不重连就关机呗。

我当时为什么会产生那样的想法？如果是服务端向客户端发心跳包，客户端收到心跳之后需要向服务端回一个心跳包，一来一回服务端需要处理两次包。而客户端向服务端发心跳就不同了，首先不需要去记录那么多的时间戳，统一一个时间戳，轮询一遍过去（本来就要轮询）看哪个客户端的心跳包没到，就清理掉即可。

心跳保活我觉得不是那么核心的业务，如果是长连接服务，一万台客户端动不动就掉线个一百台成何体统？ 将资源消耗压下去，和日志等非核心业务挤一条线程嘛。

附：

长连接断开的原因

在长连接的情况下，双方的所有通信 都建立在1条长连接上（1次TCP连接）；所以，长连接 需要 持续保持双方连接 才可使得双方持续通信

可是，长连接会存在断开的情况，而 断开原因 主要是：

长连接所在进程被杀死
NAT超时
网络状态发生变化
其他不可抗因素（网络状态差、DHCP的租期等等 ）