websocket.js重連,js websocket重連

本文目錄一覽：

• 1、websocket重連不創建新對象
• 2、一文吃透 WebSocket 原理
• 3、Websocket斷線重連怎麼實現的

websocket重連不創建新對象

可以。

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

在我的實例中，我實質上創建了一個對象，該對象包裝了WebSocket，然後通過調用connect（使用setInterval重新連接 url ），這將創建另一個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重連機制，首先要分析websocket的工作環境。socket的接收和發送都是阻塞線程的，所以websocket一般都是用兩個線程分別去負責接收和發送消息。

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