WebSocket 是一种基于 TCP 的全双工通信网络应用层协议，由 IETF 在 2011 年以 RFC 6455 标准正式发布，核心解决了 HTTP 协议只能「客户端发起、服务端响应」的单向通信固有局限，实现了客户端与服务端之间低延迟、持久化、双向自由的数据传输。
一、为什么需要 WebSocket？（核心背景）
传统 HTTP 协议是请求 - 响应的单向模式，通信只能由客户端主动发起，服务端无法主动向客户端推送数据。为了实现「服务端主动推消息」的实时性需求，早期只能用两种低效方案：
- 短轮询：客户端定时频繁发送 HTTP 请求，询问服务端是否有新数据。缺点是大量无效请求，严重浪费带宽和服务器资源，数据延迟高。
- 长轮询：客户端发送请求后，服务端 hold 住连接，有数据才返回，返回后客户端立刻重发请求。缺点是依然依赖 HTTP，连接频繁断开重连，高并发下服务端连接压力极大，实时性仍有瓶颈。
WebSocket 正是为了彻底解决这些痛点而生，专为实时双向通信场景设计。
二、核心工作原理
WebSocket 通信分为两个核心阶段，完美兼容现有网络基础设施：
- 握手阶段（复用 HTTP） ：客户端先发送一个携带
Upgrade: websocket请求头的 HTTP GET 请求，向服务端申请协议升级；服务端验证通过后，返回101 Switching Protocols响应，握手完成。 - 数据传输阶段（脱离 HTTP） ：握手成功后，底层 TCP 连接持续保持打开状态，客户端和服务端可以随时、双向、对等地发送数据，不再需要 HTTP 的请求 - 响应格式，数据以最小仅 2 字节的轻量级帧（Frame）传输，直到任意一方主动关闭连接。
三、核心关键特性
表格
| 特性 | 核心说明 |
|---|---|
| 全双工双向通信 | 客户端和服务端可同时双向发送数据，彻底摆脱 HTTP 单向请求限制，实现真正的对等通信 |
| 持久化长连接 | 一次握手，连接持续保持，避免了 HTTP 每次请求的 TCP 三次握手、四次挥手开销，大幅降低传输延迟 |
| 极低传输开销 | HTTP 请求每次需携带完整 Header（几十到几百字节），WebSocket 数据帧头部最小仅 2 字节，高并发下带宽占用优势极其明显 |
| 原生跨域支持 | 协议内置跨域能力，无需像 HTTP 那样配置复杂的 CORS 规则，天然适配多域名业务场景 |
| 灵活数据格式 | 同时支持文本帧（UTF-8 字符串）和二进制帧（Blob/ArrayBuffer），可传输文本、音视频、文件等任意类型数据 |
| 高兼容性 | 握手复用 HTTP，默认端口与 HTTP 一致（ws://用 80 端口，加密wss://用 443 端口），不会被防火墙、代理服务器拦截，部署门槛极低 |
四、核心用处（典型应用场景）
只要是需要服务端主动推送、低延迟双向实时通信的场景，WebSocket 都是最优解，核心落地场景包括：
-
即时通讯（IM）系统这是 WebSocket 最核心的应用场景，覆盖个人聊天、群聊、企业办公消息、在线客服系统等。服务端可毫秒级将消息推送给接收方，完全替代低效的轮询方案，微信网页版、钉钉、企业微信等主流产品均深度依赖 WebSocket。
-
实时数据看板与监控典型场景包括股票 / 加密货币行情、服务器运维监控大屏、物流实时轨迹、赛事比分直播。这类场景需要服务端持续推送高频更新的数据，WebSocket 以极低的开销实现毫秒级数据刷新，避免轮询带来的性能浪费和延迟。
-
多人在线协同办公工具比如腾讯文档、飞书文档、Figma 等多人实时协同编辑产品。多个用户同时编辑时，需要将每个用户的操作实时同步给所有在线成员，WebSocket 的双向低延迟传输，是实现多人无感知实时协同的核心技术基础。
-
在线互动游戏尤其是网页端 / 小程序端的实时对战游戏、休闲游戏。这类场景对延迟极其敏感，需要客户端和服务端高频同步操作与游戏状态，WebSocket 的全双工长连接可稳定实现低延迟状态同步，是 H5 游戏的主流网络通信方案。
-
直播互动场景覆盖直播弹幕、礼物打赏实时特效、在线连麦互动等。海量用户的互动消息需要实时广播给全直播间用户，WebSocket 可高效实现服务端消息广播，保障互动的实时性和流畅性。
-
物联网（IoT）设备通信智能家居、工业物联网设备的状态上报与远程控制。设备端可通过 WebSocket 与云端保持长连接，实时上报设备状态，云端也可随时下发控制指令，替代传统 HTTP 轮询，大幅降低设备的功耗和网络开销。
-
实时位置共享网约车、外卖配送、共享位置导航等场景，需要持续同步用户 / 骑手 / 司机的实时位置，WebSocket 可稳定实现位置数据的双向实时传输，保障位置更新的及时性。
补充说明
- WebSocket 不是 HTTP 的替代，而是 HTTP 的补充：仅在握手阶段复用 HTTP 通道，握手完成后完全脱离 HTTP 协议，走独立的 TCP 数据传输。
- 与 SSE（Server-Sent Events）的核心区别：SSE 是基于 HTTP 的服务端单向推送，只能服务端给客户端发数据；而 WebSocket 是全双工双向通信，功能更全面，适配场景更广。
- 结合你之前关注的 Netty：Java 生态中，Netty 内置了完整的 WebSocket 协议实现，封装了握手、编解码、心跳检测、断连重连等所有底层细节，是企业级 WebSocket 服务端开发的首选方案，绝大多数大规模 WebSocket 集群均基于 Netty 构建。