即時通訊協定 (Real-time Protocols)
三種協定速覽
| 協定 | 方向 | 底層 | 主要用途 |
|---|---|---|---|
| SSE | 單向（Server → Client） | HTTP/TCP | 通知、事件推送 |
| WebSocket | 雙向 | TCP（HTTP upgrade） | 即時聊天、協作 |
| WebRTC | 點對點（P2P） | UDP | 音視訊通話 |
SSE（Server-Sent Events）
建立在 HTTP 之上，讓伺服器在單一 HTTP 連線中持續推送多則訊息：
一般 HTTP（需等待整個回應）：
GET /events → { "events": [ {...}, {...}, ... ] }
SSE（逐行推送，即時處理）：
GET /events →
data: {"id": 1, "event": "bid_update", "price": 100}
data: {"id": 2, "event": "bid_update", "price": 110}
...
已知限制（面試加分項）：
- 連線不能保持太長（LB、代理可能會關閉）
EventSource物件會自動用最後收到的 ID 重連- 某些不規範的網路會批次聚合 SSE 回應，退化成普通 HTTP
何時用 SSE
需要伺服器推送通知或事件給客戶端時（如拍賣出價更新）。比 WebSocket 輕量，基礎設施成本低。
WebSocket
透過 HTTP Upgrade 建立持久 TCP 連線，實現雙向即時通訊：
1. 客戶端發送 HTTP Upgrade 請求
GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
2. 伺服器回應 101 Switching Protocols
3. TCP 連線切換為 WebSocket 協定
Client ◄──────────────► Server
（雙向二進位訊息）
4. 連線保持直到明確關閉
應用層協定需自定義：WebSocket 只是通道，客戶端/伺服器交換的訊息格式需要自己定義（通常用序列化 JSON）。
基礎設施成本高
客戶端和伺服器之間的每個元件都需要支援 WebSocket（防火牆、代理、負載平衡器）。
不要在沒有說明原因的情況下直接跳進 WebSocket——這是讓面試官扣分的好方法。
WebSocket 適合：高頻率雙向通訊（即時聊天、線上遊戲、協作編輯）
WebRTC
唯一在 L7 使用 UDP 的協定。讓瀏覽器之間建立直接 P2P 連線，不需要資料中繼伺服器。
連線建立四步驟：
1. 客戶端連到信令伺服器（Signaling Server），了解對方 peer
2. 客戶端聯繫 STUN 伺服器，取得自己的公網 IP 和 port
3. 透過信令伺服器交換連線資訊
4. 建立直接 P2P 連線，開始傳送音視訊資料
NAT 穿透兩種方案：
| 方案 | 原理 | 成功率 |
|---|---|---|
| STUN | 打洞（hole punching），建立可路由的公網位址 | 高（大多數 NAT） |
| TURN | 中繼伺服器轉送（備案，費用較高） | 100%（但失去 P2P 優勢） |
WebRTC 是小眾解法
WebRTC 極難做對，即使最好的實作仍會有連線問題。
只在音視訊通話/會議場景使用 WebRTC。試圖用 WebRTC 設計其他 P2P 系統，往往搞錯方向。
選型決策流程
需要即時通訊？
│
▼
伺服器單向推送就夠了？
│
Yes ──► SSE（輕量、低基礎設施成本）
│
No
│
▼
需要雙向高頻通訊？
│
Yes ──► WebSocket
│
No
│
▼
需要瀏覽器間直接 P2P 音視訊？
│
Yes ──► WebRTC
│
No ──► 重新考慮 SSE 或 REST polling
Related Notes
- 01-Networking/02-TCP-vs-UDP — WebRTC 使用 UDP
- 01-Networking/06-Load-Balancing — WebSocket 需要 L4 LB
- 01-Networking/04-API-Paradigms — REST 請求-回應 vs 即時推送
- 01-Networking/Practice-Networking