分类： 信息化
2022-06-09 10:16:38
当要实现IM即时通讯聊天、消息推送等高实时性需求时，我们一般会选择长连接的通信方式。
而真正当实现长连接方式时，会遇到很多技术问题，比如最常见的长连接保活问题。
长连接的主要作是通过长时间保持双方连接，从而：
PS：对于IM这类的开发者而言，通常大家都把HTTP协议称“短连接”、把直接基于TCP、UDP或WebSocket的socket称为“长连接”。
从上节可知，在使用长连接的情况下，双方的所有通信都建立在1条长连接上（比如1次TCP连接）。所以，长连接需要持续保持双方连接才可使得双方持续通信。
然而，实际情况是，长连接会存在断开的情况。
这些断开原因主要是：
下面，我将对每种原因进行分析。
1）原因1：进程被杀死
当进程被杀死后，长连接也会随之断开。进程被杀在Andriod端是最常见的问题
2）原因2：NAT 超时（重点关注）
特别注意：排除其他外因（网络切换、NAT超时、人为原因），TCP长连接在双方都不断开连接的情况上，本质上是不会自动中断的（也就是不需要心跳包来维持，可以验证一下：让2台电脑连上同1个Wifi，其中1台做服务器, 另1台做客户端连接服务器（无设置KeepAlive）。只要电脑、路由器不断网断电，那么，2台电脑的长连接是不会自动中断的）。即时通讯聊天软件app开发可以加v：weikeyun24咨询
3）原因3：网络状态发生变化
当移动客户端网络状态发生变化时（如移动网络 & Wifi切换、断开、重连），也会使长连接断开。
4）原因4：其他不可抗因素
如网络状态差、DHCP的租期到期等等，都会使得长连接发生 偶然的断开。DHCP的租期到期：对于 Android系统， DHCP到了租期后不会主动续约（继续使用过期IP），从而导致长连接断开。
在了解长连接断开原因后，针对这些原因，此处给出我的高效维持长连接的解决方案
说得简单点，高效维持长连接的关键在于：
心跳保活机制
这是本文的重点，下节开始会详细解析
断线重连机制
原理就是：检测网络状态变化并及时判断连接的有效性。
具体实现：这个其实跟心跳保活机制是一套完整的逻辑，所以下面会在心跳保活机制中一起讲解。
对国、内外主流的移动IM产品（WhatsApp、Line、微信）进行了心跳机制的简单分析和对比。
下面，我将根据市面上主流的心跳机制，设计了一套心跳机制方案。
对于心跳机制方案设计的主要考虑因素是：
从上图可以看出，对于心跳机制方案设计的要点在于：
在下面的方案设计中，将针对这3个问题给出详细的解决方案。
为了减少流量并提高发送效率，需要精简心跳包的设计。
设计方案：
心跳包 = 1个携带少量信息 & 大小在10字节内的信息包
为了 防止NAT超时并减少设备资源的消耗（网络流量、电量、CPU等等），心跳发送的间隔时间是整个心跳机制方案设计的重点。
一般，最直接且常用的心跳发送间隔时间设置方案多采用：“每隔估计 x 分钟发送心跳包1次”。其中，x ＜5分钟即可（综合主流移动IM产品，此处建议 x= 4分钟）。
1）如何自适应计算心跳间隔 从而使得心跳间隔 接近 当前NAT 超时时间？
答：不断增加心跳间隔时间进行心跳应答测试，直到心跳失败5次后，即可找出最接近 当前NAT 超时时间的心跳间隔时间。
注：只有当心跳间隔 接近 NAT 超时时间 时，才能最大化平衡 长连接不中断 & 设备资源消耗最低的问题。
2）如何检测 当前网络环境的NAT 超时时间 发生了变化 ？
答：当前发送心跳包成功 的最大间隔时间（即最接近NAT超时时间的心跳间隔） 发送失败5次后，则判断当前网络环境的NAT 超时时间 发生了变化。
注：在检测到 NAT 超时时间 发生变化后，重新自适应计算心跳间隔 从而使得心跳间隔 接近 NAT 超时时间
技术上来说：长连接的心跳保活依赖于心跳机制，在心跳机制起作用的情况下，适时启动断线重连机制，在心跳机制和断线重连机制的共同作用下才能实现真正的心跳保活。但为了让逻辑更清晰，我把断线重连机制跟心跳机制单独各作为一节来讲解。本节讲的是断片线重连机制。
该机制的核心在于：如何判断长连接的有效性。即：什么情况下视为长连接断线？
1）设计原则：
基本逻辑就是：判断长连接是否有效的准则 = 服务器是否返回心跳应答。
2）具体方案：
实现思路：通过计数计算，若连续5次发送心跳后，服务器都无心跳应答，则视为长连接无效。
