?主動斷開：任何一方發(fā)送Opcode=0x08的關閉幀，雙方確認后關閉 TCP 連接。

4.為什么在握手階段需要升級協(xié)議

WebSocket 并非完全脫離 HTTP，而是借助 HTTP 協(xié)議的 “握手流程” 完成 “協(xié)議切換”—— 通過一次 HTTP 請求，讓客戶端和服務端達成共識：“接下來我們用 WebSocket 協(xié)議通信，不再遵循 HTTP 規(guī)則”。

4.1.這個升級過程的核心價值是：

?兼容現(xiàn)有網(wǎng)絡環(huán)境：所有瀏覽器、網(wǎng)關、代理服務器都支持 HTTP；如果 WebSocket 設計成完全獨立的協(xié)議，可能被現(xiàn)有網(wǎng)絡設備攔截（無法穿透代理 / 防火墻）。

?低成本建立 “長連接共識”：利用 HTTP 握手的 “請求 - 響應” 流程，讓雙方快速確認 “支持 WebSocket”，避免額外的協(xié)議協(xié)商開銷。

4.2、WebSocket 和 HTTP 的關系

?

?

1.3、應用場景

WebSocket 適用于需要低延遲、雙向實時通信的場景，典型案例包括：

?即時通訊工具：如網(wǎng)頁版微信、企業(yè)微信、在線客服系統(tǒng)等，需實時收發(fā)消息，WebSocket 可保證消息更實時。

?實時協(xié)作工具：如騰訊文檔、飛書文檔等，多人同時編輯時，需實時同步光標位置、內容修改，WebSocket 可確保協(xié)作流暢。

?金融行情更新：股票、期貨等實時行情數(shù)據(jù)（每秒多次更新），通過 WebSocket 推送，比輪詢更高效。

?在線游戲：網(wǎng)頁小游戲（如貪吃蛇聯(lián)機版）需要實時同步玩家操作和游戲狀態(tài)，WebSocket 可滿足低延遲需求。

?實時監(jiān)控系統(tǒng)：如物聯(lián)網(wǎng)設備監(jiān)控（溫度、濕度實時數(shù)據(jù)）、服務器性能監(jiān)控，需持續(xù)接收設備 / 服務器推送的狀態(tài)數(shù)據(jù)。

?彈幕系統(tǒng)：視頻網(wǎng)站的實時彈幕， thousands 級用戶同時發(fā)送和接收彈幕，WebSocket 可支撐高并發(fā)推送。

?

二、Server-Sent Events（SSE）

2.1、核心概念

SSE（Server-Sent Events，服務器發(fā)送事件）是一種基于 HTTP 協(xié)議的服務器向客戶端單向實時推送數(shù)據(jù)的技術，專為 “服務器主動向客戶端持續(xù)發(fā)送更新” 場景設計，是 Web 端實時通信的重要方案之一。

SSE 的核心是建立一個持久化的 HTTP 長連接，讓服務器可以隨時向客戶端推送數(shù)據(jù)，而無需客戶端頻繁發(fā)起請求。它是一種 “服務器到客戶端” 的單向通信模式，與 WebSocket 的雙向通信形成互補。

其優(yōu)勢在于原生支持自動重連、API 簡單（EventSource接口）、服務器實現(xiàn)成本低，適合無需客戶端回傳數(shù)據(jù)的場景。與 WebSocket 相比，SSE 更專注于單向推送，實現(xiàn)和維護成本更低，是實時通知、日志展示等場景的理想選擇。

?關鍵特性：

?單向通信：僅支持服務器向客戶端推送數(shù)據(jù)，客戶端無法通過 SSE 向服務器發(fā)送數(shù)據(jù)（需配合 HTTP 或 WebSocket 實現(xiàn)雙向交互）；

?長連接：一次連接建立后持續(xù)保持，避免短連接的反復握手開銷；

?自動重連：連接意外斷開時，客戶端會自動重試連接（默認間隔 3 秒）；

?文本流：數(shù)據(jù)以 UTF-8 文本流格式傳輸，二進制數(shù)據(jù)需編碼后發(fā)送。

2.2、原理介紹

SSE 的工作流程基于 HTTP 長連接和特殊的文本流協(xié)議，主要分為連接建立、數(shù)據(jù)推送和重連機制三個階段：

