im即时通讯开发：浅析IM长连接、心跳及重连机制

说道“心跳”这个词大家都不陌生，当然不是指男女之间的心跳，而是和长连接相关的。顾名思义就是证明是否还活着的依据。

什么场景下需要心跳呢？目前我们接触到的大多是一些基于长连接的应用需要心跳来“保活”。

由于在长连接的场景下，客户端和服务端并不是一直处于通信状态，如果双方长期没有沟通则双方都不清楚对方目前的状态，所以需要发送一段很小的报文告诉对方“我还活着”。

 

同时还有另外几个目的：

1）服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道，让它下线；

2）客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。

心跳其实有两种实现方式：

1）TCP 协议实现；

2）应用层自己实现。

由于 TCP 协议过于底层，对于开发者来说维护性、灵活度都比较差同时还依赖于操作系统。

在应用层通常是由客户端发送一个心跳包 ping 到服务端，服务端收到后响应一个 pong 表明双方都活得好好的。一旦其中一端延迟 N 个时间窗口没有收到消息则进行不同的处理。

先拿客户端来说吧，每隔一段时间客户端向服务端发送一个心跳包，同时收到服务端的响应。

常规的实现应当是：

    1）开启一个定时任务，定期发送心跳包；

    2）收到服务端响应后更新本地时间；

    3）再有一个定时任务定期检测这个“本地时间”是否超过阈值；

    4）超过后则认为服务端出现故障，需要重连。

这样确实也能实现心跳，但并不友好。

在正常的客户端和服务端通信的情况下，定时任务依然会发送