websocket.js性能,websocket性能怎麼樣

本文目錄一覽：

• 1、web3js websocket處理數據慢
• 2、如何對基於node.js 的websocket進行並發訪問的性能測試
• 3、使用Node.js 的優勢和劣勢都有哪些
• 4、一文吃透 WebSocket 原理

web3js websocket處理數據慢

數據量大。websocket傳發文件一般使用都是斷電續傳，切割文件上傳。websocket本來就不是為傳輸大數據設計的，這種大數據量的傳輸，直接用post上傳，建議socket只傳遞短字符串，不然很難做到實時性。

如何對基於node.js 的websocket進行並發訪問的性能測試

java、c#、php都有專門的測試工具去測試並發、負載均衡、平滑性、代碼覆蓋率等的，node這方面還在研究中，空間很大

自己寫個模擬客戶端測試唄，nodejs也有websocket client的實現

不過性能的話不要報太大希望

使用Node.js 的優勢和劣勢都有哪些

我用 Node.js 開發了 Am I Hacked，算是有一點用 Node.js 支持大流量的經驗。先列一些數字

服務器是 Linode 512，也就是 Linode 上最低端的 VPS ，只有 512MB 的內存。

數據庫，Node.js 程序和靜態文件都放在同一台服務器上。

大部分查詢耗時 20-100ms 。少數查詢由於緩存 miss 較多，耗時會高達500ms。

最高日PV超過了一百萬，Google Analytic 上顯示的同時在線人數最高達2000。

平均每秒能完成20-30次查詢，瓶頸在磁盤IO，CPU幾乎無壓力。

雖然壓力如此之大，首頁幾乎都能在一秒內打開，查詢也會在3秒內返回。

Node.js 程序佔用內存 90MB-110MB，剩餘內存都被磁盤緩存佔據。

以我的了解，Python 和 Ruby 上的非 Event Driven 的 Framework 根本不可能達到這樣的性能。

然後說說 Node.js 的其他優點

Node.js 的架構與 Django, Rails 等傳統的 Framework 不同，不需要放在 Nginx / Apache 後，利用 WSGI， CGI 之類的接口一板一眼的 [接受Request] – [運行程序邏輯] – [生成並返回Response]。這是一個巨大的變化，之前一些無法想象的功能都有可能實現了。比如 可以用瀏覽器實現 P2P 的文件傳輸。正因為 Node.js 可以更精細的控制 Request 和 Response 的時間和內容，websocket 似乎天生就是為 Node.js 而生的，而配合 這個神奇的庫之後，在 realtime webapp 這個領域，Node.js 已經沒有對手了。

Node.js 的包管理器 npm 設計得比 python 和 ruby 好很多。有很多的 module 開發者。

當然也有一些缺點

Debug 很困難。沒有 stack trace，出了問題很難查找問題的原因。

如果設計不好，很容易讓代碼充滿 callback 。

一文吃透 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進行協議升級轉換。