WebSocket是一種網路通訊協定，專為用戶端與伺服器之間的持久雙向資料交換而設計。當應用程式需要即時更新、低延遲互動和連續訊息傳遞，又不希望反覆開啟新的HTTP請求時，通常會採用WebSocket。

在傳統Web通訊中，用戶端通常會先送出請求，然後等待伺服器回應。WebSocket改變了這種模式。完成初始交握後，雙方都可以在同一條連線上按需傳送訊息。因此，它適用於聊天系統、即時儀表板、線上遊戲、金融行情、協同編輯、物聯網監控、客服控制台、通知系統和指揮平台等場景。

從重複請求到持久會話

許多Web應用程式都需要最新資料。股票價格會變動，新的聊天訊息會到達，警報可能被觸發，裝置狀態會改變，或者使用者正在編輯共享文件。如果瀏覽器只使用一般請求-回應通訊，就可能需要一次又一次詢問伺服器是否有變化。

這種重複輪詢會帶來延遲和不必要的網路流量。伺服器可能收到大量沒有新資料可返回的請求，而用戶端仍然可能錯過事件發生的準確時刻。

持久通訊通道可以解決這個問題。連線一旦建立，伺服器就能立即向用戶端推送資料，用戶端也可以回傳訊息，而不必每次都重新發起請求。

初始交握

HTTP升級請求

連線通常以HTTP請求開始。用戶端請求伺服器將連線從一般HTTP通訊升級為WebSocket協定。該請求會包含特定標頭，用來表示用戶端希望進行協定切換。

伺服器會檢查自身是否支援升級，以及該請求是否合法。如果接受升級，伺服器會回覆切換協定的回應，連線隨即變成WebSocket通道。

協定切換

升級成功後，連線不再像一般HTTP請求-回應交換那樣運作。它會變成一條長連線通道，雙方都可以獨立傳送幀。

這個步驟很重要，因為它讓WebSocket能夠自然地與既有Web基礎架構協同運作。它先透過相容HTTP的入口建立連線，然後再支援持續通訊。

安全與非安全模式

WebSocket可以採用非安全和安全兩種形式。非安全方案通常寫作ws，安全加密版本寫作wss。對於現代Web應用程式，通常更建議使用基於TLS的安全WebSocket，尤其是在涉及使用者資料、驗證權杖、業務訊息或營運事件時。

安全版本可以防止流量被竊聽，並協助即時通訊與基於HTTPS的Web安全實務保持一致。

全雙工訊息流

核心原理是全雙工通訊。這表示用戶端和伺服器可以在同一條開啟的連線上獨立傳送訊息。伺服器傳送新資訊之前，不需要等待用戶端先發起請求。

這不同於一般HTTP，因為一般HTTP中伺服器通常只在收到請求後才傳回回應。在WebSocket會話中，一旦事件發生，伺服器就可以立即推送告警、狀態變化、聊天訊息、通知或命令結果。

這種雙向流動是該協定被廣泛用於即時系統的原因。它降低了延遲，減少了重複連線開銷，也讓應用程式行為顯得更加即時。

基於幀的通訊

文字幀

文字幀承載可讀的訊息資料，常見格式包括JSON。許多瀏覽器應用程式使用文字幀，因為它們易於產生、解析、除錯，並且容易與Web應用程式邏輯整合。

例如，一條聊天訊息可以作為JSON物件傳送，其中包含使用者ID、房間ID、訊息內容和時間戳。

二進位幀

二進位幀承載非文字資料。它們可用於精簡型協定訊息、音訊資料、遊戲資料、裝置遙測、檔案片段或自訂應用程式酬載。

當應用程式不需要人類可讀的文字格式時，二進位傳輸可以降低額外開銷。

控制幀

控制幀用於管理連線，包括ping、pong和close等動作。ping和pong可以協助偵測對端是否仍然可達，close幀則協助以受控方式終止連線。

這些控制功能對長連線會話很重要，因為連線保持開啟時，網路條件可能隨時變化。

為什麼延遲會降低

延遲降低的原因在於連線已經處於開啟狀態。對於每一次小更新，用戶端和伺服器不必反覆執行請求建立、連線建立、標頭交換和回應等待。

