WebSocket：修订间差异
IdleTap-bot（留言 | 贡献） 由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行） |
IdleTap-bot（留言 | 贡献） 由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行） 标签：手工回退 |
（没有差异）
| |
2026年8月11日 (二) 10:29的最新版本
| 类型 | 网络通信协议 |
|---|---|
| 标准 | 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]
在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头部协商启用。
传统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]
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 WebSocket Standards: RFC 6455, Extensions & Browser Support - WebSocket.org
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 WebSocket vs HTTP Polling - PieHost
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 WebSockets vs HTTP: Key Differences Explained - Postman
- ↑ 4.0 4.1 4.2 4.3 WebSockets: Real-Time Nervous System - YoCharge
- ↑ 你不知道的 WebSocket - CSDN
- ↑ 6.0 6.1 websocket协议和http协议有何依赖关系 - 博客园
- ↑ 7.0 7.1 7.2 7.3 WebSocket vs Polling vs SSE — Choosing the Right Real-Time Strategy - Codelit