LGPL:修订间差异
创建页面,内容为“{{Infobox | 标题 = GNU宽通用公共许可证 | 内容 = {{!}}- ! 英文名 {{!}} GNU Lesser General Public License(GNU LGPL)<ref name=":1" /> {{!}}- ! 发布者 {{!}} 自由软件基金会(Free Software Foundation)<ref name=":2" /> {{!}}- ! 首次发布 {{!}} 1991年(版本2.0)<ref name=":0" /> {{!}}- ! 最新版本 {{!}} 版本3(2007年6月29日)<ref name=":4" /> {{!}}- ! 许可证类型 {{!}} Copyleft、自由软件许可证<r…” |
TeodoroSeccombe(留言 | 贡献) 小 创建页面,内容为“。” |
||
| 第1行: | 第1行: | ||
{{Infobox | {{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 /> | <references /> | ||