WebSocket

**WebSocket**
類型	網絡通信協議
標準	RFC 6455（IETF）
首次提出	2008年
標準化時間	2011年12月
傳輸層	TCP
設計目標	全雙工、低延遲實時通信
相關標準	RFC 7692、RFC 8441、RFC 9220

WebSocket是一種標準化的網絡通信協議，由IETF於2011年12月以RFC 6455正式發布為互聯網標準（STD 34）。^[1] 該協議在單個TCP連接上提供全雙工通信通道，允許客戶端與伺服器之間建立持久連接並進行雙向、低延遲的數據交換。^[2] 與HTTP的請求-響應模型不同，WebSocket在初始握手完成後，連接保持打開狀態，任何一方均可隨時發送消息，無需重複建立連接。^[3]

歷史

WebSocket的概念誕生於2008年，由Michael Carter牽頭發起技術討論，旨在解決當時瀏覽器端實時通信依賴Comet技術（輪詢與長輪詢）所帶來的效率低下與實現複雜等問題。^[4] 隨後，Ian Hickson與Michael Carter合作確定了"WebSocket"這一名稱，並將其納入HTML5規範草案中。^[4] 協議最初以"TCPConnection"為名，作為基於TCP的套接字API佔位方案出現。^[5]

2009年，Google Chrome 4成為首個完整支持WebSocket協議的瀏覽器。^[4] 2010年，該協議獲得主流瀏覽器的廣泛採納。2011年12月，IETF正式發布RFC 6455，將WebSocket協議標準化，定義了握手過程、數據幀格式、關閉握手及安全考量等內容。^[1] 此後，WebSocket擴展標準陸續出台：RFC 7692定義了基於deflate算法的逐消息壓縮機制；RFC 8441增加了通過HTTP/2引導WebSocket的能力；RFC 9220進一步將其擴展至HTTP/3。^[1] WebSocket API現由WHATWG HTML Living Standard定義，全球主流瀏覽器支持率超過99%。^[1]

技術特性

握手與連接升級

WebSocket連接始於一個HTTP升級請求。客戶端發送包含Upgrade: websocket及Connection: Upgrade頭部的HTTP請求，伺服器返回101 Switching Protocols狀態碼後，TCP連接即從HTTP協議切換至WebSocket協議。^[6] 握手過程中包含Sec-WebSocket-Key與Sec-WebSocket-Accept字段，用於防止跨協議攻擊與緩存投毒。^[6] 此設計使WebSocket能夠復用80與443端口，兼容現有HTTP基礎設施如防火牆、代理與負載均衡器。^[2]

數據幀與傳輸效率

握手完成後，通信轉為輕量級的WebSocket幀格式，而非完整的HTTP消息。^[2] 幀頭部開銷極小，支持文本（UTF-8）與二進制數據載荷，並可通過分片機制處理大消息。^[3] 控制幀用於ping、pong及連接關閉操作，使應用層可實現心跳檢測與斷連感知。^[2] 相比HTTP輪詢每次請求均附帶完整頭部，WebSocket在持續通信場景下顯著降低了帶寬消耗與協議開銷。^[3]

全雙工與伺服器推送

WebSocket的核心優勢在於全雙工通信能力。連接建立後，客戶端與伺服器均可獨立發送消息，無需等待對方請求。^[3] 伺服器可在事件發生的瞬間主動向客戶端推送數據，消除了輪詢模式下的固有延遲。^[2] 這一特性使WebSocket成為實時應用的基礎設施，涵蓋即時通訊、在線協作、實時數據儀錶盤及多人遊戲等場景。^[7]

與HTTP輪詢的比較

在WebSocket出現之前，瀏覽器端實時通信主要依賴HTTP輪詢（Polling）與長輪詢（Long Polling）。^[2] 輪詢模式下，客戶端以固定間隔重複發送HTTP請求檢查更新，即使無新數據也會產生大量冗餘請求與帶寬浪費。^[3] 長輪詢通過保持請求打開直至數據可用略有改善，但仍需反覆建立連接，並受代理超時限制。^[7]

WebSocket通過持久化單一連接解決了上述問題：無需重複TCP握手與TLS協商，消息僅在數據實際產生時傳輸，伺服器負載與實際使用量而非輪詢頻率成正比。^[2] 在延遲方面，輪詢的平均延遲約為輪詢間隔的一半，而WebSocket可將延遲降至網絡傳播與處理時間決定的亞百毫秒級別。^[3] 在擴展性方面，大規模輪詢系統因空請求泛濫而難以承受高並發；WebSocket雖需維護長連接狀態，但消息驅動的負載模式使其在同等用戶規模下資源利用更為高效。^[7]

擴展標準

壓縮擴展

RFC 7692定義了WebSocket的per-message deflate擴展，允許對單個消息應用deflate壓縮算法，減少文本類數據的傳輸體積。^[1] 該擴展在握手階段通過Sec-WebSocket-Extensions頭部協商啟用。

HTTP/2與HTTP/3引導

傳統WebSocket通過HTTP/1.1升級握手建立。RFC 8441引入了通過HTTP/2流引導WebSocket連接的機制，使WebSocket可在HTTP/2多路復用環境中運行。^[1] RFC 9220進一步將該機制擴展至基於QUIC的HTTP/3，為WebSocket在現代化傳輸協議上的部署提供了標準化路徑。^[1]

應用領域

WebSocket已成為實時Web應用的基礎協議。在金融領域，它被用於股票行情推送與交易平台；在協作軟件中，支持文檔協同編輯與光標同步；在物聯網與車聯網場景中，為設備狀態監控與充電基礎設施提供低延遲通信通道。^[4] 此外，在線遊戲、社交媒體動態流、直播彈幕系統及客戶服務聊天窗口等均廣泛採用WebSocket實現即時交互。^[7]

參考文獻

[:0-1] 1.0 ^1.1 ^1.2 ^1.3 ^1.4 ^1.5 ^1.6 WebSocket Standards: RFC 6455, Extensions & Browser Support - WebSocket.org

[:1-2] 2.0 ^2.1 ^2.2 ^2.3 ^2.4 ^2.5 ^2.6 WebSocket vs HTTP Polling - PieHost

[:2-3] 3.0 ^3.1 ^3.2 ^3.3 ^3.4 ^3.5 WebSockets vs HTTP: Key Differences Explained - Postman

[:3-4] 4.0 ^4.1 ^4.2 ^4.3 WebSockets: Real-Time Nervous System - YoCharge

[:4-5] 你不知道的 WebSocket - CSDN

[:5-6] 6.0 ^6.1 websocket協議和http協議有何依賴關係 - 博客園

[:6-7] 7.0 ^7.1 ^7.2 ^7.3 WebSocket vs Polling vs SSE — Choosing the Right Real-Time Strategy - Codelit

[1]

[2]

[3]

[4]

[5]

[6]

[7]