WebSocket 簡介

小碎念: 可惜因為找周公下棋錯過發文時間，在第三天後就被中斷比賽了，不過還是堅持寫完吧!

WebSocket 顧名義就是應用於 Web 網頁應用的 Socket IPC (跨行程通訊實作)，有別於 Restful API 像是露營一樣，準備工作繁複然後僅用於一次性的快問快答，它有著 Socket 的長連結特性，管道建立後就能密集雙向收發訊息，特別適合要求高頻通訊的IRC(即時聊天室、交易所、遊戲)應用場景，以下就帶著各位認識這個協議。

簡單的示意圖: 如同最右邊的圖，透過 HTTP 建立連接後，後面就能使用 WebSocket 雙向隨意通訊了

引用自: Browser APIs and Protocols: WebSocket - High Performance Browser Networking (O'Reilly)

接著用些比對的方式，讓大家更認識 WebSocket 的特性

短連結 VS 長連結

在行程間通訊（IPC）的各種實踐家族中，大致可分為「短連結」與「長連結」。

WebSocket 屬於長連結的一種。

短連結（HTTP/REST）

• 特色：一次請求、一次連線、開啟一次通訊，完成後即關閉。
• 適用：無狀態的 Web 2.0 應用。每次請求都攜帶必要參數，彼此請求獨立。
• 優點：簡單、可水平擴充、易於緩存快取與觀測（如以 NGINX、CDN、APM）。
• 限制：即時性差，雙向互動困難，需頻繁輪詢或以 SSE 等替代。

長連結（WebSocket 等）

• 特色：初始化後維持同一條通道，雙向、持久連線，像用兩個人在 LINE 的群組中聊天。
• 適用：即時性高、需要狀態連續性的場景（交易撮合、即時白板、遊戲、通知）。
• 優點：低延遲雙向傳輸，可推送事件，節省輪詢成本。
• 限制：必須妥善處理前後文與狀態，同步與重連、順序與去重更複雜；壓測與觀測也較具挑戰。

WebSocket VS 傳統 Socket

有些人可能有過 C 語言的開發經驗，就知道有 Socket 這個函式庫。

若只從應用端觀察，WebSocket 與傳統 Socket 都需要處理建立連線、監聽接收與發送訊息，但 WebSocket 為了「瀏覽器與 Web 生態」做了許多貼心的封裝：

WebSocket 的優勢

• 原生整合 HTTP/HTTPS：透過 Upgrade 握手，易穿越防火牆與代理；可沿用既有負載平衡與 TLS。
• 廣泛的瀏覽器支援：前端以標準 API 使用（WebSocket 物件、事件模型）。
• 訊息框格式與分片：支援文字與二進位類型資料，具備基本訊息框界線與控制訊息框。
• 事件導向：open、message、error、close 便於前端與上層非同步程式整合。

傳統 Socket（TCP/UDP）的優勢

• 自由度高：可自訂協議、編解碼、重傳策略，最大化效能或針對特定設備優化。
• 少一層封裝：在內網或專用線路中，省去 HTTP 升級與代理相容性顧慮。

典型取捨

• 需要 Web 生態、跨網與 TLS、代理相容、瀏覽器端：選 WebSocket。
• 需要極致客製、特定網路條件或非網頁環境的高吞吐量：選傳統 Socket 或 gRPC over HTTP/2 作為折衷。

Python 的 WebSocket 函式庫：同步 vs 非同步

在 Python 生態中，分為同步（blocking）與非同步（asyncio）兩種實作路線。WebSocket 也不例外，最常用的就是 websocket-client 跟 websockets 這兩套，分述如下。

同步實作（例如 websocket-client）

• 心智模型：單執行緒、循序流程，易讀易除錯。
• 適用情境：
  • 簡單驗證邏輯、POC、腳本式工具。
  • 單連線或少量連線，對延遲與吞吐要求不高。
• 典型優缺點：
  • 優點：上手快，與傳統測試框架整合容易。
  • 限制：阻塞 I/O，難以同時處理多連線與高併發。

非同步實作（如 websockets、aiohttp、AnyIO/Trio 生態）

• 心智模型：事件循環 + 協程，靠 await 切換任務。
• 適用情境：
  • 多連線長時維持、需要即時推播與回應。
  • 對吞吐與延遲敏感、需要資源效率的服務側或壓測客戶端。
• 典型優缺點：
  • 優點：高併發、資源利用率佳，易擴展多路連線與批次任務。
  • 限制：程式結構較複雜，需處理競爭狀態、封包順序、積累背壓、重試與重連策略。

實務建議

• 少量、自動化驗證為主：先用同步庫快速疊代，驗證協議與流程。
• 進入壓測、多路連線與長時間穩定性驗證：改用非同步庫，加入訊息排序校驗、去重、心跳、重連、指標觀測。

小結

這個章節簡單講述了 WebSocket 跟其他協議的一些不同差異處，還有 Python 端的實作策略考量。
希望能給大家一個概念上的理解。 後續的開發都會圍繞著這一個跟 HTTP RESTful 截然不同的新協議方法來討論。