在 Web 開發中，實時通信技術的核心目標是實現客户端（Browser）與服務器之間低延遲、雙向 / 單向的動態數據交互，而非傳統 HTTP 的 “請求 - 響應” 模式。以下是 Web 端最常用的實時通信技術，從概念、原理特點、適用場景、對比選型進行詳細解析。

一、WebSocket

1.1、核心概念

WebSocket 是 Web 端實時通信的 “基礎設施”，通過全雙工長連接和輕量幀傳輸，解決了 HTTP 單向短連接的侷限性，成為即時通訊、協作工具、實時監控等場景的首選技術。其與 HTTP 並非替代關係，而是互補 ——HTTP 適用於 “請求 - 響應” 場景（如頁面加載），WebSocket 適用於 “雙向實時交互” 場景。

1.2、原理介紹

WebSocket 的工作流程分為握手協議升級、數據幀傳輸和連接管理三個階段：

1. 握手階段：基於 HTTP 升級協議

WebSocket 連接的建立依賴 HTTP 協議完成 “握手”，本質是將 HTTP 連接升級為 WebSocket 連接；

•客户端發起請求：發送特殊的 HTTP GET 請求，聲明協議升級意向：

GET /ws HTTP/1.1
Host: example.com
Connection: Upgrade  # 告訴服務端：這是一個“升級請求”，不要按普通 HTTP 處理
Upgrade: websocket   # 核心：請求升級到 WebSocket 協議
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  # 隨機字符串，用於服務端驗證（防偽造請求）
Sec-WebSocket-Version: 13  # 客户端支持的 WebSocket 版本（必須是 13，現代標準）

•服務器響應確認：驗證請求後返回101 Switching Protocols響應，確認升級：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  # 由客户端的 Sec-WebSocket-Key 計算而來（驗證身份）

•連接建立：握手成功後，底層 TCP 連接被複用，後續通信脱離 HTTP 協議。

2. 數據傳輸：基於幀結構的高效通信

WebSocket 採用二進制幀（Frame） 格式傳輸數據，幀結構僅包含 “操作碼（Opcode）、掩碼、數據長度、數據載荷” 等核心字段（頭部僅 2-14 字節），無 HTTP 頭冗餘，傳輸效率極高：

•操作碼：區分數據類型（0x01文本數據、0x02二進制數據、0x08斷開連接）；

•掩碼：客户端發送數據必須加掩碼（防止代理緩存污染），服務器返回數據無需加掩碼；

•優勢：支持文本、圖片、視頻流等任意數據類型，雙向通信延遲可低至毫秒級。

3. 連接管理：保活與斷開

•心跳保活：為避免 TCP 連接因 “長時間無數據” 被網絡設備（如路由器）斷開，WebSocket 內置Ping/Pong 心跳機制：服務器定期發送Ping幀，客户端必須回傳Pong幀；若超時未收到Pong，判定連接失效並主動斷開。；

•主動斷開：任何一方發送Opcode=0x08的關閉幀，雙方確認後關閉 TCP 連接。

4.為什麼在握手階段需要升級協議

WebSocket 並非完全脱離 HTTP，而是藉助 HTTP 協議的 “握手流程” 完成 “協議切換”—— 通過一次 HTTP 請求，讓客户端和服務端達成共識：“接下來我們用 WebSocket 協議通信，不再遵循 HTTP 規則”。

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

•兼容現有網絡環境：所有瀏覽器、網關、代理服務器都支持 HTTP；如果 WebSocket 設計成完全獨立的協議，可能被現有網絡設備攔截（無法穿透代理 / 防火牆）。

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

4.2、WebSocket 和 HTTP 的關係



1.3、應用場景

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

•即時通訊工具： 如網頁版微信、企業微信、在線客服系統等，需實時收發消息，WebSocket 可保證消息更實時。

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

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

•在線遊戲： 網頁小遊戲（如貪吃蛇聯機版）需要實時同步玩家操作和遊戲狀態，WebSocket 可滿足低延遲需求。

•實時監控系統： 如物聯網設備監控（温度、濕度實時數據）、服務器性能監控，需持續接收設備 / 服務器推送的狀態數據。

