【RealTime】Websocket VS SSE (Server-Sent Events)

1. 基本概念

WebSocket 要雙向、SSE 只要單向推送；先看需求是哪一種，再決定要付出多少連線成本。

• WebSocket：

  • 一種全雙工通訊協定，允許在單一 TCP 連線上進行雙向通訊。
  • 連線建立後，用戶端和伺服器都可以隨時傳送資料，不需要每次都重新建立 HTTP 連線。

• Server-Sent Events (SSE)：

  • 一種單向通訊協定，伺服器可以主動向用戶端推送更新。
  • 使用 HTTP 協定的一部分（基於 HTTP 的持久連線）：用戶端向伺服器發送一個 HTTP 請求後，伺服器會保持這條連線，並持續向用戶端傳送資料。

2. 通訊方向

• WebSocket：雙向（雙工）通訊。

  • 用戶端和伺服器之間可以自由地傳送與接收訊息，適合需要雙向資料流的應用，如即時聊天、多人遊戲。

• SSE：單向（單工）通訊。

  • 伺服器可以持續向用戶端推送資料，但用戶端無法透過同一條連線向伺服器傳送資料。適合用於持續接收資料流的情況，如即時股票行情更新、社群媒體通知。

3. 協定與連線

• WebSocket：

  • 使用自訂的 WebSocket 協定（ws:// 或 wss://），需要從 HTTP/HTTPS 升級而來。
  • 連線建立後，會保持持久、穩定的雙向通訊。

• SSE：

  • 使用標準的 HTTP 協定（http:// 或 https://）。
  • 發出一次請求後，會保持長時間的 HTTP 連線，直到伺服器關閉連線或用戶端斷線。

4. 瀏覽器支援

• WebSocket：

  • 大多數現代瀏覽器都支援 WebSocket，但不支援 IE 9 或更舊的版本。
  • 需要專用的 WebSocket 函式庫或 API 來管理連線和訊息。

• SSE：

  • 大多數現代瀏覽器（包括 IE 10 及以上）都支援 SSE。
  • 原生支援的 API 非常簡單易用，不需要額外的函式庫。

5. 重連機制

• WebSocket：

  • 需要自行實作重連邏輯。連線中斷時，必須撰寫用戶端程式碼來嘗試重新連線。

• SSE：

  • 內建自動重連功能。連線中斷時，瀏覽器會自動嘗試重新建立連線。

6. 資料格式

• WebSocket：

  • 支援任意的資料格式，包括文字和二進位資料（如 JSON、XML、圖片等）。

• SSE：

  • 只支援文字資料（UTF-8 編碼），通常使用純文字或 JSON 格式。

7. 使用情境

• WebSocket：

  • 適用於需要雙向通訊的情境，如聊天室、即時遊戲、協作工具等。

• SSE：

  • 適用於需要伺服器向用戶端持續推送更新的情境，如即時通知、社群媒體更新、監控面板等。

8. 效能與資源

• WebSocket：

  • 建立和維護雙向連線的開銷較高，適合需要低延遲和高頻率雙向通訊的情境。
  • 需要伺服器支援 WebSocket 協定，並能夠管理大量的持久連線。

• SSE：

  • 資源開銷相對較低，使用 HTTP 持久連線，可以輕鬆整合到現有的 HTTP 基礎設施中。
  • 不適合需要頻繁向伺服器傳送資料的情境。

延伸閱讀

• 【RealTime】Laravel Reverb - 官方 WebSocket Server 完整實作：決定採用 WebSocket 後，可看 Laravel Reverb 的完整實作
• 【RealTime】Server-Sent Events - php 範例：決定採用 SSE 後，可看 PHP 的實作範例