1. 連接建立：基于 HTTP 的長連接初始化

客戶端通過瀏覽器原生的EventSourceAPI 發(fā)起連接請求，服務器返回符合 SSE 規(guī)范的響應頭，建立持久化連接：

?客戶端請求：

// 客戶端創(chuàng)建 SSE 連接（僅支持 GET 方法）
const sse = newEventSource('/service/stream');

瀏覽器會自動發(fā)送 HTTP 請求，攜帶特殊頭信息（如Accept: text/event-stream）。

?服務器響應頭：

HTTP/1.1200OK
Content-Type:text/event-stream; charset=utf-8  # 核心：標識為 SSE 流
Cache-Control:no-cache  # 禁止緩存，確?？蛻舳私邮諏崟r數(shù)據(jù)
Connection:keep-alive   # 保持 HTTP 長連接
Access-Control-Allow-Origin:*  # 跨域配置（如需）

響應頭必須明確指定text/event-stream類型，告知客戶端 “這是持續(xù)的事件流”。

?

2. 數(shù)據(jù)推送：基于規(guī)范的文本流格式

服務器通過 HTTP 長連接持續(xù)向客戶端發(fā)送 “事件”，每個事件需遵循嚴格的文本格式，以nn作為結束符：

# 格式 1：默認事件（客戶端通過 onmessage 接收）
data: 您有一條新消息n
data: 內容：Hello Worldnn  # 多行 data 會合并為一條消息

# 格式 2：自定義事件名（客戶端通過 addEventListener 接收）
event: orderStatus  # 事件名（如“訂單狀態(tài)更新”）
id: 10086           # 事件 ID（用于重連時定位斷點）
data: 訂單已發(fā)貨nn

# 格式 3：心跳保活（客戶端忽略，僅維持連接）
: 這是注釋，無實際數(shù)據(jù)，防止長連接超時nn

?

3. 重連機制：自動恢復連接與數(shù)據(jù)補發(fā)

SSE 原生支持斷線重連，無需手動實現(xiàn)：

?自動重連：若連接意外斷開（如網(wǎng)絡波動），客戶端會在 3 秒后自動重試，并逐漸增加間隔（最多 30 秒）；

?數(shù)據(jù)補發(fā)：重連時，客戶端會在請求頭中攜帶Last-Event-ID: 1000000（最后接收的事件 ID），服務器可基于此補發(fā)斷點后的所有數(shù)據(jù)，避免數(shù)據(jù)丟失。

?

4. 事件流流程圖

?

2.3、應用場景

SSE 適用于服務器需主動向客戶端單向推送數(shù)據(jù)的場景，典型案例包括：

?AI智能助手：SSE 支持 AI 助手的流式輸出，以 “打字機” 效果逐字逐句呈現(xiàn)給用戶，提升用戶體驗，增強用戶與 AI 助手的交互感 。

?實時通知系統(tǒng)：社交應用的消息提醒（“收到新評論”），服務器可通過 SSE 實時推送通知，無需客戶端頻繁輪詢。

?日志 / 狀態(tài)實時展示：如后端任務執(zhí)行日志（部署進度、測試報告）、CI/CD 流水線狀態(tài)，服務器可實時推送日志片段，客戶端實時展示（類似終端輸出）。

?新聞 / 資訊推送：如實時新聞客戶端、股票資訊，服務器在有新內容（突發(fā)新聞、股價變動）時，通過 SSE 立即推送給訂閱用戶。

?監(jiān)控數(shù)據(jù)展示：如服務器 CPU 使用率、網(wǎng)絡流量等監(jiān)控指標，每秒 / 每分鐘推送一次更新，客戶端實時繪制監(jiān)控曲線。

?多人協(xié)作中的狀態(tài)同步：如在線文檔的 “他人正在編輯” 狀態(tài)提示，服務器可通過 SSE 向所有協(xié)作者推送當前編輯者的操作狀態(tài)。

?

三、WebRTC

3.1、核心概念

WebRTC（Web Real-Time Communication，網(wǎng)頁實時通信）是一項瀏覽器原生支持的實時通信技術標準，允許瀏覽器之間直接建立點對點（P2P）連接，實現(xiàn)音視頻通話、數(shù)據(jù)傳輸?shù)葘崟r交互，無需依賴第三方插件或額外軟件。

