websocket心跳重连 websocket-heartbeat-js

初探和实现websocket心跳重连(npm: websocket-heartbeat-js)

心跳重连缘由

websocket是前后端交互的长连接，前后端也都可能因为一些情况导致连接失效并且相互之间没有反馈提醒。因此为了保证连接的可持续性和稳定性，websocket心跳重连就应运而生。

在使用原生websocket的时候，如果设备网络断开，不会立刻触发websocket的任何事件，前端也就无法得知当前连接是否已经断开。这个时候如果调用websocket.send方法，浏览器才会发现链接断开了，便会立刻或者一定短时间后（不同浏览器或者浏览器版本可能表现不同）触发onclose函数。

后端websocket服务也可能出现异常，造成连接断开，这时前端也并没有收到断开通知，因此需要前端定时发送心跳消息ping，后端收到ping类型的消息，立马返回pong消息，告知前端连接正常。如果一定时间没收到pong消息，就说明连接不正常，前端便会执行重连。

为了解决以上两个问题，以前端作为主动方，定时发送ping消息，用于检测网络和前后端连接问题。一旦发现异常，前端持续执行重连逻辑，直到重连成功。

如何实现

在websocket实例化的时候，我们会绑定一些事件：

var ws = new WebSocket(url);
ws.onclose = function () {
    //something
};
ws.onerror = function () {
    //something
};
        
ws.onopen = function () {
   //something
};
ws.onmessage = function (event) {
   //something
}

如果希望websocket连接一直保持，我们会在close或者error上绑定重新连接方法。

ws.onclose = function () {
    reconnect();
};
ws.onerror = function () {
    reconnect();
};
    

这样一般正常情况下失去连接时，触发onclose方法，我们就能执行重连了。

那么针对断网情况的心跳重连，怎么实现呢，我们只需要定时的发送消息，去触发websocket.send方法，如果网络断开了，浏览器便会触发onclose。

简单的实现：

var heartCheck = {
    timeout: 60000,//60ms
    timeoutObj: null,
    reset: function(){
        clearTimeout(this.timeoutObj);
　　　　 this.start();
    },
    start: function(){
        this.timeoutObj = setTimeout(function(){
            ws.send("HeartBeat");
        }, this.timeout)
    }
}

ws.onopen = function () {
   heartCheck.start();
};

ws.onmessage = function (event) {
    heartCheck.reset();
}

如上代码，heartCheck 的 reset和start方法主要用来控制心跳的定时。

什么条件下执行心跳：

当onopen也就是连接成功后，我们便开始start计时，如果在定时时间范围内，onmessage获取到了后端的消息，我们就重置倒计时，

距离上次从后端获取到消息超过60秒之后，执行心跳检测，看是不是断连了，这个检测时间可以自己根据自身情况设定。

