为什么浏览器侧需要它
HTTP 的交互由客户端发起，服务端无法主动推送，长轮询与流式响应都只是变通做法。WebSocket 通过一次 HTTP 升级握手把同一条连接转为双向通道，之后双方都能随时发送消息，帧开销远低于重复请求。在物联网架构里它通常出现在最后一公里：平台把设备数据推给浏览器或移动端。
基本信息
| 握手方式 | 借用 HTTP 请求携带升级头完成协议切换 |
|---|---|
| 端口与地址 | 复用 HTTP 或 HTTPS 端口，地址方案区分加密与非加密 |
| 数据帧 | 文本帧与二进制帧，另有控制帧用于心跳与关闭 |
| 心跳 | 协议提供 ping 与 pong 控制帧，用于检测链路是否可用 |
| 部署要点 | 中间的反向代理与安全设备需要支持升级与长连接 |
推送方案对照
| 方案 | 实时性 | 开销 | 穿透性 |
|---|---|---|---|
| 短轮询 | 取决于轮询间隔 | 请求数随频率线性增长 | 最好，普通 HTTP 即可 |
| 长轮询 | 较好 | 每次事件一次请求，服务端连接占用高 | 好 |
| WebSocket | 好，服务端可即时推送 | 一次握手后帧开销小 | 较好，需中间设备支持升级 |
典型使用场景
- 监控大屏：设备数据实时刷新，避免页面定时轮询
- 移动端推送展示：App 内保持一条长连接接收更新
- 配置下发回执：管理界面需要即时反馈执行结果
- 受限网络穿透：部分企业网络只放行 Web 端口，可借此传输消息
WebSocket 只提供传输通道，不提供消息语义：订阅关系、离线补发与去重都要在应用层自行设计，或在其之上再承载消息协议。
连接空闲时间过长时，中间设备可能静默回收连接而不通知双方，必须靠心跳与自动重连把这种断裂暴露出来。
与应用层的关系
WebSocket 只是传输通道，浏览器侧通常还需要一套轻量的应用消息格式来定义订阅、取消与错误回执，否则业务语义会散落在前后端各自的约定里，后续难以演进。