對即時應用程式來說，即使是很小的延遲也會影響使用者體驗。聊天訊息應立即出現，即時警報應快速到達儀表板，協作文件也應在沒有明顯延遲的情況下反映編輯結果。

透過保持連續路徑可用，WebSocket允許事件驅動更新，而不是基於固定間隔反覆檢查。

連線生命週期

開啟階段

開啟階段包括用戶端請求、伺服器驗證、交握回應和協定升級。如果伺服器拒絕升級，通道就不會被建立。

應用程式應清楚處理交握失敗。連線失敗可能由伺服器設定、驗證失敗、代理限制、TLS問題、路徑錯誤或不支援的協定行為引起。

作用中階段

在作用中階段，訊息可以雙向傳遞。應用程式可以定義自己的訊息類型、事件名稱、酬載格式、心跳間隔、驗證更新邏輯和錯誤處理方式。

協定提供通道，但應用程式仍然需要自己的業務規則。

保活階段

長連線可能經過代理、閘道、防火牆、負載平衡器和行動網路。一些中間系統可能會關閉閒置連線。心跳訊息有助於保持通道可見，並偵測中斷的鏈路。

常見設計是定期傳送ping或應用層心跳訊息。如果在規定時間內沒有收到回應，用戶端可以重新連線。

關閉階段

當使用者離開頁面或伺服器結束會話時，連線可能正常關閉。它也可能因網路中斷、逾時、伺服器重新啟動、驗證到期或用戶端故障而異常關閉。

良好的應用程式應包含重連邏輯、訊息復原規則和使用者回饋，避免暫時斷線在使用者無感的情況下破壞工作流程。

與常見替代方案的差異

輪詢是檢查更新最簡單的方法。用戶端反覆詢問伺服器是否有新資料。它實作簡單，但可能浪費請求並產生延遲。

長輪詢會讓請求保持開啟，直到伺服器有新資料或發生逾時。它可以減少不必要的空回應，但仍依賴重複的HTTP請求。

Server-Sent Events允許伺服器透過單向串流向用戶端推送事件。這適合伺服器到用戶端的更新，但不提供同樣的雙向訊息模型。

當雙方都需要頻繁且快速傳送資料時，WebSocket更合適。不過它並非總是必要。簡單頁面、靜態內容、一般表單和低頻更新也可以很好地使用一般HTTP或其他方法。

應用層訊息設計

通道開啟後，應用程式必須定義訊息如何組織。協定本身不會自動知道某條訊息是聊天事件、裝置更新、命令請求、警報還是錯誤回應。

常見設計是使用結構化JSON訊息，欄位包括type、action、channel、payload、timestamp、request ID和status等。這樣伺服器和用戶端就能把訊息路由到正確邏輯。

對於較大的系統，訊息設計還應包含版本控制。如果以後訊息格式發生變化，舊用戶端和新伺服器可能仍需要安全通訊。

伺服器架構

WebSocket伺服器必須管理大量開啟的連線。不同於可能很快結束的一般HTTP請求，這些會話可以持續數分鐘甚至數小時。這會改變容量規劃方式。

伺服器需要連線追蹤、使用者繫結、訊息路由、驗證狀態、資源清理、逾時處理和廣播邏輯。如果有成千上萬甚至數百萬用戶端連線，架構必須面向併發進行設計。

許多真實系統會使用訊息佇列、發布訂閱系統、分散式會話儲存、負載平衡器和水平擴充來支援大量即時使用者。

負載平衡與擴充

擴充持久連線不同於擴充短HTTP請求。負載平衡器必須支援協定升級，並在會話期間將連線保持對應到正確的後端。

一些系統使用黏性會話，使已連線用戶端停留在同一台伺服器上。另一些系統使用共享訊息代理，使訊息能夠在多個後端節點之間傳遞。

設計大型部署時，團隊應考慮連線限制、記憶體占用、心跳流量、重連風暴、部署重新啟動和地理分布。

安全考量

安全至關重要，因為持久通道可能承載敏感且互動性強的資料。安全部署應使用wss、驗證來源、驗證使用者、檢查權限、限制訊息大小並防止濫用。

驗證可以發生在交握期間，也可以在連線後立即進行。權杖必須謹慎處理。如果連線開啟時權杖到期，系統應定義是更新、重新驗證還是關閉會話。

