IdleTap-bot：由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

2026-08-11T10:29:38Z

由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

←上一版本		2026年8月11日 (二) 10:29的版本
（没有差异）

IdleTap-bot：由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

2026-08-11T10:28:12Z

由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

←上一版本	2026年8月11日 (二) 10:28的版本
（没有差异）

IdleTap-bot：由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

2026-08-11T10:27:24Z

由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

←上一版本		2026年8月11日 (二) 10:27的版本
第1行：		第1行：
	{{Infobox		{{Infobox
	\| 标题 = [[Web]]Socket		\| title = [[Web]]Socket
	\| 内容 =
	~~{{!}}-~~		\| label1 = 类型
	! 类型		\| data1 = 网络通信协议
	~~{{!}}~~ 网络通信协议
	~~{{!}}-~~		\| label2 = 标准
	! 标准		\| data2 = RFC 6455（IETF）
	~~{{!}}~~ RFC 6455（IETF）
	~~{{!}}-~~		\| label3 = 首次提出
	! 首次提出		\| data3 = 2008年
	~~{{!}}~~ 2008年
	~~{{!}}-~~		\| label4 = 标准化时间
	! 标准化时间		\| data4 = 2011年12月
	~~{{!}}~~ 2011年12月
	~~{{!}}-~~		\| label5 = 传输层
	! 传输层		\| data5 = [[TCP]]
	~~{{!}}~~ [[TCP]]
	~~{{!}}-~~		\| label6 = 设计目标
	! 设计目标		\| data6 = 全双工、低延迟实时通信
	~~{{!}}~~ 全双工、低延迟实时通信
	~~{{!}}-~~		\| label7 = 相关标准
	! 相关标准		\| data7 = RFC 7692、RFC 8441、RFC 9220
	~~{{!}}~~ RFC 7692、RFC 8441、RFC 9220
	}}		}}

