常用Web 實(shí)時(shí)通信技術(shù)：原理+選型，一篇通關(guān)

作者：盧旭 2025-10-30 01:33:00

WebSocket 是 Web 端實(shí)時(shí)通信的 “基礎(chǔ)設(shè)施”，通過(guò)全雙工長(zhǎng)連接和輕量幀傳輸，解決了 HTTP 單向短連接的局限性，成為即時(shí)通訊、協(xié)作工具、實(shí)時(shí)監(jiān)控等場(chǎng)景的首選技術(shù)。

在 Web 開(kāi)發(fā)中，實(shí)時(shí)通信技術(shù)的核心目標(biāo)是實(shí)現(xiàn)客戶(hù)端（Browser）與服務(wù)器之間低延遲、雙向 / 單向的動(dòng)態(tài)數(shù)據(jù)交互，而非傳統(tǒng) HTTP 的 “請(qǐng)求 - 響應(yīng)” 模式。以下是 Web 端最常用的實(shí)時(shí)通信技術(shù)，從概念、原理特點(diǎn)、適用場(chǎng)景、對(duì)比選型進(jìn)行詳細(xì)解析。

一、WebSocket

1.1、核心概念

WebSocket 是 Web 端實(shí)時(shí)通信的 “基礎(chǔ)設(shè)施”，通過(guò)全雙工長(zhǎng)連接和輕量幀傳輸，解決了 HTTP 單向短連接的局限性，成為即時(shí)通訊、協(xié)作工具、實(shí)時(shí)監(jiān)控等場(chǎng)景的首選技術(shù)。其與 HTTP 并非替代關(guān)系，而是互補(bǔ) ——HTTP 適用于 “請(qǐng)求 - 響應(yīng)” 場(chǎng)景（如頁(yè)面加載），WebSocket 適用于 “雙向?qū)崟r(shí)交互” 場(chǎng)景。

1.2、原理介紹

WebSocket 的工作流程分為握手協(xié)議升級(jí)、數(shù)據(jù)幀傳輸和連接管理三個(gè)階段：

1. 握手階段：基于 HTTP 升級(jí)協(xié)議

WebSocket 連接的建立依賴(lài) HTTP 協(xié)議完成 “握手”，本質(zhì)是將 HTTP 連接升級(jí)為 WebSocket 連接；

?客戶(hù)端發(fā)起請(qǐng)求：發(fā)送特殊的 HTTP GET 請(qǐng)求，聲明協(xié)議升級(jí)意向：

GET /ws HTTP/1.1
Host: example.com
Connection: Upgrade  # 告訴服務(wù)端：這是一個(gè)“升級(jí)請(qǐng)求”，不要按普通 HTTP 處理
Upgrade: websocket   # 核心：請(qǐng)求升級(jí)到 WebSocket 協(xié)議
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  # 隨機(jī)字符串，用于服務(wù)端驗(yàn)證（防偽造請(qǐng)求）
Sec-WebSocket-Version: 13  # 客戶(hù)端支持的 WebSocket 版本（必須是 13，現(xiàn)代標(biāo)準(zhǔn)）

?服務(wù)器響應(yīng)確認(rèn)：驗(yàn)證請(qǐng)求后返回101 Switching Protocols響應(yīng)，確認(rèn)升級(jí)：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  # 由客戶(hù)端的 Sec-WebSocket-Key 計(jì)算而來(lái)（驗(yàn)證身份）

?連接建立：握手成功后，底層 TCP 連接被復(fù)用，后續(xù)通信脫離 HTTP 協(xié)議。

2. 數(shù)據(jù)傳輸：基于幀結(jié)構(gòu)的高效通信

WebSocket 采用二進(jìn)制幀（Frame）格式傳輸數(shù)據(jù)，幀結(jié)構(gòu)僅包含 “操作碼（Opcode）、掩碼、數(shù)據(jù)長(zhǎng)度、數(shù)據(jù)載荷” 等核心字段（頭部?jī)H 2-14 字節(jié)），無(wú) HTTP 頭冗余，傳輸效率極高：

?操作碼：區(qū)分?jǐn)?shù)據(jù)類(lèi)型（0x01文本數(shù)據(jù)、0x02二進(jìn)制數(shù)據(jù)、0x08斷開(kāi)連接）；

?掩碼：客戶(hù)端發(fā)送數(shù)據(jù)必須加掩碼（防止代理緩存污染），服務(wù)器返回?cái)?shù)據(jù)無(wú)需加掩碼；

?優(yōu)勢(shì)：支持文本、圖片、視頻流等任意數(shù)據(jù)類(lèi)型，雙向通信延遲可低至毫秒級(jí)。

