jswebsocket重連,前端websocket斷開自動重連

本文目錄一覽：

• 1、WebSocket 心跳檢測和重連機制
• 2、websocket重連不創建新對象
• 3、Websocket斷線重連怎麼實現的
• 4、一文吃透 WebSocket 原理
• 5、websocket
• 6、WebSocket心跳重連講解

WebSocket 心跳檢測和重連機制

簡單地說是為了證明客戶端和伺服器還活著。websocket 在使用過程中，如果遭遇網路問題等，這個時候服務端沒有觸發 onclose 事件，這樣會產生多餘的連接，並且服務端會繼續發送消息給客戶端，造成數據丟失。因此需要一種機制來檢測客戶端和服務端是否處於正常連接的狀態，心跳檢測和重連截止就產生了。

思路是 ：

websocket重連不創建新對象

可以。

我創建了一個新的Web應用程序，該應用程序使用WebSocket連接到Node.JS WebSocket伺服器。現在，節點伺服器可以完成所需的所有工作，並且可以完美運行。

在我的實例中，我實質上創建了一個對象，該對象包裝了WebSocket，然後通過調用connect（使用setInterval重新連接 url ），這將創建另一個WebSocket實例。

Websocket斷線重連怎麼實現的

要實現websocket重連機制，首先要分析websocket的工作環境。socket的接收和發送都是阻塞線程的，所以websocket一般都是用兩個線程分別去負責接收和發送消息。

這裡就以接收和發送都是非同步為前提實現重連。

一文吃透 WebSocket 原理

踩著年末的尾巴，提前布局來年，為來年的工作做個好的鋪墊，所以就開始了面試歷程，因為項目中使用到了 WebSocket ，面試官在深挖項目經驗的時候，也難免提到 WebSocket 相關的知識點，因為之前並沒有考慮這麼深，所以，回答的還是有所欠缺，因此，趕緊趁熱再熟悉熟悉，也藉此機會，整理出來供大家咀嚼，每個項目都有其值得挖掘的閃光點，要用有愛的眼睛去發現。

WebSocket 是一種在單個TCP連接上進行全雙工通信的協議。 WebSocket 使得客戶端和伺服器之間的數據交換變得更加簡單，允許服務端主動向客戶端推送數據。

在 WebSocket API 中，瀏覽器和伺服器只需要完成一次握手，兩者之間就直接可以創建持久性的連接， 並進行雙向數據傳輸。（維基百科）

WebSocket 本質上一種計算機網路應用層的協議，用來彌補 http 協議在持久通信能力上的不足。

WebSocket 協議在2008年誕生，2011年成為國際標準。現在最新版本瀏覽器都已經支持了。

它的最大特點就是，伺服器可以主動向客戶端推送信息，客戶端也可以主動向伺服器發送信息，是真正的雙向平等對話，屬於伺服器推送技術的一種。

WebSocket 的其他特點包括：

我們已經有了 HTTP 協議，為什麼還需要另一個協議？它能帶來什麼好處？

因為 HTTP 協議有一個缺陷：通信只能由客戶端發起，不具備伺服器推送能力。

舉例來說，我們想了解查詢今天的實時數據，只能是客戶端向伺服器發出請求，伺服器返回查詢結果。HTTP 協議做不到伺服器主動向客戶端推送信息。

這種單向請求的特點，註定了如果伺服器有連續的狀態變化，客戶端要獲知就非常麻煩。我們只能使用”輪詢”：每隔一段時候，就發出一個詢問，了解伺服器有沒有新的信息。最典型的場景就是聊天室。輪詢的效率低，非常浪費資源（因為必須不停連接，或者 HTTP 連接始終打開）。

在 WebSocket 協議出現以前，創建一個和服務端進雙通道通信的 web 應用，需要依賴HTTP協議，進行不停的輪詢，這會導致一些問題：

http 協議本身是沒有持久通信能力的，但是我們在實際的應用中，是很需要這種能力的，所以，為了解決這些問題， WebSocket 協議由此而生，於2011年被IETF定為標準RFC6455，並被RFC7936所補充規範。並且在 HTML5 標準中增加了有關 WebSocket 協議的相關 api ，所以只要實現了 HTML5 標準的客戶端，就可以與支持 WebSocket 協議的伺服器進行全雙工的持久通信了。