第37行：		第36行：
	=== 握手与连接升级 ===		=== 握手与连接升级 ===

	WebSocket连接始于一个HTTP升级请求。客户端发送包含Upgrade: websocket及Connection: Upgrade头部的HTTP请求，服务器返回101 Switching Protocols状态码后，TCP连接即从HTTP协议切换至WebSocket协议。<ref name=":5">[https://www.cnblogs.com/imust2008/p/19561979 websocket协议和http协议有何依赖关系 - 博客园]</ref> 握手过程中包含Sec-WebSocket-Key与Sec-WebSocket-Accept字段，用于防止跨协议攻击与缓存投毒。<ref name=":5" /> 此设计使WebSocket能够复用80与443端口，兼容现有HTTP基础设施如防火墙、代理与负载均衡器。<ref name=":1" />		WebSocket连接始于一个HTTP升级请求。客户端发送包含Upgrade: websocket及Connection: Upgrade头部的HTTP请求，服务器返回101 Switching Protocols状态码后，TCP连接即从HTTP协议切换至WebSocket协议。<ref name=":5">[https://www.cnblogs.com/imust2008/p/19561979 websocket协议和http协议有何依赖关系 - 博客园]</ref> 握手过程中包含Sec-WebSocket-Key与Sec-WebSocket-Accept字段，用于防止跨协议攻击与[[缓存]]投毒。<ref name=":5" /> 此设计使WebSocket能够复用80与443端口，兼容现有HTTP基础设施如防火墙、代理与负载均衡器。<ref name=":1" />

	=== 数据帧与传输效率 ===		=== 数据帧与传输效率 ===

云云：创建页面，内容为“ {{Infobox | 标题 = WebSocket | 内容 = {{!}}- ! 类型 {{!}} 网络通信协议 {{!}}- ! 标准 {{!}} RFC 6455（IETF） {{!}}- ! 首次提出 {{!}} 2008年 {{!}}- ! 标准化时间 {{!}} 2011年12月 {{!}}- ! 传输层 {{!}} TCP {{!}}- ! 设计目标 {{!}} 全双工、低延迟实时通信 {{!}}- ! 相关标准 {{!}} RFC 7692、RFC 8441、RFC 9220 }} '''WebSocket'''是一种标准化的网络通信协议，由IETF于2011年12月以RFC 6455正式发布为…”

2026-07-22T03:54:30Z

创建页面，内容为“ {{Infobox | 标题 = WebSocket | 内容 = {{!}}- ! 类型 {{!}} 网络通信协议 {{!}}- ! 标准 {{!}} RFC 6455（IETF） {{!}}- ! 首次提出 {{!}} 2008年 {{!}}- ! 标准化时间 {{!}} 2011年12月 {{!}}- ! 传输层 {{!}} TCP {{!}}- ! 设计目标 {{!}} 全双工、低延迟实时通信 {{!}}- ! 相关标准 {{!}} RFC 7692、RFC 8441、RFC 9220 }} '''WebSocket'''是一种标准化的网络通信协议，由IETF于2011年12月以RFC 6455正式发布为…”

新页面

{{Infobox
| 标题 = [[Web]]Socket
| 内容 =
{{!}}-
! 类型
{{!}} 网络通信协议
{{!}}-
! 标准
{{!}} RFC 6455（IETF）
{{!}}-
! 首次提出
{{!}} 2008年
{{!}}-
! 标准化时间
{{!}} 2011年12月
{{!}}-
! 传输层
{{!}} [[TCP]]
{{!}}-
! 设计目标
{{!}} 全双工、低延迟实时通信
{{!}}-
! 相关标准
{{!}} RFC 7692、RFC 8441、RFC 9220
}}

'''WebSocket'''是一种标准化的网络通信协议，由IETF于2011年12月以RFC 6455正式发布为[[互联网]]标准（STD 34）。<ref name=":0">[https://websocket.org/standards/ WebSocket Standards: RFC 6455, Extensions & Browser Support - WebSocket.org]</ref> 该协议在单个TCP连接上提供全双工通信通道，允许客户端与[[服务器]]之间建立持久连接并进行双向、低延迟的[[数据]]交换。<ref name=":1">[https://piehost.com/websocket/websocket-vs-http-polling WebSocket vs HTTP Polling - PieHost]</ref> 与[[HTTP]]的请求-响应模型不同，WebSocket在初始握手完成后，连接保持打开状态，任何一方均可随时发送消息，无需重复建立连接。<ref name=":2">[https://blog.postman.com/websockets-vs-http-key-differences-explained/ WebSockets vs HTTP: Key Differences Explained - Postman]</ref>

== 历史 ==

WebSocket的概念诞生于2008年，由Michael Carter牵头发起技术讨论，旨在解决当时[[浏览器]]端实时通信依赖Comet技术（轮询与长轮询）所带来的效率低下与实现复杂等问题。<ref name=":3">[https://yocharge.com/blog/websockets-real-time-nervous-system-connecting-ev-chargers-in-modern-charging-infrastructure/ WebSockets: Real-Time Nervous System - YoCharge]</ref> 随后，Ian Hickson与Michael Carter合作确定了"WebSocket"这一名称，并将其纳入[[HTML]]5规范草案中。<ref name=":3" /> 协议最初以"TCPConnection"为名，作为基于TCP的套接字API占位方案出现。<ref name=":4">[https://www.cnblogs.com/FreakEmbedded/p/19865128 你不知道的 WebSocket - CSDN]</ref>

2009年，[[Google]] [[Chrome]] 4成为首个完整支持WebSocket协议的浏览器。<ref name=":3" /> 2010年，该协议获得主流浏览器的广泛采纳。2011年12月，IETF正式发布RFC 6455，将WebSocket协议标准化，定义了握手过程、数据帧格式、关闭握手及安全考量等内容。<ref name=":0" /> 此后，WebSocket扩展标准陆续出台：RFC 7692定义了基于deflate算法的逐消息压缩机制；RFC 8441增加了通过HTTP/2引导WebSocket的能力；RFC 9220进一步将其扩展至HTTP/3。<ref name=":0" /> WebSocket API现由WHATWG HTML Living Standard定义，[[全球]]主流浏览器支持率超过99%。<ref name=":0" />

== 技术特性 ==

=== 握手与连接升级 ===

WebSocket连接始于一个HTTP升级请求。客户端发送包含Upgrade: websocket及Connection: Upgrade头部的HTTP请求，服务器返回101 Switching Protocols状态码后，TCP连接即从HTTP协议切换至WebSocket协议。<ref name=":5">[https://www.cnblogs.com/imust2008/p/19561979 websocket协议和http协议有何依赖关系 - 博客园]</ref> 握手过程中包含Sec-WebSocket-Key与Sec-WebSocket-Accept字段，用于防止跨协议攻击与缓存投毒。<ref name=":5" /> 此设计使WebSocket能够复用80与443端口，兼容现有HTTP基础设施如防火墙、代理与负载均衡器。<ref name=":1" />

=== 数据帧与传输效率 ===

握手完成后，通信转为轻量级的WebSocket帧格式，而非完整的HTTP消息。<ref name=":1" /> 帧头部开销极小，支持[[文本]]（UTF-8）与[[二进制]]数据载荷，并可通过分片机制处理大消息。<ref name=":2" /> 控制帧用于ping、pong及连接关闭操作，使应用层可实现心跳检测与断连感知。<ref name=":1" /> 相比HTTP轮询每次请求均附带完整头部，WebSocket在持续通信场景下显著降低了带宽消耗与协议开销。<ref name=":2" />

=== 全双工与服务器推送 ===

WebSocket的核心优势在于全双工通信能力。连接建立后，客户端与服务器均可独立发送消息，无需等待对方请求。<ref name=":2" /> 服务器可在事件发生的瞬间主动向客户端推送数据，消除了轮询模式下的固有延迟。<ref name=":1" /> 这一特性使WebSocket成为实时应用的基础设施，涵盖即时通讯、在线协作、实时数据仪表盘及多人游戏等场景。<ref name=":6">[https://codelit.io/blog/websocket-vs-polling-vs-sse WebSocket vs Polling vs SSE — Choosing the Right Real-Time Strategy - Codelit]</ref>

== 与HTTP轮询的比较 ==

在WebSocket出现之前，浏览器端实时通信主要依赖HTTP轮询（Polling）与长轮询（Long Polling）。<ref name=":1" /> 轮询模式下，客户端以固定间隔重复发送HTTP请求检查更新，即使无新数据也会产生大量冗余请求与带宽浪费。<ref name=":2" /> 长轮询通过保持请求打开直至数据可用略有改善，但仍需反复建立连接，并受代理超时限制。<ref name=":6" />

WebSocket通过持久化单一连接解决了上述问题：无需重复TCP握手与[[TLS]]协商，消息仅在数据实际产生时传输，服务器负载与实际使用量而非轮询频率成正比。<ref name=":1" /> 在延迟方面，轮询的平均延迟约为轮询间隔的一半，而WebSocket可将延迟降至网络传播与处理时间决定的亚百毫秒级别。<ref name=":2" /> 在扩展性方面，大规模轮询系统因空请求泛滥而难以承受高并发；WebSocket虽需维护长连接状态，但消息驱动的负载模式使其在同等[[用户]]规模下资源利用更为高效。<ref name=":6" />

== 扩展标准 ==

=== 压缩扩展 ===

RFC 7692定义了WebSocket的per-message deflate扩展，允许对单个消息应用deflate压缩算法，减少文本类数据的传输体积。<ref name=":0" /> 该扩展在握手阶段通过Sec-WebSocket-Extensions头部协商启用。

=== HTTP/2与HTTP/3引导 ===

传统WebSocket通过HTTP/1.1升级握手建立。RFC 8441引入了通过HTTP/2流引导WebSocket连接的机制，使WebSocket可在HTTP/2多路复用环境中运行。<ref name=":0" /> RFC 9220进一步将该机制扩展至基于QUIC的HTTP/3，为WebSocket在现代化传输协议上的部署提供了标准化路径。<ref name=":0" />

== 应用领域 ==

WebSocket已成为实时Web应用的基础协议。在金融领域，它被用于股票行情推送与交易平台；在协作[[软件]]中，支持文档协同编辑与光标同步；在物联网与车联网场景中，为设备状态监控与充电基础设施提供低延迟通信通道。<ref name=":3" /> 此外，在线游戏、社交媒体动态流、直播弹幕系统及客户服务聊天窗口等均广泛采用WebSocket实现即时交互。<ref name=":6" />

== 参考文献 ==

<references />

WebSocket - 版本历史

IdleTap-bot：​由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

IdleTap-bot：​由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

IdleTap-bot：​由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

IdleTap-bot：由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

IdleTap-bot：由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）

IdleTap-bot：由旧格式Infobox转换为新参数格式（label/data），修复空信息框（由IdleTap-bot执行）