3. 連接管理：保活與斷開(kāi)

?心跳保活：為避免 TCP 連接因 “長(zhǎng)時(shí)間無(wú)數(shù)據(jù)” 被網(wǎng)絡(luò)設(shè)備（如路由器）斷開(kāi)，WebSocket 內(nèi)置Ping/Pong 心跳機(jī)制：服務(wù)器定期發(fā)送Ping幀，客戶(hù)端必須回傳Pong幀；若超時(shí)未收到Pong，判定連接失效并主動(dòng)斷開(kāi)。；

?主動(dòng)斷開(kāi)：任何一方發(fā)送Opcode=0x08的關(guān)閉幀，雙方確認(rèn)后關(guān)閉 TCP 連接。

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

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

4.1.這個(gè)升級(jí)過(guò)程的核心價(jià)值是：

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

?低成本建立 “長(zhǎng)連接共識(shí)”：利用 HTTP 握手的 “請(qǐng)求 - 響應(yīng)” 流程，讓雙方快速確認(rèn) “支持 WebSocket”，避免額外的協(xié)議協(xié)商開(kāi)銷(xiāo)。

4.2、WebSocket 和 HTTP 的關(guān)系

4.3、應(yīng)用場(chǎng)景

WebSocket 適用于需要低延遲、雙向?qū)崟r(shí)通信的場(chǎng)景，典型案例包括：

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

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

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

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

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

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

二、Server-Sent Events（SSE）

2.1、核心概念

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

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

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

?關(guān)鍵特性：

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

長(zhǎng)連接：一次連接建立后持續(xù)保持，避免短連接的反復(fù)握手開(kāi)銷(xiāo)；

自動(dòng)重連：連接意外斷開(kāi)時(shí)，客戶(hù)端會(huì)自動(dòng)重試連接（默認(rèn)間隔 3 秒）；

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

2.2、原理介紹

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

1. 連接建立：基于 HTTP 的長(zhǎng)連接初始化

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

?客戶(hù)端請(qǐng)求：

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

瀏覽器會(huì)自動(dòng)發(fā)送 HTTP 請(qǐng)求，攜帶特殊頭信息（如
Accept: text/event-stream

?服務(wù)器響應(yīng)頭：

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

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

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

服務(wù)器通過(guò) HTTP 長(zhǎng)連接持續(xù)向客戶(hù)端發(fā)送 “事件”，每個(gè)事件需遵循嚴(yán)格的文本格式，以\n\n作為結(jié)束符：

# 格式 1：默認(rèn)事件（客戶(hù)端通過(guò) onmessage 接收）
data: 您有一條新消息\n
data: 內(nèi)容：Hello World\n\n  # 多行 data 會(huì)合并為一條消息
# 格式 2：自定義事件名（客戶(hù)端通過(guò) addEventListener 接收）
event: orderStatus  # 事件名（如“訂單狀態(tài)更新”）
id: 10086           # 事件 ID（用于重連時(shí)定位斷點(diǎn)）
data: 訂單已發(fā)貨\n\n
# 格式 3：心跳保活（客戶(hù)端忽略，僅維持連接）
: 這是注釋?zhuān)瑹o(wú)實(shí)際數(shù)據(jù)，防止長(zhǎng)連接超時(shí)\n\n

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

SSE 原生支持?jǐn)嗑€重連，無(wú)需手動(dòng)實(shí)現(xiàn)：

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

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

4. 事件流流程圖

2.3、應(yīng)用場(chǎng)景

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

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

?實(shí)時(shí)通知系統(tǒng)：社交應(yīng)用的消息提醒（“收到新評(píng)論”），服務(wù)器可通過(guò) SSE 實(shí)時(shí)推送通知，無(wú)需客戶(hù)端頻繁輪詢(xún)。

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

?新聞 / 資訊推送：如實(shí)時(shí)新聞客戶(hù)端、股票資訊，服務(wù)器在有新內(nèi)容（突發(fā)新聞、股價(jià)變動(dòng)）時(shí)，通過(guò) SSE 立即推送給訂閱用戶(hù)。

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

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

三、WebRTC

3.1、核心概念

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

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

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

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

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

?安全性?xún)?nèi)置：所有數(shù)據(jù)強(qiáng)制加密傳輸（通過(guò) SRTP 協(xié)議），防止竊聽(tīng)和篡改。

3.2、原理介紹

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

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

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

?交換的核心信息：

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

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

?流程示例：

客戶(hù)端 A 生成 SDP offer 并通過(guò)信號(hào)服務(wù)器發(fā)送給客戶(hù)端 B；