•彈幕系統： 視頻網站的實時彈幕， thousands 級用户同時發送和接收彈幕，WebSocket 可支撐高併發推送。



二、Server-Sent Events（SSE）

2.1、核心概念

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

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

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

•關鍵特性：

◦單向通信：僅支持服務器向客户端推送數據，客户端無法通過 SSE 向服務器發送數據（需配合 HTTP 或 WebSocket 實現雙向交互）；

◦長連接：一次連接建立後持續保持，避免短連接的反覆握手開銷；

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

◦文本流：數據以 UTF-8 文本流格式傳輸，二進制數據需編碼後發送。

2.2、原理介紹

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

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

客户端通過瀏覽器原生的EventSourceAPI 發起連接請求，服務器返回符合 SSE 規範的響應頭，建立持久化連接：

•客户端請求：

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

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

•服務器響應頭：

HTTP/1.1200OK
Content-Type:text/event-stream; charset=utf-8  # 核心：標識為 SSE 流
Cache-Control:no-cache  # 禁止緩存，確保客户端接收實時數據
Connection:keep-alive   # 保持 HTTP 長連接
Access-Control-Allow-Origin:*  # 跨域配置（如需）

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



2. 數據推送：基於規範的文本流格式

服務器通過 HTTP 長連接持續向客户端發送 “事件”，每個事件需遵循嚴格的文本格式，以\n\n作為結束符：

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

# 格式 2：自定義事件名（客户端通過 addEventListener 接收）
event: orderStatus  # 事件名（如“訂單狀態更新”）
id: 10086           # 事件 ID（用於重連時定位斷點）
data: 訂單已發貨\n\n

# 格式 3：心跳保活（客户端忽略，僅維持連接）
: 這是註釋，無實際數據，防止長連接超時\n\n



3. 重連機制：自動恢復連接與數據補發

SSE 原生支持斷線重連，無需手動實現：

•自動重連：若連接意外斷開（如網絡波動），客户端會在 3 秒後自動重試，並逐漸增加間隔（最多 30 秒）；

•數據補發：重連時，客户端會在請求頭中攜帶Last-Event-ID: 1000000（最後接收的事件 ID），服務器可基於此補發斷點後的所有數據，避免數據丟失。



4. 事件流流程圖

2.3、 應用場景

SSE 適用於服務器需主動向客户端單向推送數據的場景，典型案例包括：

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

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

•日誌 / 狀態實時展示： 如後端任務執行日誌（部署進度、測試報告）、CI/CD 流水線狀態，服務器可實時推送日誌片段，客户端實時展示（類似終端輸出）。

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

•監控數據展示： 如服務器 CPU 使用率、網絡流量等監控指標，每秒 / 每分鐘推送一次更新，客户端實時繪製監控曲線。

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



三、WebRTC

3.1、核心概念

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

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

•點對點通信：數據主要在客户端之間直接傳輸（僅信號協商需服務器參與），減少延遲和服務器帶寬壓力；

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

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

•安全性內置：所有數據強制加密傳輸（通過 SRTP 協議），防止竊聽和篡改。

3.2、原理介紹

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

1. 信號協商（Signaling）：發現與連接準備

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

•交換的核心信息：

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

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

•流程示例：

◦客户端 A 生成 SDP offer 並通過信號服務器發送給客户端 B；

◦客户端 B 收到 offer 後，生成 SDP answer 並通過信號服務器返回給 A；

◦雙方分別收集自身的 ICE 候選地址（如本地局域網地址、NAT 轉換後的公網地址），並通過信號服務器互相發送；

◦雙方根據收到的 SDP 和 ICE 信息，確定最優通信路徑。

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

由於多數設備處於 NAT（網絡地址轉換）或防火牆後，直接建立 P2P 連接需解決 “地址可達性” 問題，WebRTC 通過ICE（Interactive Connectivity Establishment）協議實現：

•ICE 工作原理：

◦首先嚐試 “主機候選地址”（本地局域網 IP），若雙方在同一局域網，直接建立連接；

◦若失敗，嘗試 “服務器反射候選地址”（通過 STUN 服務器獲取 NAT 轉換後的公網地址）；

◦若仍失敗（如嚴格對稱 NAT 環境），則通過 TURN 服務器中轉數據（作為最後的 fallback 方案）。

