在互聯網早期，網頁像一本翻頁雜志：用戶點擊，瀏覽器請求，服務器響應，頁面刷新。當產品經理提出“實時聊天”“股價閃動”“庫存秒變”這些需求時，HTTP 的“請求—響應”模型立刻顯得力不從心。于是，開發者經歷了一場從“笨拙輪詢”到“優雅全雙工”的技術進化。今天，就讓我們再走一遍這條路。

一、短輪詢

思路簡單到極致：

客戶端每隔 X 秒發一次 Ajax，問“有新消息嗎？”服務器答“沒有”——循環往復。

偽代碼

痛點

• 空包占比高：99% 的請求是無用往返。

• 連接反復建立：TCP 三次握手 + 四次揮手成了“日常運動”。

• 延遲不可控：最快也要等到下一個輪詢周期。

短輪詢就像給服務器打“騷擾電話”，簡單，卻低效。

二、長輪詢

聰明的工程師想到：

把電話“掛起不掛線”。客戶端發起 Ajax，服務器夯住這個連接，直到真的有消息才返回；客戶端收到后立即再掛一個，如此循環。

優勢

• 零空包：每次響應都攜帶數據。

• 減少連接數：TCP 復用率提高。

新問題

• 超時風險：瀏覽器/代理可能粗暴切斷長連接。

• 資源懸掛：服務器需要為大量空閑連接維持線程或內存。

• 實時性仍受“掛起窗口”限制。

長輪詢把“騷擾電話”變成了“占線等待”，但線路資源依舊吃緊。

三、WebSocket

HTML5 帶來了 WebSocket——基于 TCP 的全雙工通道。

握手階段仍用 HTTP，升級協議后，雙方可隨時推送數據幀。

1. 握手：HTTP 的極限操作

客戶端：

服務器返回 101：

狀態碼 101 表示：協議升級完成。此后數據幀不再走 HTTP。

2. 通信：幀級協議，雙向飛馳

• **幀（frame）**是最小單位，攜帶 payload、opcode、掩碼。

• **流（stream）**由幀組成，任何一方都可主動發送。

• 無隊頭阻塞：不同消息并行交錯，靠幀頭 id 區分歸屬。

3. 代碼示例（Node + 前端）

前端

Node 后端（ws 庫）

四、使用場景與權衡

閱讀原文：點擊這里