伺服器還應驗證每一條訊息。不能因為用戶端已經連線就自動信任它。輸入驗證、速率限制、授權檢查和稽核日誌仍然是必要的。

實際應用場景

聊天與協作

訊息應用程式、團隊聊天、客服視窗、即時評論和協同編輯器都受益於即時雙向更新。使用者可以傳送訊息、接收回覆，並在不重新整理頁面的情況下看到變化。

線上狀態、正在輸入提示、已讀回條和共享編輯事件也是常見範例。

即時儀表板

維運儀表板、金融系統、監控平台、物流大螢幕和指揮中心通常需要即時資料。WebSocket可以在事件發生時立即推送告警、圖表、裝置狀態和事件更新。

這減少了現場事件與操作員感知之間的延遲。

線上遊戲與互動系統

遊戲和互動式應用程式需要頻繁的狀態更新。持久雙向通道可以支援玩家動作、伺服器回應、房間狀態、分數和事件同步。

對於對延遲極其敏感的遊戲，也可以考慮其他協定，但WebSocket在基於瀏覽器的即時互動中很常見。

IoT與裝置監控

IoT平台可以使用持久通道更新裝置狀態、感測器數值、警報和控制訊息。儀表板無需反覆重新整理，就能顯示裝置條件變化。

對於現場裝置，選擇方案取決於耗電、網路穩定性、訊息量和平台架構。

常見問題

常見問題之一是升級請求失敗。當伺服器路徑錯誤、反向代理未轉發升級標頭、HTTPS與WSS不匹配，或後端不支援該協定時，就可能發生這種情況。

另一個問題是意外中斷。行動網路、閒置逾時、代理規則、防火牆行為和伺服器重新啟動都可能關閉連線。因此需要心跳和重連邏輯。

訊息過載也可能發生。如果伺服器太快傳送過多更新，用戶端可能落後，記憶體可能增加，使用者介面也可能變慢。應考慮背壓和限流機制。

部署最佳實務

正式環境應使用安全連線。對於現代Web應用程式，WSS應作為預設選擇，尤其是在涉及使用者身分或業務資料時。

設計清晰的訊息結構。根據需要包含訊息類型、請求ID、錯誤格式和版本資訊。

加入心跳和重連邏輯。網路變化時，使用者不應被迫手動重新整理頁面。

正確設定代理和負載平衡器。升級標頭、逾時值和連線限制必須支援長連線會話。

監控連線數量、訊息速率、錯誤率、記憶體使用、斷線原因和重連頻率。這些指標能夠反映系統真實健康狀態。

產業趨勢

即時互動正在成為許多數位系統的標準期待。使用者期待即時訊息、即時告警、動態儀表板、線上協作和回應迅速的控制介面。

隨著雲端平台、邊緣運算、IoT、線上服務台和瀏覽器工具持續成長，持久通訊通道仍然重要。同時，新的協定和傳輸技術也在發展，因此系統架構師應根據使用情境選擇，而不是只追隨趨勢。

當即時通訊與清晰的應用邏輯、安全的身分控制、可擴充基礎架構和可靠使用者體驗結合時，其價值最明顯。

WebSocket透過將HTTP連線升級為持久雙向通道，使用戶端和伺服器能夠以更低延遲和更少重複請求開銷連續交換訊息。

FAQ

WebSocket和HTTP一樣嗎？

不一樣。它從HTTP升級交握開始，但升級成功後，連線遵循WebSocket幀格式，而不是一般請求-回應行為。

為什麼連線在反向代理後會失敗？

代理可能沒有轉發升級標頭，可能太快關閉閒置會話，可能使用了錯誤的後端路徑，或者沒有正確支援長連線。

每個即時功能都應該使用WebSocket嗎？

不一定。簡單通知或單向更新可以使用Server-Sent Events、輪詢或一般API請求。選擇應匹配訊息頻率和傳輸方向。

如何偵測中斷的連線？

使用ping和pong幀，或應用層心跳訊息。如果回應停止到達，用戶端可以關閉會話並重新連線。

排查問題時應該記錄什麼？

記錄交握失敗、驗證錯誤、關閉代碼、中斷原因、訊息解析錯誤、心跳逾時、後端節點ID和重連模式。