WebSocket 與 HTTP 的關係圖：

下面一張圖說明了 HTTP 與 WebSocket 的主要區別：

不同點：

與http協議一樣， WebSocket 協議也需要通過已建立的TCP連接來傳輸數據。具體實現上是通過http協議建立通道，然後在此基礎上用真正 WebSocket 協議進行通信，所以WebSocket協議和http協議是有一定的交叉關係的。首先， WebSocket 是一個持久化的協議，相對於 HTTP 這種非持久的協議來說。簡單的舉個例子吧，用目前應用比較廣泛的 PHP 生命周期來解釋。

HTTP 的生命周期通過 Request 來界定，也就是一個 Request 一個 Response ，那麼在 HTTP1.0 中，這次 HTTP 請求就結束了。

在 HTTP1.1 中進行了改進，使得有一個 keep-alive，也就是說，在一個 HTTP 連接中，可以發送多個 Request，接收多個 Response。但是請記住 Request = Response， 在 HTTP 中永遠是這樣，也就是說一個 Request 只能有一個 Response。而且這個 Response 也是被動的，不能主動發起。首先 WebSocket 是基於 HTTP 協議的，或者說借用了 HTTP 協議來完成一部分握手。

首先我們來看個典型的 WebSocket 握手

熟悉 HTTP 的童鞋可能發現了，這段類似 HTTP 協議的握手請求中，多了這麼幾個東西。

這個就是 WebSocket 的核心了，告訴 Apache 、 Nginx 等伺服器：注意啦，我發起的請求要用 WebSocket 協議，快點幫我找到對應的助理處理~而不是那個老土的 HTTP 。

這裡開始就是 HTTP 最後負責的區域了，告訴客戶，我已經成功切換協議啦~

依然是固定的，告訴客戶端即將升級的是 WebSocket 協議，而不是 mozillasocket ，lurnarsocket 或者 shitsocket 。

然後， Sec-WebSocket-Accept 這個則是經過伺服器確認，並且加密過後的 Sec-WebSocket-Key 。伺服器：好啦好啦，知道啦，給你看我的 ID CARD 來證明行了吧。後面的， Sec-WebSocket-Protocol 則是表示最終使用的協議。至此，HTTP 已經完成它所有工作了，接下來就是完全按照 WebSocket 協議進行了。總結， WebSocket 連接的過程是：

優點：

缺點：

心跳就是客戶端定時的給服務端發送消息，證明客戶端是在線的， 如果超過一定的時間沒有發送則就是離線了。

當客戶端第一次發送請求至服務端時會攜帶唯一標識、以及時間戳，服務端到db或者緩存去查詢改請求的唯一標識，如果不存在就存入db或者緩存中， 第二次客戶端定時再次發送請求依舊攜帶唯一標識、以及時間戳，服務端到db或者緩存去查詢改請求的唯一標識，如果存在就把上次的時間戳拿取出來，使用當前時間戳減去上次的時間， 得出的毫秒秒數判斷是否大於指定的時間，若小於的話就是在線，否則就是離線；

通過查閱資料了解到 nginx 代理的 websocket 轉發，無消息連接會出現超時斷開問題。網上資料提到解決方案兩種，一種是修改nginx配置信息，第二種是 websocket 發送心跳包。下面就來總結一下本次項目實踐中解決的 websocket 的斷線 和 重連 這兩個問題的解決方案。主動觸發包括主動斷開連接，客戶端主動發送消息給後端

主動斷開連接，根據需要使用，基本很少用到。

下面主要講一下客戶端也就是前端如何實現心跳包：

首先了解一下心跳包機制

跳包之所以叫心跳包是因為：它像心跳一樣每隔固定時間發一次，以此來告訴伺服器，這個客戶端還活著。事實上這是為了保持長連接，至於這個包的內容，是沒有什麼特別規定的，不過一般都是很小的包，或者只包含包頭的一個空包。

在 TCP 的機制裡面，本身是存在有心跳包的機制的，也就是 TCP 的選項： SO_KEEPALIVE 。系統默認是設置的2小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火牆這些斷線。而且邏輯層處理斷線可能也不是那麼好處理。一般，如果只是用於保活還是可以的。

