即時功能一定要用 WebSocket 嗎？淺談 WebSocket 與它的老對手們

「我想在網站加個即時聊天／即時通知，是不是要用 WebSocket？」這是我們接需求時很常被問到的一句話。答案是——有時候要，但很多時候你其實用不到，甚至不該用。這篇就來破解這個迷思，順便把 WebSocket 和幾個常被拿來一起比較的技術講清楚。

先講結論

「即時」不等於「一定要 WebSocket」。真正的問題是：資料要單向流還是雙向流？延遲要多低？你願意付出多少複雜度？ 想清楚這三件事，答案自然浮現。

WebSocket 是什麼？

平常瀏覽器跟伺服器的對話是「一問一答」——你點一下（發出請求），伺服器回一次（回應），然後這條連線就關了。要拿新資料，就得再問一次。

WebSocket 打破了這個模式。它一開始也是用一個普通的 HTTP 請求「敲門」，但敲完之後雙方協議把這條連線升級成一條持續開著的雙向通道（網址從 http:// 變成 ws://）。從此伺服器可以主動推東西給你，你也能隨時傳給伺服器，不用每次重新敲門。

這條「常開的雙向通道」就是 WebSocket 的靈魂，也是它適合聊天室、多人協作、線上遊戲、即時報價這類雙方都要頻繁互推訊息場景的原因。

常被一起比較的四個對手

WebSocket 很少單獨出現，它總是跟這幾位一起被拿出來比：

技術	資料方向	底層	延遲	複雜度	最適合
短輪詢 Short Polling	用戶端一直問	HTTP	高	低	偶爾更新、能接受延遲
長輪詢 Long Polling	伺服器 hold 住再回	HTTP	中	中	相容性優先的推播
SSE（Server-Sent Events）	伺服器 → 用戶端（單向）	HTTP	低	低	通知、即時比分、動態牆
WebSocket	雙向	升級後的 TCP	低	中	聊天、協作、遊戲
WebRTC	點對點雙向	UDP 為主	極低	高	視訊、語音、P2P 傳輸

短輪詢：最土法煉鋼

用戶端每隔幾秒就問伺服器一次「有新東西嗎？」。實作最簡單，但大多數時候都是白問，浪費流量，而且延遲就等於你的輪詢間隔。適合「更新不頻繁、慢一點也沒關係」的情境。

長輪詢：輪詢的進化版

用戶端問了之後，伺服器不急著回，先 hold 住連線，等真的有新資料才回應，用戶端收到後馬上再問。這樣就能模擬出「伺服器主動推」的效果，相容性極佳（純 HTTP），是 WebSocket 普及前的主流做法。

SSE：只要伺服器單向推，它就夠了

這是最容易被忽略、卻常常是正解的選項。SSE 讓伺服器單向、持續地推訊息給瀏覽器，用瀏覽器內建的 EventSource 就能接，還會自動斷線重連。如果你的需求是「伺服器有更新就通知我」——像即時比分、股價、通知紅點、動態消息——SSE 比 WebSocket 更輕、更簡單。 很多人一律上 WebSocket，其實是殺雞用牛刀。

WebRTC：不同賽道的選手

WebRTC 是為了瀏覽器之間點對點傳音訊、視訊、資料而生，延遲極低，但架設複雜（要處理信令、STUN/TURN 穿透）。它跟 WebSocket 常被一起提，但其實解決的是不同問題——視訊通話找它，聊天訊息找 WebSocket。

那我到底該選哪個？

用一句話幫你對號入座：

• 單向、伺服器推給你 → 先考慮 SSE，別急著上 WebSocket
• 雙向、雙方頻繁互動（聊天、協作、遊戲） → WebSocket
• 音訊視訊、點對點 → WebRTC
• 更新很少、又想最簡單 → 短輪詢就好
• 要相容老舊環境的推播 → 長輪詢還是有它的位置

合理的期待值

WebSocket 很強，但它不是「即時功能」的同義詞。常開連線也有代價——伺服器要維持大量連線、要處理斷線重連、負載平衡與擴展也比無狀態的 HTTP 麻煩。先問清楚需求是單向還是雙向、能接受多少延遲，再選工具，往往會發現一個更輕的方案就解決了。

如果你正在規劃網站的即時功能，不確定該用哪一個，歡迎跟我們聊聊，選對地基能省下之後很多力氣。