•關鍵服務器：

◦STUN 服務器：幫助設備獲取自身的公網 IP 和端口（用於 NAT 穿透）；

◦TURN 服務器：在 P2P 連接失敗時，作為中繼服務器轉發數據（確保通信不中斷，但增加延遲）。

3. 媒體流傳輸：實時音視頻與數據交互

連接建立後，WebRTC 通過兩套核心 API 實現數據傳輸：

•媒體流傳輸（RTCPeerConnection） ：

◦客户端通過getUserMediaAPI 捕獲攝像頭、麥克風數據，生成MediaStream（媒體流）；

◦通過RTCPeerConnection將媒體流編碼（如 H.264、VP8 視頻編碼，OPUS 音頻編碼）後，通過 RTP（實時傳輸協議）發送給對方；

◦接收方解碼後，通過<video>或<audio>標籤播放實時音視頻。

•數據通道（RTCDataChannel） ：

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

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

3.3、應用場景

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

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

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

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

•瀏覽器端 P2P 文件傳輸： 如基於網頁的文件共享工具，用户可直接向其他在線用户發送文件，無需通過服務器中轉（速度取決於雙方帶寬）。

•實時遊戲： 如多人文本冒險遊戲、簡單實時對戰遊戲，通過RTCDataChannel傳輸玩家操作指令，實現低延遲同步。

•物聯網設備實時監控： 如通過網頁實時查看家用攝像頭畫面、工業設備監控視頻，WebRTC 可直接接收設備推送的音視頻流。



四、輪詢

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

五、技術對比與選型建議

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

5.1、技術特性對比

5.2、核心優缺點分析

•2.1. WebSocket

◦優點：全雙工通信、低延遲、支持任意數據類型，適合高頻雙向交互；

◦缺點：服務器需維護長連接（高併發場景需負載均衡），實現複雜度高於 SSE / 輪詢。

•2.2. SSE

◦優點：服務器單向推送場景下實現簡單（客户端EventSource開箱即用），自動重連，服務器資源消耗低；

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

•2.3. WebRTC

◦優點：點對點通信（減少服務器帶寬壓力），音視頻傳輸延遲極低，支持文件等二進制數據；

◦缺點：實現複雜（需處理 NAT 穿透、信號協商），瀏覽器兼容性細節差異大，依賴 STUN/TURN 服務器。

•2.4. 輪詢

◦優點：實現最簡單，兼容性 100%（支持所有瀏覽器和服務器）；

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

5.3、適用場景對比



六、一些進階問題

6.1、高併發與擴展性問題

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

6.2、數據安全與身份認證

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

6.3、網絡穩定性與連接可靠性

弱網環境（如 4G 切換、WiFi 信號差）會導致連接中斷或數據丟失，需通過 “保活機制” 和 “重連策略” 保障可靠性：

•連接保活機制

◦WebSocket：實現 Ping/Pong 心跳（服務器定時發Ping，客户端回Pong），超時未響應則判定連接失效：

◦SSE：服務器定期發送註釋幀（:\n\n）作為心跳，防止長連接被網關超時關閉。

◦WebRTC：通過RTCPeerConnection的oniceconnectionstatechange監聽連接狀態，狀態為failed時觸發重連。

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

•智能重連策略

◦指數退避重連：重連間隔按指數增長（1s → 2s → 4s → 最大 30s），避免網絡恢復時的請求風暴

◦網絡感知重連：通過navigator.connection.effectiveType判斷網絡類型（如 2g/3g/4g），弱網環境下延長重連間隔。

◦數據補發機制：

▪WebSocket/SSE：重連後通過Last-Event-ID或自定義偏移量（如消息 ID）向服務器請求遺漏數據；

▪WebRTC：關鍵數據（如遊戲操作）啓用可靠傳輸模式（ordered: true），確保重連後補發。

6.4、跨域與瀏覽器兼容性

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

•跨域通信處理

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

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

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

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

•瀏覽器兼容性適配

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

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

◦WebRTC：不同瀏覽器對編碼格式支持不同（如 Safari 不支持 VP8），需在 SDP 協商時指定兼容編碼（如 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，允許媒體和通用應用數據在瀏覽器或設備之間進行實時發送和接收。