WebRTC 的核心目標是打破傳統(tǒng)實時通信對中間服務器的強依賴，讓瀏覽器之間能夠直接傳輸數(shù)據(jù)（音視頻、文本、文件等），其關鍵特性包括：

?點對點通信：數(shù)據(jù)主要在客戶端之間直接傳輸（僅信號協(xié)商需服務器參與），減少延遲和服務器帶寬壓力；

?原生瀏覽器支持：無需安裝插件，通過 JavaScript API 即可調用（如getUserMedia捕獲音視頻、RTCPeerConnection建立連接）；

?實時性強：基于 UDP 協(xié)議傳輸（部分場景降級為 TCP），延遲可低至 100-200 毫秒，滿足實時交互需求；

?安全性內置：所有數(shù)據(jù)強制加密傳輸（通過 SRTP 協(xié)議），防止竊聽和篡改。

3.2、原理介紹

WebRTC 的工作流程可分為信號協(xié)商、P2P 連接建立和媒體流傳輸三個核心階段，其中 “信號協(xié)商” 需借助服務器，而實際數(shù)據(jù)傳輸則在客戶端之間直接進行。

1. 信號協(xié)商（Signaling）：發(fā)現(xiàn)與連接準備

瀏覽器（客戶端）無法直接知道對方的網(wǎng)絡位置（IP 地址、端口），需通過 “信號服務器” 交換連接所需的元數(shù)據(jù)（如網(wǎng)絡信息、媒體能力）：

?交換的核心信息：

?SDP（Session Description Protocol）：描述本地媒體能力（如支持的音視頻編碼格式、分辨率、采樣率等），分為 “offer”（發(fā)起方提議）和 “answer”（接收方應答）；

?ICE 候選地址（ICE Candidate）：包含本地網(wǎng)絡可被訪問的 IP 地址和端口（需穿透 NAT 網(wǎng)絡地址轉換）。

?流程示例：

?客戶端 A 生成 SDP offer 并通過信號服務器發(fā)送給客戶端 B；

?客戶端 B 收到 offer 后，生成 SDP answer 并通過信號服務器返回給 A；

?雙方分別收集自身的 ICE 候選地址（如本地局域網(wǎng)地址、NAT 轉換后的公網(wǎng)地址），并通過信號服務器互相發(fā)送；

?雙方根據(jù)收到的 SDP 和 ICE 信息，確定最優(yōu)通信路徑。

2. P2P 連接建立：穿透 NAT 與防火墻

由于多數(shù)設備處于 NAT（網(wǎng)絡地址轉換）或防火墻后，直接建立 P2P 連接需解決 “地址可達性” 問題，WebRTC 通過ICE（Interactive Connectivity Establishment）協(xié)議實現(xiàn)：

?ICE 工作原理：

?首先嘗試 “主機候選地址”（本地局域網(wǎng) IP），若雙方在同一局域網(wǎng)，直接建立連接；

?若失敗，嘗試 “服務器反射候選地址”（通過 STUN 服務器獲取 NAT 轉換后的公網(wǎng)地址）；

?若仍失?。ㄈ鐕栏駥ΨQ NAT 環(huán)境），則通過 TURN 服務器中轉數(shù)據(jù)（作為最后的 fallback 方案）。

?關鍵服務器：

?STUN 服務器：幫助設備獲取自身的公網(wǎng) IP 和端口（用于 NAT 穿透）；

?TURN 服務器：在 P2P 連接失敗時，作為中繼服務器轉發(fā)數(shù)據(jù)（確保通信不中斷，但增加延遲）。

3. 媒體流傳輸：實時音視頻與數(shù)據(jù)交互

連接建立后，WebRTC 通過兩套核心 API 實現(xiàn)數(shù)據(jù)傳輸：

?媒體流傳輸（RTCPeerConnection）：

?客戶端通過getUserMediaAPI 捕獲攝像頭、麥克風數(shù)據(jù)，生成MediaStream（媒體流）；

?通過RTCPeerConnection將媒體流編碼（如 H.264、VP8 視頻編碼，OPUS 音頻編碼）后，通過 RTP（實時傳輸協(xié)議）發(fā)送給對方；

