跳至主要內容
日沐 SunBathe

Appearance

Socket.io 深度剖析：核心原理與適配器擴展 ​

在之前的章節中，我們學會了如何從 Byte 層級打造 WebSocket 伺服器。但在企業級開發中，我們更常接觸到的是 Socket.io。

很多人誤以為 Socket.io 就是 WebSocket，這其實是不準確的。Socket.io 是一個基於 WebSocket 的抽象封裝庫，它提供了更強大的錯誤恢復、自動重連與廣播能力。本章我們將拆解它的內部魔法。

一、 核心引擎：Engine.io ​

Socket.io 的連線是由底層的 Engine.io 負責的。它採用了一種特殊的「升級策略」：

  1. HTTP Long Polling 首先建立：確保 100% 的相容性（避免老舊代理攔截 WebSocket）。
  2. 背景測試 WebSocket：在 Polling 期間暗中測試當前環境是否支援 WebSocket。
  3. 協議升級 (Upgrade)：測試通過後平滑切換，不導致應用層斷線。

二、 Socket.io 的兩大支柱 ​

1. 命名空間 (Namespaces) ​

允許在單個 TCP 連線上邏輯地劃分多個通道。例如 /admin 與 /chat。

2. 房間 (Rooms) ​

Socket.io 內建了完美的房間支援：

javascript
// 加入房間
socket.join("room1");

// 廣播給房間內所有人 (排除自己)
socket.to("room1").emit("message", "hello");

三、 適配器 (Adapter) 與擴展 ​

當你啟動多個伺服器實例（叢集）時，Server 1 並不知道 Server 2 的連線情況。這時 Socket.io 的 Adapter 機制就派上用場了。

透過更換為 Redis Adapter，所有 Server 的訊息會先流向 Redis，再分發給目標節點。這就是 Socket.io 能支撐百萬級併發的秘密。

總結 ​

Socket.io 雖然稍重，但它帶來的自動重連、多傳輸協議降級與房間系統，極大降低了維護複雜即時系統的成本。

下一章，我們將探討分散式集群方案：Redis Pub/Sub 與水平擴展。

️ 進階挑戰 ​

  1. 實作挑戰：嘗試在瀏覽器的 Network 面板觀察 Socket.io 的連線過程，看看你是如何從 transport=polling 變成 transport=websocket 的。
  2. 深度思考：既然 WebSocket 已經很成熟了，Socket.io 堅持「先 Polling 再升級」的策略在現代 Web 環境中還有意義嗎？

延伸閱讀與資源 ​