這篇文章，我們聊聊 四種實時通信技術(shù)：短輪詢、長輪詢、WebSocket 和 SSE 。

1.短輪詢

瀏覽器 定時（如每秒）向服務(wù)器發(fā)送 HTTP 請求，服務(wù)器立即返回當(dāng)前數(shù)據(jù)（無論是否有更新）。

圖片

• 優(yōu)點：實現(xiàn)簡單，兼容性極佳
• 缺點：高頻請求浪費資源，實時性差（依賴輪詢間隔）
• 延遲：高（取決于輪詢頻率）
• 適用場景：兼容性要求高，延遲不敏感的簡單場景。

筆者職業(yè)生涯印象最深刻的短輪詢應(yīng)用場景是比分直播：

圖片

如圖所示，用戶進入比分直播界面，瀏覽器定時查詢賽事信息（比分變動、黃紅牌等），假如數(shù)據(jù)有變化，則重新渲染頁面。

這種方式實現(xiàn)起來非常簡單可靠，但是頻繁的調(diào)用后端接口，會對后端性能會有影響（主要是 CPU）。同時，因為依賴輪詢間隔，頁面數(shù)據(jù)變化有延遲，用戶體驗并不算太好。

2.長輪詢

瀏覽器發(fā)送 HTTP 請求后，服務(wù)器 掛起連接 直到數(shù)據(jù)更新或超時，返回響應(yīng)后瀏覽器立即發(fā)起新請求。

圖片

• 優(yōu)點：減少無效請求，比短輪詢實時性更好
• 缺點：服務(wù)器需維護掛起連接，高并發(fā)時資源消耗大
• 延遲：中（取決于數(shù)據(jù)更新頻率）
• 適用場景：需要較好實時性且無法用 WebSocket/SSE 的場景（如消息通知）

長輪詢最常見的應(yīng)用場景是：配置中心，我們耳熟能詳?shù)淖灾行?Nacos 、阿波羅都是依賴長輪詢機制。

nacos長輪詢

客戶端發(fā)起請求后，Nacos 服務(wù)端不會立即返回請求結(jié)果，而是將請求掛起等待一段時間，如果此段時間內(nèi)服務(wù)端數(shù)據(jù)變更，立即響應(yīng)客戶端請求，若是一直無變化則等到指定的超時時間后響應(yīng)請求，客戶端重新發(fā)起長輪詢。

3.WebSocket

基于 TCP 的全雙工協(xié)議，通過 HTTP 升級握手（Upgrade: websocket）建立持久連接（雙向?qū)崟r通信）。

image.png

• 優(yōu)點：最低延遲，支持雙向交互，節(jié)省帶寬
• 缺點：實現(xiàn)復(fù)雜，需單獨處理連接狀態(tài)
• 延遲：極低
• 適用場景：聊天室、在線游戲、協(xié)同編輯等 高實時雙向交互 需求

筆者曾經(jīng)服務(wù)于北京一家電商公司，參與直播答題功能的研發(fā)。

圖片

直播答題整體架構(gòu)見下圖：

圖片

TCP 網(wǎng)關(guān)的技術(shù)選型是：Netty、ProtoBuf、WebSocket ，選擇 WebSocket 是因為它支持雙向?qū)崟r通信，同時 Netty 內(nèi)置了 WebSocket 實現(xiàn)類，工程實現(xiàn)起來相對簡單。

4.Server Send Event(SSE)

基于 HTTP 協(xié)議，服務(wù)器可 主動推送 數(shù)據(jù)流（如Content-Type: text/event-stream），瀏覽器通過EventSource API 監(jiān)聽。

圖片

• 優(yōu)點：原生支持?jǐn)嗑€重連，輕量級（HTTP協(xié)議）
• 缺點：單向通信（服務(wù)端--》客戶端），低版本 IE 瀏覽器不支持
• 延遲：低（服務(wù)器可即時推送）
• 適用場景：股票行情、實時日志等 服務(wù)器單向推送 需求。

SSE 最經(jīng)典的應(yīng)用場景是 ： DeepSeek web 聊天界面  ，如圖所示：

圖片

當(dāng)在 DeepSeek 對話框發(fā)送消息后，瀏覽器會發(fā)送一個 HTTP 請求 ，服務(wù)端會通過 SSE 方式將數(shù)據(jù)返回到瀏覽器。

圖片

5.總結(jié)

選擇建議：

• 需要 簡單兼容性 → 短輪詢
• 需要 中等實時性 → 長輪詢
• 只需 服務(wù)器推送 → SSE
• 需要 全雙工實時交互 → WebSocket