08 | 智能心跳机制：解决网络的不确定性

袁武林



该思维导图由 AI 生成，仅供参考

你好，我是袁武林。
在前面的章节里，我讲到了在即时消息场景中非常重要的两个特性：“可靠投递”和“实时性”。
为了让消息能更加实时、可靠、快速地触达到接收方，大部分 IM 系统会通过“长连接”的方式来建立收发双方的通信通道，这些基于 TCP 长连接的通信协议，在用户上线连接时，会在服务端维护好连接到服务器的用户设备和具体 TCP 连接的映射关系，通过这种方式服务端也能通过这个映射关系随时找到对应在线的用户的客户端，而且这个长连接一旦建立，就一直存在，除非网络被中断。
因为“长连接”方式相比“短连接轮询”，不仅能节约不必要的资源开销，最重要的是能够通过“服务端推送”，提供更加实时的消息下发。
同样，对于发送方来说，如果发送消息也能通过“长连接”通道把消息给到 IM 服务端，相对于短连接方式，也能省略 TCP 握手和 TLS 握手的几个 RTT 的时间开销，在用户体验和实时性上也会更好。
为什么需要心跳机制“长连接”方式给我们带来了众多好处，那么要让消息通过“长连接”实现可靠投递，最重要的环节就在于如何维护好这个“长连接”。
由于这个“长连接”底层使用的 TCP 连接并不是一个真正存在的物理连接，实际上只是一个无感知的虚拟连接，中间链路的断开连接的两端不会感知到，因此维护好这个“长连接”一个关键的问题在于能够让这个“长连接”能够在中间链路出现问题时，让连接的两端能快速得到通知，然后通过“重连”来重新建立新的可用连接，从而让我们这个“长连接”一直保持“高可用”状态。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

智能心跳机制在即时通讯场景中扮演着重要角色，通过维护长连接的可用性，提供更实时、可靠的消息传递。文章介绍了心跳检测的几种实现方式，包括TCP Keepalive、应用层心跳及智能心跳。应用层心跳相比TCP Keepalive更能反映应用的可用性，而智能心跳则能根据网络环境自动调整心跳间隔，平衡NAT超时和设备资源节约。总体而言，心跳机制能降低服务端连接维护的开销，支持客户端断线重连，并保持长连接的存活时间更长。这些技术方案有助于优化长连接的维护，提高即时通讯系统的性能和稳定性。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《即时消息技术剖析与实战》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(29)

最新
精选

王棕生
解答问题：如果从实现功能角度看，传输层和应用层的心跳机制没有结合的必要，因为传输层的心跳探测连接可用性，应用层的心跳机制也可以完成探测; 但从debug角度看，应用层的心跳探测机制无法定位是网络的问题还是系统的问题，此时由传输层辅助就非常好，但实现会相对复杂！
作者回复: 是的👍
2019-09-14
2
46
rfyiamcool
能简单说下二分法来进行心跳探测的逻辑么？
作者回复: 其实就是下一次动态调整的心跳间隔是：当前已经确认的安全的心跳间隔最大值和已经确认的心跳探测过大的最小值的中间均值。比如上一次心跳间隔是4分钟，而且连续N次都成功ack了，那么当前已经确认的安全的心跳间隔是4分钟，假设已经确认10分钟时心跳间隔过大了，那么下一次调整的心跳就是 4 + 10 / 2 = 7分钟。
2019-10-24
2
11
隰有荷
看了老师的讲解，在理论上是明白了，但是具体实践上该如何操作？比如：tcp的keepalive该如何通过具体的代码语言去实现。这些具体操作性的知识，不知道本课程后面是否有涉及到？
作者回复: tcp的keepalive开启比较简单，比如netty下可以通过如下代码开启： ServerBootstrap bootstrap = new ServerBootstrap(); bootstrap.childOption(ChannelOption.SO_KEEPALIVE, true); 另外tcp keepalive的心跳间隔的配置也需要修改一下系统的/etc/sysctl.conf，类似下面： net.ipv4.tcp_keepalive_time=120 net.ipv4.tcp_keepalive_intvl=30 net.ipv4.tcp_keepalive_probes=3
2019-09-20

9
newzai
智能心跳，采用什么算法逼近或者选择心跳周期？如何感知当前的心跳周期是否太小？因为一旦太大就会导致连接断开
作者回复: 比较常见的有二分法。
2019-09-13

5
dongdong
请问老师，我这里使用应用层发心跳包，很奇怪在内网测试环境，网页一直不操作都不会断线，但在外网同套代码，不操作1，2个小时后，网页的长链接就会断线，WS脚本重连也连不上，但只要重新刷新页面就可以连上了，这是什么原因？
作者回复: 心跳间隔是多少？外网的中间路由环节和运营商网络都可能在一个连接一段时间没有数据传输的时候从NAT表删除这个连接的映射。所以心跳间隔最好不要大于5分钟。
2019-09-16

3
奕
我看上图心跳处理流程，只有客户端当判断连接无效的时候才会进行连接重连，重连的这个动作服务端不会进行吗？如果这样的话服务端还要发送心跳消息进行心跳检测做什么呢？服务端是不是可以这样处理，当一段时间没有收到客户端的心跳包的时候就判断与该客户端的心跳连接断开了，直接释放对应的资源不就可以了吗？
作者回复: 服务端不知道客户端的固定连接地址呀，所以重连一般都是由客户端发起。服务端一般不需要发送心跳，是由客户端来发送心跳，服务端一段时间没有收到客户端的心跳包的时候就可以判断连接异常，主动断开等客户端重连上线就可以了。
2019-09-14

3
蛮野
服务端在进行推送时候，假设判断用户连接有效，即用户在线，此时推送是同时推与客户端应用保持的长连接和apns等多条通道吗？然后在客户端去重？还是每次只会选择一条通道？
作者回复: 会双推，走APNs不会直接落地app的db，苹果会根据应用在前台还是在后台来决定要不要展示APNs走通知栏的消息。现在也有很多应用支持应用在前台时也展示通知栏的消息，看具体需求。
2019-09-13

3
Geek_e7834d
看流程图，服务器检查心跳并不是定时的，而只是推送的时候检测？
作者回复: 具体是哪个图呀，理解不太对，心跳和推送是独立的，并不会在推送的时候进行检测，一般会由独立的定时器来根据一定时间内socket中是否有数据收发来定时触发的。
2019-10-17

2
花指令
老师好，我用go的tcpsocket，有一端异常退出时，另一端会触发掉线通知。所以我不明白的是，socket是不是不需要心跳？还是是因为我是在局域网测试，和公网情况不一样？
作者回复: 因为tcp本身是一个虚拟连接，中间链路断开的话另一端是感知不到的，另外，移动运营商的NAT会对一段时间没有数据传输的连接切断，所以对于维护高可用的一条长连接心跳是必不可少的。
2019-09-16
5
2
大魔王汪汪
老师客户端或服务端心跳实现是在客户端维持一个轮训服务吗？这样会不会有浪费客户端资源的问题，有没有什么好方法解决轮训定时器这种资源浪费问题
作者回复: 一种方式是客户端采用固定timer来定时发送心跳包，也可以在客户端没有消息收发后的一段时间才可以发送心跳包，这样能节约一些流量。
2019-09-14

2

收起评论