心跳包一般來說都是在邏輯層發送空的 echo 包來實現的。下一個定時器，在一定時間間隔下發送一個空包給客戶端，然後客戶端反饋一個同樣的空包回來，伺服器如果在一定時間內收不到客戶端發送過來的反饋包，那就只有認定說掉線了。

在長連接下，有可能很長一段時間都沒有數據往來。理論上說，這個連接是一直保持連接的，但是實際情況中，如果中間節點出現什麼故障是難以知道的。更要命的是，有的節點(防火牆)會自動把一定時間之內沒有數據交互的連接給斷掉。在這個時候，就需要我們的心跳包了，用於維持長連接，保活。

心跳檢測步驟：

針對這種異常的中斷解決方案就是處理重連，下面我們給出的重連方案是使用js庫處理：引入 reconnecting-websocket.min.js ，ws建立鏈接方法使用js庫api方法：

斷網監測支持使用js庫： offline.min.js

以上方案，只是拋磚引玉，如果大家有更好的解決方案歡迎評論區分享交流。

WebSocket 是為了在 web 應用上進行雙通道通信而產生的協議，相比於輪詢HTTP請求的方式，WebSocket 有節省伺服器資源，效率高等優點。WebSocket 中的掩碼是為了防止早期版本中存在中間緩存污染攻擊等問題而設置的，客戶端向服務端發送數據需要掩碼，服務端向客戶端發送數據不需要掩碼。WebSocket 中 Sec-WebSocket-Key 的生成演算法是拼接服務端和客戶端生成的字元串，進行SHA1哈希演算法，再用base64編碼。WebSocket 協議握手是依靠 HTTP 協議的，依靠於 HTTP 響應101進行協議升級轉換。

websocket

建立連接（創建WebSocket對象）：

var Socket =new WebSocket(url, [protocol] );// url：伺服器端地址；protocol：可選，指定可接受的子協議。

WebSocket對象提供了兩個屬性、四個事件、兩個方法，分別是：

1.WebSocket.readyState屬性：表示連接狀態

    0——（連接尚未建立）；1——（連接已建立）；2——（連接正在關閉）；3——（連接已經關閉或連接不能打開）

2.WebSocket.bufferedAmount屬性：被send()放入傳輸隊列，還未發出的UTF-8文本位元組數

    ws.addEventListener(‘open’,function(event){

            ws.send(‘Hello Server!’);

    });

     ws.onopen =function(){

        ws.send(‘Hello Server!’);

    }

3.open：WebSocket.onopen()：連接建立時觸發的事件

4.message：WebSocket.onmessage()： 客戶端接收伺服器端發送的信息時觸發

5.error：WebSocket.onerror()：通信發生錯誤時觸發

6.close：WebSocket.onclose()：連接關閉時觸發

7.WebSocket.send()：發送信息的方法

8.WebSocket.close()：關閉連接方法

SOCKJS

SOCKJS 是一個瀏覽器使用的js庫，它提供了一個類似網路的對象，和連貫的，跨瀏覽器的jaApi，可以在瀏覽器和伺服器之間創建一個低延遲，全雙工的跨域通信通道

SOCKJS實現了對瀏覽器的兼容，spring框架提供了很多透明的，回退選項，如果遇到低版本的瀏覽器會自動降級為輪詢，支持就用websocket

sockjs-client

sockjs-client 是從SOCKJS分離出來的客戶端使用的通信模塊

stompjs

STOMP(Simple Text-Orientated Messaging Protocol) 面向消息的簡單文本協議;

websocket只是一個消息架構，不強制使用任何的消息協議，為了更好的在瀏覽器和伺服器之間傳遞消息，使用stomp協議 的stompjs

STOMP與WebSocket 的關係:就是沒使用http而使用stomp協議，在瀏覽器和伺服器之間進行消息傳遞

1.HTTP協議解決了web瀏覽器發起請求以及web伺服器響應請求的細節,假設HTTP協議不存在,只能使用TCP套接字來編寫web應用,你可能認為這是一件瘋狂的事情;

2.直接使用WebSocket(SockJS)就很類似於使用TCP套接字來編寫web應用,因為沒有高層協議,就需要我們定義應用間發送消息的語義,還需要確保連接的兩端都能遵循這些語義;

3同HTTP在TCP套接字上添加請求-響應模型層一樣,STOMP在WebSocket之上提供了一個基於幀的線路格式層,用來定義消息語義、

