WebSocket 的错误处理与断线重连

发布于:2025-03-28 ⋅ 阅读:(21) ⋅ 点赞:(0)

websocket 断线重连

心跳就是客户端定时的给服务端发送消息,证明客户端是在线的 如果超过一定的时间没有发送则就是离线了。

如何判断在线离线?

当客户端第一次发送请求至服务端时会携带唯一标识、以及时间戳,服务端到 db 或者缓存去查询改请求的唯一标识,如果不存在就存入 db 或者缓存中,

第二次客户端定时再次发送请求依旧携带唯一标识、以及时间戳,服务端到 db 或者缓存去查询改请求的唯一标识,如果存在就把上次的时间戳拿取出来,使用当前时间戳减去上次的时间,

得出的毫秒秒数判断是否大于指定的时间,若小于的话就是在线,否则就是离线;

如何解决断线问题?

通过查阅资料了解到 nginx 代理的 websocket 转发,无消息连接会出现超时断开问题。网上资料提到解决方案两种,一种是修改 nginx 配置信息,第二种是 websocket 发送心跳包。

下面就来总结一下本次项目实践中解决的 websocket 的断线 和 重连 这两个问题的解决方案。

主动触发包括主动断开连接,客户端主动发送消息给后端

  1. 主动断开连接

ws.close();

主动断开连接,根据需要使用,基本很少用到。

  1. 主动发送消息

ws.send("hello world");

针对 websocket 断线我们来分析一下,

断线的可能原因 1:websocket 超时没有消息自动断开连接

应对措施:

这时候我们就需要知道服务端设置的超时时长是多少,在小于超时时间内发送心跳包,有 2 中方案:一种是客户端主动发送上行心跳包,另一种方案是服务端主动发送下行心跳包。

下面主要讲一下客户端也就是前端如何实现心跳包:

首先了解一下心跳包机制

跳包之所以叫心跳包是因为:它像心跳一样每隔固定时间发一次,以此来告诉服务器,这个客户端还活着。事实上这是为了保持长连接,至于这个包的内容,是没有什么特别规定的,不过一般都是很小的包,或者只包含包头的一个空包。

在 TCP 的机制里面,本身是存在有心跳包的机制的,也就是 TCP 的选项:SO_KEEPALIVE。系统默认是设置的 2 小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般,如果只是用于保活还是可以的。

心跳包一般来说都是在逻辑层发送空的 echo 包来实现的。下一个定时器,在一定时间间隔下发送一个空包给客户端,然后客户端反馈一个同样的空包回来,服务器如果在一定时间内收不到客户端发送过来的反馈包,那就只有认定说掉线了。

在长连接下,有可能很长一段时间都没有数据往来。理论上说,这个连接是一直保持连接的,但是实际情况中,如果中间节点出现什么故障是难以知道的。更要命的是,有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉。在这个时候,就需要我们的心跳包了,用于维持长连接,保活。

心跳检测步骤:

  1. 客户端每隔一个时间间隔发生一个探测包给服务器

  2. 客户端发包时启动一个超时定时器

  3. 服务器端接收到检测包,应该回应一个包

  4. 如果客户机收到服务器的应答包,则说明服务器正常,删除超时定时器

  5. 如果客户端的超时定时器超时,依然没有收到应答包,则说明服务器挂了

// 前端解决方案:心跳检测
var heartCheck = {
  timeout: 30000, //30秒发一次心跳
  timeoutObj: null,
  serverTimeoutObj: null,
  reset: function () {
    clearTimeout(this.timeoutObj);
    clearTimeout(this.serverTimeoutObj);
    return this;
  },
  start: function () {
    var self = this;
    this.timeoutObj = setTimeout(function () {
      //这里发送一个心跳,后端收到后,返回一个心跳消息,
      //onmessage拿到返回的心跳就说明连接正常
      ws.send("ping");
      console.log("ping!");

      self.serverTimeoutObj = setTimeout(function () {
        //如果超过一定时间还没重置,说明后端主动断开了
        ws.close(); //如果onclose会执行reconnect,我们执行ws.close()就行了.如果直接执行reconnect 会触发onclose导致重连两次
      }, self.timeout);
    }, this.timeout);
  },
};
断线的可能原因 2:websocket 异常包括服务端出现中断,交互切屏等等客户端异常中断等等

当若服务端宕机了,客户端怎么做、服务端再次上线时怎么做?

客户端则需要断开连接,通过 onclose 关闭连接,服务端再次上线时则需要清除之间存的数据,若不清除 则会造成只要请求到服务端的都会被视为离线。

针对这种异常的中断解决方案就是处理重连,下面我们给出的重连方案是使用 js 库处理:引入 reconnecting-websocket.min.js,ws 建立链接方法使用 js 库 api 方法:

var ws = new ReconnectingWebSocket(url);
// 断线重连:
reconnectSocket(){
    if ('ws' in window) {
        ws = new ReconnectingWebSocket(url);
    } else if ('MozWebSocket' in window) {
       ws = new MozWebSocket(url);
    } else {
      ws = new SockJS(url);
    }
}

断网监测支持使用 js 库:offline.min.js

onLineCheck(){
    Offline.check();
    console.log(Offline.state,'---Offline.state');
    console.log(this.socketStatus,'---this.socketStatus');

    if(!this.socketStatus){
        console.log('网络连接已断开!');
        if(Offline.state === 'up' && websocket.reconnectAttempts > websocket.maxReconnectInterval){
            window.location.reload();
        }
        reconnectSocket();
    }else{
        console.log('网络连接成功!');
        websocket.send("heartBeat");
    }
}

// 使用:在websocket断开链接时调用网络中断监测
websocket.onclose => () {
    onLineCheck();
};