一、WebSocket 是什么？
WebSocket 是一种在单个 TCP 连接上进行全双工通信的网络协议，由 IETF（互联网工程任务组）于 2011 年标准化为 RFC 6455。它由 HTML5 推出，旨在解决传统 HTTP 协议在实时通信场景中的性能瓶颈。
✅ 一句话定义：
WebSocket 是一种持久化、双向、低延迟的通信协议，允许客户端与服务器在建立连接后，无需重复握手，持续互相发送数据。
🌐 协议标识
- URL Scheme：
ws://（明文） 或wss://（加密，基于 TLS） - 默认端口：
80（ws） /443（wss） - 底层传输：基于 TCP（与 HTTP 相同）
二、WebSocket 的核心作用
WebSocket 的诞生是为了解决 Web 应用中实时双向通信的痛点。传统 HTTP 协议是“请求-响应”模式，无法满足以下场景：
| 场景 | HTTP 的缺陷 | WebSocket 的优势 |
|---|---|---|
| 实时聊天 | 客户端需轮询服务器（每秒多次请求），浪费带宽和资源 | 服务器可主动推送消息，零轮询 |
| 股票行情 | 每秒数百次数据更新，HTTP 轮询造成服务器压力巨大 | 一条连接，持续推送，效率提升 90%+ |
| 在线游戏 | 玩家动作需秒级同步，HTTP 延迟高、丢包率高 | 低延迟（<50ms）、双向实时同步 |
| 实时协作编辑 | 多人同时编辑文档，需即时同步光标、内容 | 事件实时广播，无延迟 |
| 物联网监控 | 设备状态每秒上报，服务器需下发指令 | 一对多、双向指令通道 |
✅ WebSocket 的四大核心作用：
- 实现真正的双向通信：客户端和服务器可随时主动发送数据，无需等待对方请求。
- 大幅降低网络开销：避免 HTTP 每次请求携带大量头部（如 Cookie、User-Agent），连接建立后仅传输有效负载。
- 减少服务器压力：消除频繁轮询，一个连接服务成千上万客户端。
- 支持低延迟实时交互：适用于金融、游戏、直播、IoT 等对时间敏感的系统。
三、WebSocket 的核心特点
| 特性 | 说明 |
|---|---|
| ✅ 全双工通信 | 客户端和服务器可同时发送和接收数据，互不阻塞。 |
| ✅ 持久连接 | 一次握手后，TCP 连接保持打开，直到任意一方主动关闭（可长达数小时甚至数天）。 |
| ✅ 低延迟 | 数据传输无需重复 HTTP 头部，最小帧开销仅 2 字节（控制帧），平均延迟 < 10ms。 |
| ✅ 基于 TCP | 继承 TCP 的可靠性、有序性、流量控制，数据不会丢失或错序。 |
| ✅ 协议升级机制 | 通过 HTTP/1.1 的 Upgrade 机制从 HTTP 升级为 WebSocket，兼容现有网络基础设施（代理、防火墙）。 |
| ✅ 支持文本与二进制 | 可传输 UTF-8 文本（JSON、XML）或二进制数据（图片、音频、视频流）。 |
| ✅ 支持跨域 | 通过 CORS 机制控制跨域访问（需服务端显式允许）。 |
| ✅ 支持心跳机制 | 可通过 Ping/Pong 帧检测连接状态，自动断线重连。 |
| ✅ 浏览器原生支持 | 所有现代浏览器（Chrome、Firefox、Safari、Edge、iOS/Android WebView）均原生支持 WebSocket API。 |
📌 重要补充：WebSocket 不是“HTTP 替代品”
- WebSocket 不是用来替代 HTTP 的。
- 它是 HTTP 的补充，专门用于持续、高频、双向的数据交换。
- HTTP 仍用于：页面加载、API 调用、文件下载等“一次请求-响应”场景。
- WebSocket 用于：聊天、推送、监控、游戏等“持续通信”场景。
四、HTTP 与 WebSocket 对比详解（表格 + 图文说明）
| 对比维度 | HTTP（传统） | WebSocket |
|---|---|---|
| 通信模式 | 单向请求-响应 客户端发起请求 → 服务器响应 → 连接关闭 | 双向全双工 连接建立后，双方可随时主动发送数据，无请求/响应限制 |
| 连接生命周期 | 短连接 每次请求新建 TCP 连接（HTTP/1.1 可复用，但有限） | 长连接 一次握手后连接持续保持，可长达数小时甚至永久 |
| 数据开销 | 高 每次请求携带大量 HTTP 头部（ Host, Cookie, User-Agent, Accept 等，通常 > 500 字节） | 极低 建立连接后，每条消息仅需 2–14 字节 开销（帧头） |
| 实时性 | 差 依赖轮询（Polling）或长轮询（Long Polling），延迟高（秒级） | 极佳 服务器可即时推送，延迟通常 < 50ms |
| 服务器资源消耗 | 高 每秒数百次请求 → 每次都要建立/关闭连接，消耗 CPU、内存、端口 | 极低 一个连接服务大量客户端，连接数少，资源占用少 |
| 适用场景 | 页面加载、REST API、文件下载、表单提交 | 实时聊天、股票行情、在线游戏、协作编辑、IoT 设备监控、直播弹幕 |
| 协议升级 | 无 | 基于 HTTP/1.1 的 Upgrade: websocket 机制，从 HTTP 升级而来，兼容代理和防火墙 |
| 握手过程 | 无 | 首次握手为 HTTP 请求： 客户端发送： GET /chat HTTP/1.1 + Upgrade: websocket + Sec-WebSocket-Key服务器响应： 101 Switching Protocols + Sec-WebSocket-Accept握手成功后，协议从 HTTP 切换为 WebSocket |
| 数据格式 | 文本（JSON/XML）或二进制（multipart） | 支持文本帧（UTF-8）和二进制帧（任意字节流） |
| 错误处理 | 依赖 HTTP 状态码（404、500 等） | 依赖关闭帧（Close Frame）和错误码（1000–1015） |
| 浏览器 API | fetch(), XMLHttpRequest | new WebSocket(url) |
| 是否支持推送 | ❌ 不支持（需客户端轮询） | ✅ 完全支持（服务器可主动推送） |
| 防火墙/代理兼容性 | 极高（标准 HTTP 端口） | 高（基于 HTTP 升级，绝大多数代理支持） |
| 安全性 | 支持 HTTPS（TLS） | 支持 WSS（WebSocket Secure，基于 TLS） |
五、HTTP 轮询 vs WebSocket：性能对比示意图
📈 场景：每秒 10 次数据更新（如股票行情）
| 方案 | 每秒请求数 | 每次请求大小 | 总带宽消耗（估算） | 服务器并发连接数 |
|---|---|---|---|---|
| HTTP 轮询 | 10 次 | 1.2 KB（含头部） | 12 KB/s | 10 个（每个请求一个连接） |
| HTTP 长轮询 | 1 次（保持连接） | 1.2 KB（首次）+ 0.5 KB（响应） | 1.7 KB/s | 1 个（但需维持大量空闲连接） |
| WebSocket | 0 次（无请求） | 10 条消息 × 10 字节 | 0.1 KB/s | 1 个（永久连接） |
💡 结论：WebSocket 在实时场景下，带宽节省 90%+，服务器负载降低 95%+。
六、WebSocket 握手流程详解（图文）
1️⃣ 客户端发起 HTTP 升级请求
GET /chat HTTP/1.1
Host: example.com
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Connection: Upgrade：请求协议升级Upgrade: websocket：指定升级为 WebSocket 协议Sec-WebSocket-Key：客户端生成的随机 Base64 字符串，用于服务端验证Sec-WebSocket-Version: 13：协议版本（RFC 6455）
2️⃣ 服务端响应 101 状态码（协议切换）
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
101 Switching Protocols：表示协议切换成功Sec-WebSocket-Accept：服务端对Sec-WebSocket-Key进行 SHA-1 + Base64 计算后的值（用于防伪造）
🔐 计算公式：
Sec-WebSocket-Accept = Base64(SHA-1(Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))
3️⃣ 握手成功 → 进入 WebSocket 通信阶段
握手完成后，TCP 连接不再使用 HTTP 协议，而是切换为 WebSocket 二进制帧协议：
[客户端] ←─────── TCP 隧道 ───────→ [服务器]
↓ 二进制帧 (文本/二进制) ↓
✅ 持续双向通信，无协议开销
⚠️ 注意：握手阶段是 HTTP，通信阶段是 WebSocket，两者是“协议升级”关系，非并行。
七、WebSocket 与 HTTP 的典型使用场景对比
| 应用场景 | 推荐协议 | 原因 |
|---|---|---|
| 加载网页（HTML/CSS/JS） | HTTP/HTTPS | 一次请求，获取静态资源，无需持续通信 |
| 用户登录（POST /login） | HTTP | 一次认证，返回 Token，符合 REST 设计 |
| 获取用户信息（GET /api/user） | HTTP | 状态无关，幂等操作，适合 REST |
| 实时聊天消息 | WebSocket | 需要服务器主动推送、低延迟、双向通信 |
| 股票价格实时更新 | WebSocket | 每秒数十次更新，HTTP 轮询会拖垮服务器 |
| 在线游戏（FPS） | WebSocket | 需要玩家位置、射击动作秒级同步 |
| 实时协作文档（光标同步） | WebSocket | 多人编辑，事件广播，毫秒级响应 |
| 服务器监控面板（CPU/内存） | WebSocket | 持续推送指标，避免浏览器频繁刷新 |
| 文件上传（大文件） | HTTP | 支持断点续传、分块上传，WebSocket 不适合大文件传输 |
| 推送通知（App/Web） | WebSocket + 服务端队列 | 可实现“在线推送”，离线存储后通过 APNs/FCM 补发 |
八、WebSocket 的局限性（需注意）
尽管 WebSocket 强大，但在某些场景下不适用：
| 局限 | 说明 |
|---|---|
| ❌ 不适合大文件传输 | 无断点续传、无分块机制，不如 HTTP 的 multipart/form-data 或 Range 请求 |
| ❌ 不适合缓存机制 | WebSocket 传输的数据无法被浏览器或 CDN 缓存 |
| ❌ 无标准认证机制 | 需自行在握手阶段传递 Token（如 URL 参数或自定义 Header） |
| ❌ 代理/防火墙限制 | 某些企业网络或老旧代理不支持 Upgrade 头，导致连接失败（可通过 SockJS 降级解决） |
| ❌ 无内置重连机制 | 客户端需自行实现断线重连逻辑 |
| ❌ 调试复杂 | 无法像 HTTP 那样用浏览器开发者工具直接查看“请求-响应”（需用 WebSocket 插件或 Wireshark） |
✅ 解决方案：
- 使用 SockJS 库自动降级为长轮询（兼容老环境）
- 使用 STOMP 协议封装 WebSocket，提供消息队列语义（推荐用于企业系统）
- 结合 Spring Boot + WebSocket + STOMP 实现生产级实时系统（见前文示例）
九、WebSocket 在现代架构中的地位
| 架构层级 | 技术选型 |
|---|---|
| 传输层 | TCP（WebSocket 基于 TCP） |
| 协议层 | WebSocket（RFC 6455） |
| 消息协议 | STOMP（Simple Text Oriented Messaging Protocol）或自定义 JSON |
| 服务端框架 | Spring Boot（spring-boot-starter-websocket）、Node.js（Socket.IO）、Netty、Go（gorilla/websocket） |
| 客户端 API | new WebSocket()（浏览器）、WebSocket（Node.js）、flutter_web_socket（Flutter） |
| 部署模式 | 单机、集群（需共享会话）、负载均衡（需 Sticky Session） |
| 云服务支持 | AWS API Gateway、Azure SignalR、腾讯云 WebSocket 网关 |
💡 行业趋势：
WebSocket 已成为现代 Web 实时应用的事实标准。
微信、钉钉、飞书、抖音、B站弹幕、京东购物车实时更新、阿里云监控系统等，全部基于 WebSocket 或其封装协议（如 STOMP、Socket.IO）。
十、总结：WebSocket 的核心价值
| 维度 | WebSocket 的优势 |
|---|---|
| 通信效率 | 一次连接，双向通信，零轮询，极致省带宽 |
| 实时性 | 服务器主动推送，延迟低至毫秒级 |
| 扩展性 | 一个连接服务万人，高并发场景下资源消耗极低 |
| 兼容性 | 基于 HTTP 升级，兼容现有网络设备 |
| 生态成熟 | Spring、Node.js、React、Vue 等主流框架深度支持 |
| 未来趋势 | IoT、5G、WebRTC、元宇宙等场景的通信基石 |
✅ 终极建议：
凡涉及“实时”、“双向”、“高频”、“低延迟” 的 Web 交互，优先选择 WebSocket。
凡涉及“一次性”、“无状态”、“可缓存” 的请求，继续使用 HTTP。
附录：WebSocket 与 HTTP 的通信流程对比图
┌─────────────────────┐ ┌─────────────────────┐
│ HTTP │ │ WebSocket │
├─────────────────────┤ ├─────────────────────┤
│ 1. 客户端发起请求 │ │ 1. 客户端发起 HTTP │
│ GET /api/user │ │ GET /ws │
│ 2. 服务器响应 │ │ 2. 服务器响应 101 │
│ 200 OK │ │ Upgrade: ws │
│ { "name": "张三" }│ │ Sec-WebSocket... │
│ 3. 连接关闭 │ │ 3. 协议升级成功 │
└─────────┬───────────┘ └─────────┬───────────┘
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ 下次请求需重连 │ │ 双向持续通信 │
│ 每次都带完整头 │ │ 发送：{"msg":"hi"} │
│ 带宽浪费严重 │ │ 接收：{"msg":"ok"} │
└─────────────────────┘ └─────────┬───────────┘
│
▼
┌─────────────────────┐
│ 无需重连，无头开销 │
│ 每秒可传输 1000+ 消息 │
└─────────────────────┘
📌 一句话总结 WebSocket 的革命性：
它让 Web 从“文档浏览时代”进入了“实时交互时代”。
✅ 推荐阅读与工具
| 工具 | 用途 |
|---|---|
| RFC 6455 | WebSocket 官方协议标准 |
| WebSocket.org | 官方教程与在线测试工具 |
| Postman | 支持 WebSocket 测试（新版） |
| Wireshark | 抓包分析 WebSocket 帧结构 |
| SockJS | WebSocket 降级库（兼容 IE9+） |
| STOMP over WebSocket | 企业级消息协议封装 |
🌟 结论：
WebSocket 不是“新技术”，而是“必需品”。
在现代 Web 开发中，不懂 WebSocket，就无法构建真正的实时应用。
掌握它，你将具备构建微信、钉钉、在线游戏、实时监控系统的核心能力！
本文档适用于：前端工程师、后端开发、架构师、技术负责人、技术面试官。
可作为团队技术规范、技术选型依据、面试题库使用。
扫一扫
902
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
