如何实现一套高效的IM即时通讯长连接自适应心跳保活机制

当要实现IM即时通讯聊天、消息推送等高实时性需求时，我们一般会选择长连接的通信方式。而真正当实现长连接方式时，会遇到很多技术问题，比如最常见的长连接保活问题。

 

什么是长连接

认识长连接：

长连接的主要作是通过长时间保持双方连接，从而：

   1）提高通信速度；2）确保实时性；3）避免短时间内重复连接所造成的信道资源和网络资源的浪费。

长连接与短连接的区别：

PS：对于IM这类的开发者而言，通常大家都把HTTP协议称“短连接”、把直接基于TCP、UDP或WebSocket的socket称为“长连接”。

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

然而，实际情况是，长连接会存在断开的情况。

这些断开原因主要是：

    1）长连接所在进程被杀死（这主要说的是移动端）；2）NAT超时；3）网络状态发生变化；4）其他不可抗因素（网络状态差、DHCP的租期等等 ）。

特别注意：排除其他外因（网络切换、NAT超时、人为原因），TCP长连接在双方都不断开连接的情况上，本质上是不会自动中断的（也就是不需要心跳包来维持，可以验证一下：让2台电脑连上同1个Wifi，其中1台做服务器, 另1台做客户端连接服务器（无设置KeepAlive）。只要电脑、路由器不断网断电，那么，2台电脑的长连接是不会自动中断的）。

 

2）措施2：心跳保活机制

这是本文的重点，下节开始会详细解析

3）措施3：断线重连机制

原理就是：检测网络状态变化并及时判断连接的有效性。

具体实现：这个其实跟心跳保活机制是一套完整的逻辑，所以下面会在心跳保活机制中一起讲解。

心跳保活机制方案总体设计

下面，我将根据市面上主流的心跳机制，设计了一套心跳机制方案。即时通讯聊天软件app开发可以加小蓝豆的v：weikeyun24咨询

心跳机制方案的基本流程：

对于心跳机制方案设计的主要考虑因素是：

    1）要保证消息的实时性；2）要考虑耗费设备的资源（网络流量、电量、CPU等等）。

从上图可以看出，对于心跳机制方案设计的要点在于：

    1）心跳包的规格（内容 & 大小）；2）心跳发送的间隔时间；3）断线重连机制 （核心 = 如何 判断长连接的有效性）。

在下面的方案设计中，将针对这3个问题给出详细的解决方案。

断线重连机制的实现

技术上来说：长连接的心跳保活依赖于心跳机制，在心跳机制起作用的情况下，适时启动断线重连机制，在心跳机制和断线重连机制的共同作用下才能实现真正的心跳保活。但为了让逻辑更清晰，我把断线重连机制跟心跳机制单独各作为一节来讲解。本节讲的是断片线重连机制。

该机制的核心在于：如何判断长连接的有效性。即：什么情况下视为长连接断线？

1）设计原则：

基本逻辑就是：判断长连接是否有效的准则 = 服务器是否返回心跳应答。

此处需要分清长连接的“存活 & 有效“状态的区别：

2）具体方案：

实现思路：通过计数计算，若连续5次发送心跳后，服务器都无心跳应答，则视为长连接无效。

判断流程：

3）网上流传的方案：

在网上流传着一些用于判断长连接是否有效的方案，具体介绍如下：

至此，关于心跳保活机制已经讲解完毕。