?接收方解碼后，通過

或 標簽播放實時音視頻。

?數(shù)據(jù)通道（RTCDataChannel）：

?除音視頻外，WebRTC 支持通過RTCDataChannel傳輸任意二進制或文本數(shù)據(jù)（如聊天消息、文件、游戲控制指令）；

?數(shù)據(jù)通道支持可靠傳輸（類似 TCP，保證數(shù)據(jù)有序、不丟失）和非可靠傳輸（類似 UDP，低延遲但可能丟包），可按需配置。

3.3、應用場景

WebRTC 適用于需要低延遲、點對點實時交互的場景，尤其在音視頻通信領域應用廣泛：

?實時音視頻通話：如網(wǎng)頁版視頻會議（騰訊會議網(wǎng)頁版）、在線問診（醫(yī)生與患者視頻溝通）、遠程面試系統(tǒng)等，WebRTC 可提供 100-200ms 低延遲的音視頻傳輸。

?屏幕共享與遠程協(xié)助：如在線教育中的老師屏幕共享、遠程辦公中的技術支持（協(xié)助操作對方電腦），通過getDisplayMediaAPI 捕獲屏幕流并實時傳輸。

?實時互動直播：如直播平臺的連麥功能（主播與觀眾實時互動）、在線課堂的師生互動，WebRTC 可支持多人間的低延遲音視頻交互。

?瀏覽器端 P2P 文件傳輸：如基于網(wǎng)頁的文件共享工具，用戶可直接向其他在線用戶發(fā)送文件，無需通過服務器中轉（速度取決于雙方帶寬）。

?實時游戲：如多人文本冒險游戲、簡單實時對戰(zhàn)游戲，通過RTCDataChannel傳輸玩家操作指令，實現(xiàn)低延遲同步。

?物聯(lián)網(wǎng)設備實時監(jiān)控：如通過網(wǎng)頁實時查看家用攝像頭畫面、工業(yè)設備監(jiān)控視頻，WebRTC 可直接接收設備推送的音視頻流。

?

四、輪詢

輪詢是 Web 實時通信的 “早期方案”，核心邏輯是客戶端通過周期性發(fā)送 HTTP 請求，主動從服務器獲取最新數(shù)據(jù)，本質是利用 HTTP 短連接模擬 “實時” 效果。核心優(yōu)勢是兼容性強、實現(xiàn)簡單，核心劣勢是服務器開銷大、實時性有限。隨著 WebSocket 和 SSE 的普及，輪詢已逐漸退出主流實時場景，但在兼容性要求極高或低成本臨時需求中，仍是一種可落地的選擇（這里不再詳細介紹）。實際開發(fā)中，優(yōu)先選擇 WebSocket/SSE，僅在必要時考慮輪詢。

五、技術對比與選型建議

WebSocket、SSE、WebRTC 和輪詢是 Web 端實時通信的四大核心技術，以下從技術特性、優(yōu)缺點、適用場景三個維度進行對比分析：

5.1、技術特性對比

5.2、核心優(yōu)缺點分析

?2.1. WebSocket

?優(yōu)點：全雙工通信、低延遲、支持任意數(shù)據(jù)類型，適合高頻雙向交互；

?缺點：服務器需維護長連接（高并發(fā)場景需負載均衡），實現(xiàn)復雜度高于 SSE / 輪詢。

?2.2. SSE

?優(yōu)點：服務器單向推送場景下實現(xiàn)簡單（客戶端EventSource開箱即用），自動重連，服務器資源消耗低；

?缺點：僅支持單向通信，不支持二進制原生傳輸，IE 完全不兼容。

?2.3. WebRTC

?優(yōu)點：點對點通信（減少服務器帶寬壓力），音視頻傳輸延遲極低，支持文件等二進制數(shù)據(jù)；

?缺點：實現(xiàn)復雜（需處理 NAT 穿透、信號協(xié)商），瀏覽器兼容性細節(jié)差異大，依賴 STUN/TURN 服務器。

?2.4. 輪詢

?優(yōu)點：實現(xiàn)最簡單，兼容性 100%（支持所有瀏覽器和服務器）；

?缺點：實時性差（短輪詢延遲高，長輪詢服務器壓力大），帶寬浪費嚴重。

