网页端聊天不掉线，5招优化即时通讯稳定连接

发不出聊天消息, 刷新页面后又连接上了, 别着急, 核心答案只有一个, 网页端即时通讯不稳定, 大概率是WebSocket连接断开或者被浏览器限制了, 下面我直接给你5个能落地的技巧, 照着去做能够明显改善。

1. 让连接自动重连，别等你手动刷新

好多掉线情况是源于临时网络出现波动, 不用去动页面, 写一个自动重连的机制就可以了。

操作步骤：

1. 掀开你上网页的JS代码篇章, 从中寻觅WebSocket初始设定的部分之处。

2. 这里加个定时器就在onclose事件以及onerror事件当中, 断开之后等待三秒, 然后自动再次调用连接函数。

3. 设定最大重试的次数, 举例来说是十次, 一旦超出这个次数, 就给出“网络异常”的提示, 以此来防止出现无限循环的情况。

使用上自己遇到问题需格外留意的细节是, 千万别采用固定时长三秒那样等来处理相关情况, 我真实经历过在网络状况欠佳的时候会出现频繁进行重新连接的状况。最好是运用指数退避的方式来尝试, 也就是初次进行重新连接的时候等待三秒钟时间, 第二次重新连接的时候等待六秒钟时间, 再来第三次重新连接的时候等待十二秒钟时间, 一直到等待时间达到三十秒作为上限这个限度。通过这样的方式, 既能够节省相关信息资源, 又不会让界面出现卡顿的现象。

优化网络与浏览器配置，提升整体使用流畅度；规范多设备切换登录操作可查看：WhatsApp 网页版多设备切换登录，其实就三步搞定

2. 加个心跳包，防止“假在线”

你瞧着页面之上呈现出已连接状态, 然而消息却没法发送出去, 很大概率连接已然失效了。心跳包乃是每隔一段特定时间就发送一个空消息，以此来确认连接处于存活状态。

操作步骤：

1. 处于前端位置, 每隔三十秒就发送一条固定的内容, 此内容例如是{"type":"ping"}。

2. 在后端接收之后, 进行回复, 回复的内容为{"type":"pong"}。

3. 要是前端接连两次都没能收到回复, 那就主动把连接断掉, 进而触发自动重连。

下面是自用过程中踩坑的具体细节: , 心跳间隔既不能太长, 也不能太短。这一点我有过切身体会。比如那会儿我设置成了15秒, , 结果用户手机处于息屏状态后就频繁发送心跳信号, , 由此导致的结果是既消耗电量, 又耗费流量。经过实践发现最佳的心跳间隔大致在30秒至60之间, , 同时发来的心跳消息要尽量做到轻量, , 不要携带大数据字段。

3. 选对连接方式：别死磕 WebSocket

有些浏览器不支持WebSocket, 特别是旧版本的, 或者防火墙会将其拦截, 故而要准备一个降级方案, 以确保所有环境都能使用。

选项：

首选：WebSocket（实时性最高）

备选1: 服务器发送事件, 此方式仅支持接收, 适宜用于只读场景。

备选2：轮询（每几秒发一次HTTP请求，最兼容但费流量）

操作步骤：

1. 前端先检测是否支持WebSocket，支持就用它。

2. 不支持或连接失败，自动切到SSE或轮询。

3. 将一个连接管理器在代码当中进行统一封装, 对于这三种协议, 后端同样会使其得到统一处理。

涉及自用的踩坑相关细节, 轮询这一操作千万别设置得过于密集, 我曾经设置成间隔2秒进行一次, 当用户数量较多的时候, 直接就把服务器给弄崩溃了。在此建议每次间隔最少5秒进行一次, 并且要用到if - modified - since这个头部来减少重复的数据。

4. 优化页面可见性：切到后台就暂停

浏览器在用户切换至其他标签页或者处于锁屏状态之际, 会使JS执行出现降低或者暂停的情况, 这会直接致使连接超时。你需要主动去监听页面状态。

操作步骤：

1. 依靠基于文档可见性变化的事件来展开监听 , 通过document.visibilitychange事件进行监听。

2. 页面不可见时，停止发送心跳，但保留连接。

3. 当页面再度重现于可视状态之际, 即刻发送一回心跳, 以此查验连接是否依旧存活可用, 若连接已然失效则重新进行连接操作。

私自使用时会碰到的踩坑具体细节是, 不要在呈不可见状态下完全切断连接, 这一点我有亲身尝试过, 当用户切换回原本状态时需要等待长达好几秒的时间才能够得以恢复, 如此一来体验是非常糟糕的。只需把心跳功能暂停, 将连接保留不中断, 当回来的时候进行快速校验便可以了。

5. 客户端缓存消息：防止发送中掉线

你来点击发送按钮, 消息尚未抵达服务器之时网络就断开连接了, 在这个时候消息直接丢失不见。先进行本地存储, 保证发送成功之后再予以删除。

操作步骤：

1. 用户进行点发送操作之后, 先将消息存储到localStorage当中, 或者存储到IndexedEDB里面, 并且把其标记为“待发送”。

2. 将消息投放至发送队列当中, 按照次序逐一进行发送, 每成功发送一条, 便把状态更新成“已发送”。

3. 如果连接断了，队列里的消息不丢，等重连后再自动发。

关于自用过程里边存在的踩坑有关详细情况是, 要记得添加对于去掉重复情况的那套逻辑。我有一回没有添加它, 因为用户那边网络发生了波动, 致使消息发送了两次, 结果对方收到了重复的内容。采用唯一的ID去标记每一条消息, 而后端把该消息收到之后检查这个ID, 如果是重复的就将之丢弃。

FAQ 答疑

问：用了这些方法，为什么有时候还是卡？

答: 或许问题存在于后端, 比如说后端单个点位处理不堪负荷又或者数据库出现卡顿现象, 建议对服务端的WebSocket同步发生数量以及消息处理速率予以检查。

问：我的用户量少，是不是不用搞这么复杂？

答复是, 即便用户数量少, 也建议最少要做自动重连以及心跳, 这两者成本是最低的, 然而却能够解决百分之八十的掉线问题。

总结

欲使网页端即时通讯达至稳定状态, 其核心要点主要涵盖三件要事: 其一为自动重连以保障连接的持续性, 其二是借助心跳包来防止出现假死现象, 其三乃采用降级方案确保兼容性。若依据上述五步去修改代码, 绝大多数掉线以及消息发送失败等问题皆可得以解决。切莫妄图一蹴而就, 不妨先从较为简易的重连与心跳环节着手, 待用户反馈显示稳定之后, 再去补充缓存以及考虑页面可见性相关事宜。

解决在线状态显示异常故障可参考：WhatsApp网页版在线状态不显示？试试这5招