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

一、WebSocket

1.1、核心概念

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

1.2、原理介紹

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

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

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

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

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

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

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  # 由客戶端的 Sec-WebSocket-Key 計算而來（驗(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ù)長度、數(shù)據(jù)載荷” 等核心字段（頭部僅 2-14 字節(jié)），無 HTTP 頭冗余，傳輸效率極高：

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

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

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

3. 連接管理：?；钆c斷開

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

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

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

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

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

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

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

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

?

?

1.3、應(yīng)用場景

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

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

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

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

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

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

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

?

二、Server-Sent Events（SSE）

2.1、核心概念

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

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

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

?關(guān)鍵特性：

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

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

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

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

2.2、原理介紹

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

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

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

?客戶端請求：

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

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

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

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

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

?

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

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

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

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

# 格式 3：心跳?；睿蛻舳撕雎裕瑑H維持連接）
: 這是注釋，無實(shí)際數(shù)據(jù)，防止長連接超時nn

?

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

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

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

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

?

4. 事件流流程圖

?

2.3、應(yīng)用場景

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

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

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

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

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

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

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

?

三、WebRTC

3.1、核心概念

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

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

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

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

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

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

3.2、原理介紹

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

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

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

?交換的核心信息：

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

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

?流程示例：

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

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

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

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

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

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

?ICE 工作原理：

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

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

?若仍失?。ㄈ鐕?yán)格對稱 NAT 環(huán)境），則通過 TURN 服務(wù)器中轉(zhuǎn)數(shù)據(jù)（作為最后的 fallback 方案）。

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

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

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

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

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

?媒體流傳輸（RTCPeerConnection）：

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

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

?接收方解碼后，通過

或 標(biāo)簽播放實(shí)時音視頻。

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

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

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

3.3、應(yīng)用場景

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

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

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

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

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

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

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

?

四、輪詢

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

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

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

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

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

?2.1. WebSocket

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

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

?2.2. SSE

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

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

?2.3. WebRTC

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

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

?2.4. 輪詢

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

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

5.3、適用場景對比

?

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

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

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

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

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

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

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

?連接?；顧C(jī)制

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

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

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

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

?智能重連策略

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

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

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

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

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

6.4、跨域與瀏覽器兼容性

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

?跨域通信處理

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

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

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

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

?瀏覽器兼容性適配

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

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

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

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

七、其它

?WebSocket：https://www.w3.org/TR/websockets/，介紹了 WebSocket API 的相關(guān)內(nèi)容。

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

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

審核編輯 黃宇