心跳是什么
由于在长连接的场景下，客户端和服务端并不是一直处于通信状态，如果双方长期没有沟通则双方都不清楚对方目前的状态，所以需要发送一段很小的报文告诉对方“我还活着”
为什么有了tcp 的KeepAlive 机制还要在应用层实现心跳机制呢？
TCP的KeepAlive机制只能保证连接的存在，但是并不能保证客户端以及服务端的可用性。
例如:
某台服务器因为某些原因导致负载超高，CPU 100%，无法响应任何业务请求，但是使用 TCP 探针则仍旧能够确定连接状态，这就是典型的连接活着但业务提供方已死的状态。
对客户端而言，这时的最好选择就是断线后重新连接其他服务器，而不是一直认为当前服务器是可用状态，一直向当前服务器发送些必然会失败的请求.从上面我们可以知道，KeepAlive 并不适用于检测双方存活的场景，这种场景还得依赖于应用层的心跳。
应用层心跳有着更大的灵活性，可以控制检测时机，间隔和处理流程，甚至可以在心跳包上附带额外信息。从这个角度而言，应用层的心跳的确是最佳实践。
应用层的心跳
应用层心跳实际上就是客户端每隔一定时间间隔，向IM服务端发送一个业务层的数据包告知自身存活。心跳失败后，服务器可以踢用户下线，或者客户端可以重连。
注意：1.心跳成功了是一定成功了，失败了不一定是失败了，客户端需要重试机制，不断发送心跳失败 n 次之后，才认为是连接断开。
简单粗暴的方法就是定时心跳，客户端每隔一段时间去给服务器发一个心跳包。这样会比较费电和费流量。 心跳发送的间隔时间是整个心跳机制方案设计的重点难点。可以参考Android微信智能心跳方案
