心跳重連緣由

提示：文章最下方有倉庫地址

websocket是前后端交互的長連接，前后端也都可能因為一些情況導致連接失效并且相互之間沒有反饋提醒。因此為了保證連接的可持續(xù)性和穩(wěn)定性，websocket心跳重連就應運而生。

在使用原生websocket的時候，如果設備網(wǎng)絡斷開，不會立刻觸發(fā)websocket的任何事件，前端也就無法得知當前連接是否已經(jīng)斷開。這個時候如果調用websocket.send方法，瀏覽器才會發(fā)現(xiàn)鏈接斷開了，便會立刻或者一定短時間后（不同瀏覽器或者瀏覽器版本可能表現(xiàn)不同）觸發(fā)onclose函數(shù)。

后端websocket服務也可能出現(xiàn)異常，造成連接斷開，這時前端也并沒有收到斷開通知，因此需要前端定時發(fā)送心跳消息ping，后端收到ping類型的消息，立馬返回pong消息，告知前端連接正常。如果一定時間沒收到pong消息，就說明連接不正常，前端便會執(zhí)行重連。

為了解決以上兩個問題，以前端作為主動方，定時發(fā)送ping消息，用于檢測網(wǎng)絡和前后端連接問題。一旦發(fā)現(xiàn)異常，前端持續(xù)執(zhí)行重連邏輯，直到重連成功。

如何實現(xiàn)

在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();
};

這樣一般正常情況下失去連接時，觸發(fā)onclose方法，我們就能執(zhí)行重連了。

那么針對斷網(wǎng)情況的心跳重連，怎么實現(xiàn)呢，我們只需要定時的發(fā)送消息，去觸發(fā)websocket.send方法，如果網(wǎng)絡斷開了，瀏覽器便會觸發(fā)onclose。

簡單的實現(xiàn)：

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方法主要用來控制心跳的定時。

什么條件下執(zhí)行心跳：

當onopen也就是連接成功后，我們便開始start計時，如果在定時時間范圍內，onmessage獲取到了后端的消息，我們就重置倒計時，

距離上次從后端獲取到消息超過60秒之后，執(zhí)行心跳檢測，看是不是斷連了，這個檢測時間可以自己根據(jù)自身情況設定。

判斷前端websocket斷開(斷網(wǎng)但不限于斷網(wǎng)的情況）：

當心跳檢測執(zhí)行send方法之后，如果當前websocket是斷開狀態(tài)(或者說斷網(wǎng)了)，發(fā)送超時之后，瀏覽器的websocket會自動觸發(fā)onclose方法，重連就會立刻執(zhí)行（onclose方法體綁定了重連事件），如果當前一直是斷網(wǎng)狀態(tài)，重連會2秒（時間是自己代碼設置的）執(zhí)行一次直到網(wǎng)絡正常后連接成功。

如此一來，判斷前端斷開websocket的心跳檢測就實現(xiàn)了。為什么說是前端主動斷開，因為當前這種情況主要是通過前端websocket.send來檢測并觸發(fā)的onclose，后面說后端斷開的情況。

我本想測試websocket超時時間，又發(fā)現(xiàn)了一些新的問題

1. 在chrome中，如果心跳檢測 也就是websocket實例執(zhí)行send之后，15秒內沒發(fā)送到另一接收端，onclose便會執(zhí)行。那么超時時間是15秒。

2. 我又打開了Firefox ，F(xiàn)irefox在斷網(wǎng)7秒之后，直接執(zhí)行onclose。說明在Firefox中不需要心跳檢測便能自動onclose。

3.  同一代碼， reconnect方法 在chrome 執(zhí)行了一次，F(xiàn)irefox執(zhí)行了兩次。當然我們在幾處地方（代碼邏輯處和websocket事件處）綁定了reconnect()，

所以保險起見，我們還是給reconnect()方法加上一個鎖，保證只執(zhí)行一次

目前來看不同的瀏覽器，有不同的機制，無論瀏覽器websocket自身會不會在斷網(wǎng)情況下執(zhí)行onclose，加上心跳重連后，已經(jīng)能保證onclose的正常觸發(fā)。  其實這是由于socket本身就有底層的心跳，socket消息發(fā)送不出去的時候，會等待一定時間看是否能在這個時間之內再次連接上，如果超時便會觸發(fā)onclose。

判斷后端斷開：

    如果后端因為一些情況斷開了ws，是可控情況下的話，會下發(fā)一個斷連的通知，這樣會觸發(fā)前端weboscket的onclose方法，我們便會重連。

如果因為一些異常斷開了連接，前端是不會感應到的，所以如果前端發(fā)送了心跳一定時間之后，后端既沒有返回心跳響應消息，前端也沒有收到任何其他消息的話，我們就能斷定后端發(fā)生異常斷開了。

一點特別重要的發(fā)送心跳到后端，后端收到消息之后必須返回消息，否則超過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會執(zhí)行reconnect，我們執(zhí)行ws.close()就行了.如果直接執(zhí)行reconnect 會觸發(fā)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：

    因為目前我們這種方式會一直重連如果沒連接上或者斷連的話，如果有兩個設備同時登陸并且會踢另一端下線，一定要發(fā)送一個踢下線的消息類型，這邊接收到這種類型的消息，邏輯判斷后就不再執(zhí)行reconnect，否則會出現(xiàn)一只相互擠下線的死循環(huán)。

結語

由于斷開等原因可能會導致發(fā)送的數(shù)據(jù)沒有發(fā)送出去，要保證數(shù)據(jù)不丟失的話，可以做消息回執(zhí)，也就是a給b發(fā)送消息id=1，b返回收到id=1的消息，如果沒有回執(zhí)a可以再次發(fā)送消息id=1。

由上文可以看到，我們使用了前端發(fā)送ping，后端返回pong的這樣一種心跳的方式。也有一種方式是后端主動發(fā)送心跳，前端判斷是否超時。因為ws鏈接必須是前端主動請求建立連接，因此重連肯定是給前端來做，所以判斷重連邏輯都是寫在前端。

上面所說第二種方式是讓服務端發(fā)送心跳，前端來接收，這樣的方式會多節(jié)約一點帶寬，因為如果是前端發(fā)送心跳，后端需要返回心跳，也就是ping pong的過程會有兩次數(shù)據(jù)傳遞。  而后端來發(fā)送心跳的話，就只需要發(fā)送ping，前端不需要回應。但是這樣造成了一個問題。前端需要和后端約定好心跳間隔，比如后端設置10秒發(fā)送一次心跳，那前端就需要設置一個安全值，比如距離上次收到心跳超過12秒還沒收到下一個心跳就重連。這種方式的問題在于調節(jié)時間就變得不那么靈活了，需要雙方都同時確定一個時間約定。后端的邏輯也會比較多一點。
而如果前端來發(fā)送ping 后端返回pong的話，那么間隔時間就只需要前端自己控制了。加上我的代碼把收到的任何后端信息都可以當作是連接正常，從而重置心跳時間，這樣也節(jié)約了一些請求次數(shù)。
使用我這樣的方式，后端比較輕松，只需要在 onmessage 寫一段代碼，大概如下：

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

封裝了一個npm包，歡迎使用

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

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

以上就是websocket心跳重連實現(xiàn)探索(npm:websocket-heartbeat-js)的詳細內容，更多關于websocket心跳重連的資料請關注腳本之家其它相關文章！

最新評論