5.3、適用場景對比

?

六、一些進階問題

6.1、高并發(fā)與擴展性問題

當連接數(shù)達到數(shù)萬甚至數(shù)十萬級時，單臺服務器難以承載，需解決 “連接瓶頸” 和 “負載均衡” 問題。

6.2、數(shù)據(jù)安全與身份認證

實時通信涉及用戶敏感數(shù)據(jù)（如聊天內容、音視頻），需解決 “身份驗證” 和 “數(shù)據(jù)加密” 問題：通過身份認證機制和數(shù)據(jù)加密傳輸解決。

6.3、網(wǎng)絡穩(wěn)定性與連接可靠性

弱網(wǎng)環(huán)境（如 4G 切換、WiFi 信號差）會導致連接中斷或數(shù)據(jù)丟失，需通過 “?；顧C制” 和 “重連策略” 保障可靠性：

?連接?；顧C制

?WebSocket：實現(xiàn) Ping/Pong 心跳（服務器定時發(fā)Ping，客戶端回Pong），超時未響應則判定連接失效：

?SSE：服務器定期發(fā)送注釋幀（:nn）作為心跳，防止長連接被網(wǎng)關超時關閉。

?WebRTC：通過RTCPeerConnection的oniceconnectionstatechange監(jiān)聽連接狀態(tài)，狀態(tài)為failed時觸發(fā)重連。

?長輪詢：設置合理超時時間（如 30 秒），客戶端收到超時響應后立即重試，避免連接長期閑置。

?智能重連策略

?指數(shù)退避重連：重連間隔按指數(shù)增長（1s → 2s → 4s → 最大 30s），避免網(wǎng)絡恢復時的請求風暴

?網(wǎng)絡感知重連：通過navigator.connection.effectiveType判斷網(wǎng)絡類型（如 2g/3g/4g），弱網(wǎng)環(huán)境下延長重連間隔。

?數(shù)據(jù)補發(fā)機制：

?WebSocket/SSE：重連后通過Last-Event-ID或自定義偏移量（如消息 ID）向服務器請求遺漏數(shù)據(jù)；

?WebRTC：關鍵數(shù)據(jù)（如游戲操作）啟用可靠傳輸模式（ordered: true），確保重連后補發(fā)。

6.4、跨域與瀏覽器兼容性

不同技術的跨域處理和瀏覽器支持存在差異，需針對性兼容：

?跨域通信處理

?WebSocket：支持跨域，服務器需在握手階段返回Access-Control-Allow-Origin: *（或指定域名），并驗證Origin頭防止惡意請求。

?SSE：同 WebSocket，依賴 HTTP 跨域頭（Access-Control-*），且EventSource僅支持 GET 請求，無法攜帶自定義頭（需通過 URL 參數(shù)傳遞認證信息）。（在微信小程序中有版本和平臺的兼容問題，這里暫不敘述）

?WebRTC：信令服務器需配置跨域，媒體流傳輸本身不涉及跨域（P2P 直連）。

?輪詢：通過 CORS 或 JSONP（僅 GET）處理跨域，同普通 HTTP 請求。

?瀏覽器兼容性適配

?WebSocket：IE 不支持，需用Socket.IO等庫自動降級為長輪詢（兼容 IE 8+）。

?SSE：IE 完全不支持，可通過fetch+ 長輪詢模擬 SSE 功能（如sse.js庫）。

?WebRTC：不同瀏覽器對編碼格式支持不同（如 Safari 不支持 VP8），需在 SDP 協(xié)商時指定兼容編碼（如 H.264）；移動端需處理攝像頭權限請求差異。

?輪詢：無兼容性問題，但需注意老舊瀏覽器對fetch的支持（可降級為XMLHttpRequest）

七、其它

?WebSocket：https://www.w3.org/TR/websockets/，介紹了 WebSocket API 的相關內容。

?SSE：https://developer.mozilla.org/en-US/docs/Web/API/EventSource，對 SSE 的使用方法和相關 API 進行了詳細說明。

?WebRTC：https://www.w3.org/TR/webrtc/，定義了一組 ECMAScript API，允許媒體和通用應用數(shù)據(jù)在瀏覽器或設備之間進行實時發(fā)送和接收。

審核編輯 黃宇