判断前端websocket断开(断网但不限于断网的情况）：

当心跳检测执行send方法之后，如果当前websocket是断开状态(或者说断网了)，发送超时之后，浏览器的websocket会自动触发onclose方法，重连就会立刻执行（onclose方法体绑定了重连事件），如果当前一直是断网状态，重连会2秒（时间是自己代码设置的）执行一次直到网络正常后连接成功。

如此一来，判断前端断开websocket的心跳检测就实现了。为什么说是前端主动断开，因为当前这种情况主要是通过前端websocket.send来检测并触发的onclose，后面说后端断开的情况。

我本想测试websocket超时时间，又发现了一些新的问题

1. 在chrome中，如果心跳检测 也就是websocket实例执行send之后，15秒内没发送到另一接收端，onclose便会执行。那么超时时间是15秒。

2. 我又打开了Firefox ，Firefox在断网7秒之后，直接执行onclose。说明在Firefox中不需要心跳检测便能自动onclose。

3.  同一代码， reconnect方法 在chrome 执行了一次，Firefox执行了两次。当然我们在几处地方（代码逻辑处和websocket事件处）绑定了reconnect()，

所以保险起见，我们还是给reconnect()方法加上一个锁，保证只执行一次

目前来看不同的浏览器，有不同的机制，无论浏览器websocket自身会不会在断网情况下执行onclose，加上心跳重连后，已经能保证onclose的正常触发。  其实这是由于socket本身就有底层的心跳，socket消息发送不出去的时候，会等待一定时间看是否能在这个时间之内再次连接上，如果超时便会触发onclose。

判断后端断开：

    如果后端因为一些情况断开了ws，是可控情况下的话，会下发一个断连的通知，这样会触发前端weboscket的onclose方法，我们便会重连。

如果因为一些异常断开了连接，前端是不会感应到的，所以如果前端发送了心跳一定时间之后，后端既没有返回心跳响应消息，前端也没有收到任何其他消息的话，我们就能断定后端发生异常断开了。

一点特别重要的发送心跳到后端，后端收到消息之后必须返回消息，否则超过60秒之后会判定后端主动断开了。再改造下代码:

var heartCheck = {
    timeout: 60000,//60ms
    timeoutObj: null,
    serverTimeoutObj: null,
    reset: function(){
        clearTimeout(this.timeoutObj);
        clearTimeout(this.serverTimeoutObj);
　　　　 this.start();
    },
    start: function(){
        var self = this;
        this.timeoutObj = setTimeout(function(){
            ws.send("HeartBeat");
            self.serverTimeoutObj = setTimeout(function(){
                ws.close();//如果onclose会执行reconnect，我们执行ws.close()就行了.如果直接执行reconnect 会触发onclose导致重连两次
            }, self.timeout)
        }, this.timeout)
    },
}

ws.onopen = function () {
   heartCheck.start();
};
ws.onmessage = function (event) {
    heartCheck.reset();
}

ws.onclose = function () {
    reconnect();
};
ws.onerror = function () {
    reconnect();
};

PS：

    因为目前我们这种方式会一直重连如果没连接上或者断连的话，如果有两个设备同时登陆并且会踢另一端下线，一定要发送一个踢下线的消息类型，这边接收到这种类型的消息，逻辑判断后就不再执行reconnect，否则会出现一只相互挤下线的死循环。

结语

由于断开等原因可能会导致发送的数据没有发送出去，要保证数据不丢失的话，可以做消息回执，也就是a给b发送消息id=1，b返回收到id=1的消息，如果没有回执a可以再次发送消息id=1。

由上文可以看到，我们使用了前端发送ping，后端返回pong的这样一种心跳的方式。也有一种方式是后端主动发送心跳，前端判断是否超时。因为ws链接必须是前端主动请求建立连接，因此重连肯定是给前端来做，所以判断重连逻辑都是写在前端。

上面所说第二种方式是让服务端发送心跳，前端来接收，这样的方式会多节约一点带宽，因为如果是前端发送心跳，后端需要返回心跳，也就是ping pong的过程会有两次数据传递。  而后端来发送心跳的话，就只需要发送ping，前端不需要回应。但是这样造成了一个问题。前端需要和后端约定好心跳间隔，比如后端设置10秒发送一次心跳，那前端就需要设置一个安全值，比如距离上次收到心跳超过12秒还没收到下一个心跳就重连。这种方式的问题在于调节时间就变得不那么灵活了，需要双方都同时确定一个时间约定。后端的逻辑也会比较多一点。
而如果前端来发送ping 后端返回pong的话，那么间隔时间就只需要前端自己控制了。加上我的代码把收到的任何后端信息都可以当作是连接正常，从而重置心跳时间，这样也节约了一些请求次数。
使用我这样的方式，后端比较轻松，只需要在 onmessage 写一段代码，大概如下：

if(msg=='heartbeat') socket.send(anything);

封装了一个npm包，欢迎使用

https://github.com/zimv/websocket-heartbeat-js

https://www.npmjs.com/package/websocket-heartbeat-js

Introduction

The websocket-heartbeat-js is base on WebSocket of browser javascript, whose main purpose is to ensure web client and server connection, and it has a mechanism of heartbeat detection and automatic reconnection. When client device has network outage or server error which causes websocket to disconnect, the program will automatically reconnect until reconnecting is successful again.

Why

When we use the native websocket, if network disconnects, any event function not be executed. So front-end program doesn't know that websocket was disconnected. But if program is now executing ***WebSocket.send()***, browser must discover that message signal is failed, so the onclose function will execute.

Back-end websocket service is likely to happen error, when websocket disconnected that front-end not notice message received. So need to send ping message by timeout. Server return pong message to client when server received ping message. Because received pong message, client know connection normal. If client not received pong message, it is connection abnormal, client will reconnect.

In summary, for solve above two problems. Client should initiative send ping message for check connect status.

How

1.close websocket connection

If websocket need to disconnect, client must execute ***WebsocketHeartbeatJs.close()***. If server wants to disconnect, it should send a close message to client. When client received close message that it to execute ***WebsocketHeartbeatJs.close()***.

Example:

websocketHeartbeatJs.onmessage = (e) => {
    if(e.data == 'close') websocketHeartbeatJs.close();
}

2.ping & pong

Server should to return pong message when the client sends a ping message. Pong message can be of any value. websocket-heartbeat-js will not handle pong message, instead it will only reset heartbeat after receiving any message, as receiving any message means that the connection is normal.

Usage

install

npm install websocket-heartbeat-js

import

import WebsocketHeartbeatJs from 'websocket-heartbeat-js';
let websocketHeartbeatJs = new WebsocketHeartbeatJs({
    url: 'ws://xxxxxxx'
});
websocketHeartbeatJs.onopen = function () {
    console.log('connect success');
    websocketHeartbeatJs.send('hello server');
}
websocketHeartbeatJs.onmessage = function (e) {
    console.log(`onmessage: ${e.data}`);
}
websocketHeartbeatJs.onreconnect = function () {
    console.log('reconnecting...');
}

use script

<script src="./node_modules/websocket-heartbeat-js/dist/index.js"></script>
let websocketHeartbeatJs = new window.WebsocketHeartbeatJs({
    url: 'ws://xxxxxxx'
});

API

websocketHeartbeatJs.ws (WebSocket)

This websocketHeartbeatJs.ws is native Websocket instance. If you need more native Websocket features, operate the websocketHeartbeatJs.ws.

websocketHeartbeatJs.ws == WebSocket(websocketHeartbeatJs.opts.url);

websocketHeartbeatJs.opts (Object)

Attribute	required	type	default	description
url	true	string	none	websocket service address
pingTimeout	false	number	15000	A heartbeat is sent every 15 seconds. If any backend message is received, the timer will reset
pongTimeout	false	number	10000	After the Ping message is sent, the connection will be disconnected without receiving the backend message within 10 seconds
reconnectTimeout	false	number	2000	The interval of reconnection
pingMsg	false	string	"heartbeat"	Ping message value
repeatLimit	false	number	null	The trial times of reconnection。default: unlimited

const options = {
    url: 'ws://xxxx',
    pingTimeout: 15000, 
    pongTimeout: 10000, 
    reconnectTimeout: 2000,
    pingMsg: "heartbeat"
}
let websocketHeartbeatJs = new WebsocketHeartbeatJs(options);

websocketHeartbeatJs.send(msg) (function)

Send the message to the back-end service

websocketHeartbeatJs.send('hello server');

websocketHeartbeatJs.close() (function)

The front end manually disconnects the websocket connection. This method does not trigger reconnection.

hook function and event function

websocketHeartbeatJs.onclose (function)

websocketHeartbeatJs.onclose = () => {
    console.log('connect close');
}

websocketHeartbeatJs.onerror (function)

websocketHeartbeatJs.onerror = () => {
    console.log('connect onerror');
}

websocketHeartbeatJs.onopen (function)

websocketHeartbeatJs.onopen = () => {
    console.log('open success');
}

websocketHeartbeatJs.onmessage (function)

websocketHeartbeatJs.onmessage = (e) => {
    console.log('msg:', e.data);
}

websocketHeartbeatJs.onreconnect (function)

websocketHeartbeatJs.onreconnect = (e) => {
    console.log('reconnecting...');
}

demo

demo show

blog

初探和实现websocket心跳重连

RFC 6455 - The WebSocket Protocol https://tools.ietf.org/html/rfc6455#section-5.5

5.5.2. Ping

   The Ping frame contains an opcode of 0x9.

   A Ping frame MAY include "Application data".

   Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in
   response, unless it already received a Close frame.  It SHOULD
   respond with Pong frame as soon as is practical.  Pong frames are
   discussed in Section 5.5.3.

   An endpoint MAY send a Ping frame any time after the connection is
   established and before the connection is closed.

   NOTE: A Ping frame may serve either as a keepalive or as a means to
   verify that the remote endpoint is still responsive.

5.5.3. Pong

   The Pong frame contains an opcode of 0xA.

   Section 5.5.2 details requirements that apply to both Ping and Pong
   frames.

   A Pong frame sent in response to a Ping frame must have identical
   "Application data" as found in the message body of the Ping frame
   being replied to.

   If an endpoint receives a Ping frame and has not yet sent Pong
   frame(s) in response to previous Ping frame(s), the endpoint MAY
   elect to send a Pong frame for only the most recently processed Ping
   frame.

Writing WebSocket servers - Web APIs | MDN https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#Pings_and_Pongs_The_Heartbeat_of_WebSockets

Pings and Pongs: The Heartbeat of WebSockets

At any point after the handshake, either the client or the server can choose to send a ping to the other party. When the ping is received, the recipient must send back a pong as soon as possible. You can use this to make sure that the client is still connected, for example.

A ping or pong is just a regular frame, but it's a control frame. Pings have an opcode of 0x9, and pongs have an opcode of 0xA. When you get a ping, send back a pong with the exact same Payload Data as the ping (for pings and pongs, the max payload length is 125). You might also get a pong without ever sending a ping; ignore this if it happens.

If you have gotten more than one ping before you get the chance to send a pong, you only send one pong.

Closing the connection

To close a connection either the client or server can send a control frame with data containing a specified control sequence to begin the closing handshake (detailed in Section 5.5.1). Upon receiving such a frame, the other peer sends a Close frame in response. The first peer then closes the connection. Any further data received after closing of connection is then discarded. 

Sending and receiving heartbeat messages — django-websocket-redis 0.5.2 documentation https://django-websocket-redis.readthedocs.io/en/latest/heartbeats.html

Sending and receiving heartbeat messages

The Websocket protocol implements so called PING/PONG messages to keep Websockets alive, even behind proxies, firewalls and load-balancers. The server sends a PING message to the client through the Websocket, which then replies with PONG. If the client does not reply, the server closes the connection.

The client part

Unfortunately, the Websocket protocol does not provide a similar method for the client, to find out if it is still connected to the server. This can happen, if the connection simply disappears without further notification. In order to have the client recognize this, some Javascript code has to be added to the client code responsible for the Websocket:

var ws = new WebSocket('ws://www.example.com/ws/foobar?subscribe-broadcast');
var heartbeat_msg = '--heartbeat--', heartbeat_interval = null, missed_heartbeats = 0;

function on_open() {
    // ...
    // other code which has to be executed after the client
    // connected successfully through the websocket
    // ...
    if (heartbeat_interval === null) {
        missed_heartbeats = 0;
        heartbeat_interval = setInterval(function() {
            try {
                missed_heartbeats++;
                if (missed_heartbeats >= 3)
                    throw new Error("Too many missed heartbeats.");
                ws.send(heartbeat_msg);
            } catch(e) {
                clearInterval(heartbeat_interval);
                heartbeat_interval = null;
                console.warn("Closing connection. Reason: " + e.message);
                ws.close();
            }
        }, 5000);
    }
}

The heartbeat message, here --heartbeat-- can be any magic string which does not interfere with your remaining logic. The best way to achieve this, is to check for that magic string inside the receive function, just before further processing the message:

function on_message(evt) {
    if (evt.data === heartbeat_msg) {
        // reset the counter for missed heartbeats
        missed_heartbeats = 0;
        return;
    }
    // ...
    // code to further process the received message
    // ...
}

The server part

The main loop of the Websocket server is idle for a maximum of 4 seconds, even if there is nothing to do. After that time interval has elapsed, this loop optionally sends a magic string to the client. This can be configured using the special setting:

WS4REDIS_HEARTBEAT = '--heartbeat--'

The purpose of this setting is twofold. During processing, the server ignores incoming messages containing this magic string. Additionally the Websocket server sends a message with that magic string to the client, about every four seconds. The above client code awaits these messages, at least every five seconds, and if too many were not received, it closes the connection and tries to reestablish it.

By default the setting WS4REDIS_HEARTBEAT is None, which means that heartbeat messages are neither expected nor sent.

Next  Previous