WebSocket、WebRTC 與下一代——雙向、點對點、選型總表
🎁 登入後投票可獲得 5 點 希望電子報內容在更專業嗎? 希望電子報內容在更專業嗎? 是, 希望有更技術性的專題否, 希望能多一些小白也能看懂的內容繼續填完整問卷 |
嗨，我是凱文大叔。
前兩期把「你去問」（輪詢）和「它來說」（SSE）講完了。這期進入即時通訊的重武器區：雙向的 WebSocket、點對點的 WebRTC，以及幾個你該認識的新面孔——最後兌現承諾，給你一張可以直接抄的選型決策表。
WebSocket：真正的雙向對講機
WebSocket 從一個普通的 HTTP 請求出發，透過 Upgrade: websocket 握手，把這條連線「升級」成全雙工通道：之後雙方隨時都能開口，訊息可以是文字或二進位，沒有請求—回應的回合限制。
它的主場是雙向、高頻、低延遲：
- 聊天室、即時客服——訊息你來我往
- 多人協作——白板、共編文件，每個人的操作要即時廣播給所有人
- 網頁遊戲——狀態同步每秒好幾次
- 交易下單——按下去的那一刻就要送達
一句話對比上期：SSE 是廣播電台，WebSocket 是對講機。只聽廣播的場景別買對講機——你會多付「連線管理」這筆隱形成本，下面後段會講它有多真實。
WebRTC：根本不走你的伺服器
WebRTC 解的是另一個維度的問題：瀏覽器跟瀏覽器直接連，音訊、視訊、任意資料（DataChannel）點對點傳輸，內建加密與網路自適應。
- 視訊通話、線上會議、螢幕分享
- P2P 檔案傳輸（檔案不經過伺服器）
- 即時性極端敏感的資料通道（雲端遊戲的操作流）
但「點對點」不代表「不需要伺服器」——這是 WebRTC 最大的認知陷阱。你仍然需要：
- 信令伺服器：兩個瀏覽器交換「怎麼連上我」的資訊（通常拿 WebSocket 來做）
- STUN：幫雙方發現自己在 NAT 後面的公網位址
- TURN：雙方都穿不透 NAT 時的中繼備援——這是要花頻寬錢的，做視訊產品時 TURN 流量是實打實的成本項
所以 WebRTC 的定位很清楚：媒體流與 P2P 才用它。拿它做聊天室是用火箭筒打蚊子。
新世代與家族其他成員
- Web Push：唯一能在使用者沒開你網站時送通知的技術（配合 Service Worker，走瀏覽器廠商的推播服務）。「離線也要通知」找它，不是 WebSocket。
- WebTransport：跑在 HTTP/3（QUIC）上的新協定，同時支援可靠與不可靠傳輸——遊戲、串流這種「舊資料晚到不如丟掉」的場景等它很久了。它今年三月隨 Safari 26.4 補上最後一塊拼圖，正式成為 Baseline（Chrome、Edge、Firefox、Safari 全數支援），是 WebSocket 眼下最有力的挑戰者。
- HTTP/2 Server Push：曾被寄予厚望，結果沒人用得好，Chrome 已經移除支援——留名警世：不是掛著「Push」就適合做即時通訊。
- Socket.IO／STOMP／SignalR／MQTT over WebSocket：注意，這些是程式庫或訊息協定，不是傳輸層——底下跑的還是 WebSocket（含降級路徑）。它們解決的是重連、房間、訊息格式這些「WebSocket 沒管的事」。
常被誤會的親戚：Webhook
有人會問：Webhook 不也是「即時推送」嗎？算，但方向完全不同——Webhook 是伺服器對伺服器：外部服務（金流、GitHub、LINE）在事件發生時，對「你的後端」發一個 HTTP 請求。瀏覽器沒有公網位址，接不到 webhook，所以它不在瀏覽器即時技術的選型清單裡。
正確的理解是「互補鏈」而不是「替代品」：
金流服務 ──webhook──▶ 你的後端 ──SSE / WebSocket──▶ 使用者的瀏覽器
（付款完成） （更新訂單狀態） （畫面即時顯示「付款成功」）
如果 AI 在「瀏覽器要即時看到更新」的需求裡端出 webhook，那就是搞錯了受眾——webhook 通知得了你的伺服器，通知不了使用者的螢幕。（Webhook 自己的深水區——簽章驗證、重試與冪等——下期就來講。）
|
FlixSeek共享平台 購買時輸入折扣券【kevin】還能打95折喔 |
後段：WebSocket 的生產等級清單
WebSocket 上線後你才會發現，握手成功只是開始。照系列慣例，每一項附一句可以直接丟給 AI 的提示詞。