安裝

npm install sockjs-client –save

npm install stompjs –save

引入

import SockJS from ‘sockjs-client’;

import  Stomp from ‘stompjs’;

export default {

    data(){

        return {

            stompClient:”,

            timer:”,

        }

    },

    methods:{

        initWebSocket() {

            this.connection();

            let that= this;

            // 斷開重連機制,嘗試發送消息,捕獲異常發生時重連

            this.timer = setInterval(() = {

                try {

                    that.stompClient.send(“test”);

                } catch (err) {

                    console.log(“斷線了: ” + err);

                    that.connection();

                }

            }, 5000);

        }, 

        connection() {

            // 建立連接對象

            let socket = new SockJS(‘execution-progress/info?t=1593744273983’);

            var sockjs =new SockJS(url, _reserved, options);

                //server(string)：添加到url的字元串，默認為隨機的4位數

                //transports (string OR array of strings)：回退傳輸列表

                // sessionId (number OR function)：會話標識，函數必須返回一個隨機生成的字元串

            // 獲取STOMP子協議的客戶端對象

            this.stompClient = Stomp.over(socket);

            // 定義客戶端的認證信息,按需求配置

            let headers = {

                Authorization:”

            }

            // 向伺服器發起websocket連接

            this.stompClient.connect(headers,() = {

                this.stompClient.subscribe(‘/topic/public’, (msg) = { // 訂閱服務端提供的某個topic

                    console.log(‘廣播成功’)

                    console.log(msg);  // msg.body存放的是服務端發送給我們的信息

                },headers);

                this.stompClient.send(“/app/chat.addUser”,

                    headers,

                    JSON.stringify({sender: ”,chatType: ‘JOIN’}),

                )  //用戶加入介面

            }, (err) = {

                // 連接發生錯誤時的處理函數

                console.log(‘失敗’)

                console.log(err);

            });

        },    //連接 後台

        disconnect() {

            if (this.stompClient) {

                this.stompClient.disconnect();

            }

        },  // 斷開連接

    },

    mounted(){

        this.initWebSocket();

    },

    beforeDestroy: function () {

        // 頁面離開時斷開連接,清除定時器

        this.disconnect();

        clearInterval(this.timer);

    }

}

WebSocket心跳重連講解

最近在開發小程序用到了WebSocket，小程序提供了相應的原生API，與H5的API使用方式上有一些區別，所以流行的H5的一些成熟的類庫使用起來有些困難，而原生API又存在一些缺陷，所以就自己實現了一套心跳重連機制。

慣例，先簡單介紹一下Websocket。

HTTP 協議是一種無狀態的、無連接的、單向的應用層協議。它採用了請求/響應模型。通信請求只能由客戶端發起，服務端對請求做出應答處理。

所以當我們想伺服器主動給客戶端發送消息，HTTP是做不到的，我們只能使用輪詢或者長輪詢來實現類似的功能，這樣的方式效率低並且浪費資源，為了解決這樣的問題，WebSocket誕生了。

把你給懶得！自己官網看去!

在使用原生WebSocket的時候，我們經常會感覺不太穩定，服務端發送的消息有時候客戶端接收不到，或者是客戶端發送的消息服務端接收不到，雖然WebSocket也提供了onError和onClose的方法，但是經常會有各種未知情況導致斷開連接而並不觸發Error或Close事件。這樣就導致實際連接已經斷開了，而客戶端和服務端卻不知道，還在傻傻的等著消息來。

所以我們要解決的問題就很清晰了：

保證連接狀態，連接斷開時讓客戶端與服務端都能知道，進而重連。

頁面載入後,我們連接socket先

然後調用initEventHandle來綁定各種各樣的事件

這個先放在這我們一會往裡填東西

我們設置一個鎖和最大的重連次數，避免出現無限重連的情況，為了不給伺服器太大的壓力我這裡設置的是5秒重試一次，最多請求12次。

改造一下initEventHandle這樣我們就可以實現一般的觸發Error的斷線重連。

先擼為敬

心跳對象內timeout為每10秒發一次心跳,timeoutObj、serverTimeoutObj是清除定時器用的對象，reset方法重置定時器，start發送心跳。

繼續改造我們的initEventHandle