標準 HTTP 是「用戶端問、伺服器答」——資料一在伺服器上更新，用戶端卻不知道。想讓更新即時抵達，就得在這條單向的問答上動手腳：讓用戶端一直問、讓伺服器把答覆吊著、或乾脆開一條能主動推的通道。四種做法，就是這條光譜上的四個點。
🧠 Core Ideas
TIP
一般 HTTP 的流程只有三步：用戶端開連線請求資料 → 伺服器算出回應 → 送回用戶端。所有即時更新技術，都是在回答同一個問題——伺服器有新資料時，怎麼讓用戶端知道。
- Ajax Polling（輪詢）：用戶端以固定間隔（例如每 0.5 秒）反覆請求；沒新資料時伺服器回空回應。
- HTTP Long-Polling（長輪詢）：用戶端照常請求，但伺服器把請求吊著、有資料才回，又稱 Hanging GET。
- WebSocket：單一 TCP 上的全雙工持久連線，雙方隨時互推。
- Server-Sent Events（SSE）：持久連線，伺服器單向推給用戶端。
⚖️ Tradeoffs
Ajax Polling — 最直覺，但大量空回應
- 大多數 AJAX 應用的標準做法：網頁定期發請求，伺服器照一般 HTTP 流量算好回應送回，用戶端重複這個循環拿到更新。
- 痛點：用戶端得不斷問「有沒有新資料」，多數回應是空的，白白製造 HTTP 開銷。
HTTP Long-Polling — 把請求吊著等資料
- 用戶端請求方式與一般輪詢相同，但預期伺服器不會立即回應。
- 沒資料時伺服器不送空回應，而是保持請求、等到資料出現（或逾時）才送出完整回應。
- 用戶端收到回應後立即再發一個 Long-Poll 請求，讓伺服器幾乎總有一個等待中的請求可用來遞送資料。
- 每個 Long-Poll 請求都有逾時限制，連線關閉後用戶端需要定期重新連線。
WebSocket — 一條連線，雙向隨時推
- 用戶端透過 WebSocket Handshake 建立連線，成功後雙方可隨時雙向傳輸。
- 單一 TCP 上的持久連線，相比傳統 HTTP 通訊開銷更低，有利即時資料傳輸。
- 伺服器可主動推內容到瀏覽器，不必等用戶端請求；訊息在連線保持的狀態下來回傳遞，形成雙向持續對話。
Server-Sent Events — 伺服器單向串流
- 用戶端與伺服器建立一個持久且長期的連線，伺服器透過它把資料推給用戶端。
- 只解決伺服器 → 用戶端這個方向；用戶端若要送資料回伺服器，得改用其他技術或協定。
- 最適合需要即時單向資料流、或伺服器在迴圈中產生資料要連續發多個事件的場景。
🔑 Takeaways
- Polling 最好懂但最浪費——多數請求換回空回應；Long-Polling 把請求吊著、有資料才回，省掉空轉。
- 要雙向即時用 WebSocket（全雙工、開銷低）；只要伺服器單向推用 SSE，更輕、天生契合連續事件流。
- 四者都是在「用戶端問、伺服器答」這條單向 HTTP 上做取捨：問的頻率、答的時機、通道的方向。
No notes yet — jot your takeaways or Q&A here.