1. 基本概念

協議	通信模式	協議層	數據流向	連接方式
SSE	服務器單向推送	基于HTTP/HTTPS	服務器→客戶端（單向）	持久化TCP連接
WebSocket	全雙工通信	獨立協議（基于TCP）	服務器?客戶端（雙向）	持久化TCP連接（升級協議）
Polling	客戶端主動輪詢	基于HTTP/HTTPS	客戶端→服務器（單向觸發響應）	短連接（頻繁建立/關閉）

---

2. 核心特性對比

特性	SSE	WebSocket	Polling
實時性	高（低延遲）	極高（毫秒級）	低（依賴輪詢間隔）
帶寬效率	高（無重復請求）	高（無頭部開銷）	低（重復HTTP頭部開銷）
服務器壓力	中等（維護長連接）	中等（維護長連接）	高（頻繁建立連接）
兼容性	不支持IE/部分移動瀏覽器	廣泛支持（需HTTP/1.1+）	全瀏覽器支持
數據格式	文本（text/event-stream）	二進制/文本	任意HTTP兼容格式
斷線重連	自動支持	需手動實現	無（每次輪詢獨立）

---

3. 優缺點分析

SSE

• 優點：
  • 簡單易用（基于HTTP，無需額外協議）。
  • 自動重連機制。
  • 適合服務器主導的實時更新（如新聞推送、股價波動）。
• 缺點：
  • 僅支持單向通信（服務器→客戶端）。
  • 瀏覽器兼容性有限（IE不支持）。

WebSocket

• 優點：
  • 全雙工通信，適合交互式場景（如聊天、游戲）。
  • 低延遲和高性能（減少HTTP開銷）。
• 缺點：
  • 實現復雜（需處理協議升級、心跳檢測等）。
  • 需要額外的負載均衡配置（非HTTP默認端口）。

Polling

• 優點：
  • 兼容性極佳（所有瀏覽器支持）。
  • 實現簡單（普通HTTP請求）。
• 缺點：
  • 高延遲（輪詢間隔不可控）。
  • 浪費資源（無效請求多）。

---

4. 典型應用場景

協議	適用場景	不適用場景
SSE	實時通知（股票行情、新聞推送）、日志流監控	需要客戶端頻繁發送數據的場景
WebSocket	在線聊天、多人協作編輯、實時游戲、視頻會議	簡單單向數據推送（過度設計）
Polling	兼容性要求高的舊系統、低頻更新（如天氣查詢）	高頻實時交互（如在線游戲）

---

5. 選擇建議

• 選擇SSE：需要服務器單向推送且追求簡單實現時（替代長輪詢）。
• 選擇WebSocket：需雙向交互或對延遲敏感的場景。
• 選擇Polling：僅在不支持SSE/WebSocket的舊系統中作為備選。

---

總結

• SSE是HTTP生態內輕量級的單向推送方案。
• WebSocket是高性能全雙工通信的標準選擇。
• Polling是兼容性強但效率低下的兜底方案。

根據實際需求（實時性、雙向性、兼容性）和系統資源（服務器負載、帶寬）綜合選擇。