客戶(hù)端 B 收到 offer 后，生成 SDP answer 并通過(guò)信號(hào)服務(wù)器返回給 A；

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

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

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

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

?ICE 工作原理：

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

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

若仍失敗（如嚴(yán)格對(duì)稱(chēng) NAT 環(huán)境），則通過(guò) TURN 服務(wù)器中轉(zhuǎn)數(shù)據(jù)（作為最后的 fallback 方案）。

?關(guān)鍵服務(wù)器：

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

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

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

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

?媒體流傳輸（RTCPeerConnection）：

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

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

接收方解碼后，通過(guò)<video>或<audio>標(biāo)簽播放實(shí)時(shí)音視頻。

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

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

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

3.3、應(yīng)用場(chǎng)景

WebRTC 適用于需要低延遲、點(diǎn)對(duì)點(diǎn)實(shí)時(shí)交互的場(chǎng)景，尤其在音視頻通信領(lǐng)域應(yīng)用廣泛：

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

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

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

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

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

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

四、輪詢(xún)

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

五、技術(shù)對(duì)比與選型建議

WebSocket、SSE、WebRTC 和輪詢(xún)是 Web 端實(shí)時(shí)通信的四大核心技術(shù)，以下從技術(shù)特性、優(yōu)缺點(diǎn)、適用場(chǎng)景三個(gè)維度進(jìn)行對(duì)比分析：

5.1、技術(shù)特性對(duì)比

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

5?2.1. WebSocket

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

缺點(diǎn)：服務(wù)器需維護(hù)長(zhǎng)連接（高并發(fā)場(chǎng)景需負(fù)載均衡），實(shí)現(xiàn)復(fù)雜度高于 SSE / 輪詢(xún)。

5?2.2. SSE

優(yōu)點(diǎn)：服務(wù)器單向推送場(chǎng)景下實(shí)現(xiàn)簡(jiǎn)單（客戶(hù)端EventSource開(kāi)箱即用），自動(dòng)重連，服務(wù)器資源消耗低；

缺點(diǎn)：僅支持單向通信，不支持二進(jìn)制原生傳輸，IE 完全不兼容。

5?2.3. WebRTC

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

缺點(diǎn)：實(shí)現(xiàn)復(fù)雜（需處理 NAT 穿透、信號(hào)協(xié)商），瀏覽器兼容性細(xì)節(jié)差異大，依賴(lài) STUN/TURN 服務(wù)器。

5?2.4. 輪詢(xún)

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

缺點(diǎn)：實(shí)時(shí)性差（短輪詢(xún)延遲高，長(zhǎng)輪詢(xún)服務(wù)器壓力大），帶寬浪費(fèi)嚴(yán)重。

5.3、適用場(chǎng)景對(duì)比

六、一些進(jìn)階問(wèn)題

6.1、高并發(fā)與擴(kuò)展性問(wèn)題

當(dāng)連接數(shù)達(dá)到數(shù)萬(wàn)甚至數(shù)十萬(wàn)級(jí)時(shí)，單臺(tái)服務(wù)器難以承載，需解決 “連接瓶頸” 和 “負(fù)載均衡” 問(wèn)題。

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

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

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

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

?連接保活機(jī)制

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

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

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

長(zhǎng)輪詢(xún)：設(shè)置合理超時(shí)時(shí)間（如 30 秒），客戶(hù)端收到超時(shí)響應(yīng)后立即重試，避免連接長(zhǎng)期閑置。

?智能重連策略

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

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

數(shù)據(jù)補(bǔ)發(fā)機(jī)制：

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

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

6.4、跨域與瀏覽器兼容性

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

?跨域通信處理

WebSocket：支持跨域，服務(wù)器需在握手階段返回Access-Control-Allow-Origin: *（或指定域名），并驗(yàn)證Origin頭防止惡意請(qǐng)求。

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

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

輪詢(xún)：通過(guò) CORS 或 JSONP（僅 GET）處理跨域，同普通 HTTP 請(qǐng)求。

?瀏覽器兼容性適配

WebSocket：IE 不支持，需用Socket.IO等庫(kù)自動(dòng)降級(jí)為長(zhǎng)輪詢(xún)（兼容 IE 8+）。

SSE：IE 完全不支持，可通過(guò)fetch+ 長(zhǎng)輪詢(xún)模擬 SSE 功能（如sse.js庫(kù)）。

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

輪詢(xún)：無(wú)兼容性問(wèn)題，但需注意老舊瀏覽器對(duì)fetch的支持（可降級(jí)為XMLHttpRequest）