WebSocket 与 HTTP 有什么区别：从单向请求到全双工实时通信

01. 前言：为什么有了 HTTP 还需要 WebSocket？

HTTP 协议是 Web 的基石，但它有一个天生缺陷：只有客户端能主动发起请求，服务器只能被动响应。这种“一问一答”的模式，在需要实时推送的场景（聊天、股票行情、游戏、协作编辑）中显得力不从心。

传统解决方案（轮询、长轮询）要么浪费资源，要么延迟高。WebSocket应运而生——它在单个 TCP 连接上建立全双工通道，让服务器也能主动“说话”。

本文从协议设计、连接方式、通信模式、适用场景等角度，全面对比 WebSocket 与 HTTP。

02. 核心区别一句话总结

03. HTTP 的通信模式：请求-响应模型

3.1 传统 HTTP（短连接）

客户端 服务器 │ │ │──── 请求1（req1）───────────────────→│ │←──── 响应1（resp1）──────────────────│ │ │ │──── 请求2（req2）───────────────────→│ │←──── 响应2（resp2）──────────────────│ │ │ 每次请求需要重新建立 TCP 连接（HTTP 1.0） 或复用连接但仍是“一问一答”（HTTP 1.1+）

3.2 HTTP 轮询（模拟实时）

客户端 服务器 │ │ │──── 请求：有新消息吗？────────────→│ │←──── 响应：没有 ───────────────────│ │ （等待间隔，如 2 秒） │ │──── 请求：有新消息吗？────────────→│ │←──── 响应：没有 ───────────────────│ │ （重复，浪费资源） │

3.3 HTTP 长轮询（Long Polling，改进版）

客户端 服务器 │ │ │──── 请求：有新消息就回复我 ────────→│ │ │ （服务器hold住连接，不立即响应） │ │ （直到有新消息或超时） │←──── 响应：消息来了！ ─────────────│ │ │ │──── 再次发起长轮询请求 ───────────→│ （重复）

长轮询比短轮询好，但仍有缺陷：

• 每个消息需重新建立 HTTP 连接
• 服务器需维护大量挂起连接
• 头部开销大

04. WebSocket 的全双工通信

4.1 WebSocket 连接建立过程（HTTP 升级握手）

WebSocket 复用 HTTP 的Upgrade机制完成握手：

客户端 服务器 │ │ │──── HTTP GET 请求（Upgrade: websocket）───→│ │ GET /chat HTTP/1.1 │ │ Host: example.com │ │ Upgrade: websocket │ │ Connection: Upgrade │ │ Sec-WebSocket-Key: x3JJ... │ │ Sec-WebSocket-Version: 13 │ │ │ │←──── HTTP 101 Switching Protocols ──────────│ │ HTTP/1.1 101 Switching Protocols │ │ Upgrade: websocket │ │ Connection: Upgrade │ │ Sec-WebSocket-Accept: HSmrc... │ │ │ │ ========== 协议升级完成 ========== │ │ │ │←──── 服务器主动推送消息（帧）────────────────│ │──── 客户端发送消息（帧）────────────────────→│ │←──── 服务器再发一条─────────────────────────│ │──── 客户端再发一条──────────────────────────→│ │ （全双工，任意时刻互发） │

4.2 WebSocket 通信模式

建立连接后： 客户端 ──────────────────────────────→ 服务器 ↑ ↓ └──────────── 全双工通道 ────────────────┘ 特点： - 双方随时可以发送消息 - 消息以帧（Frame）为单位，帧头很小（2~14 字节） - 连接保持，直到一方主动关闭

05. 详细对比：WebSocket vs HTTP

5.1 连接建立与维护

5.2 数据传输

5.3 协议开销对比示例

场景：发送 10 条短消息 HTTP 轮询（每次独立连接）： 10 × (TCP 握手 + HTTP 头 + 消息体 + 挥手) ≈ 巨大开销 HTTP 长轮询（每次消息需新连接）： 10 × (HTTP 头 + 消息体) ≈ 几千字节开销 WebSocket： 1 × (HTTP 握手) + 10 × (帧头 ~6 字节 + 消息体) ≈ 一次握手的开销 + 每消息几十字节帧头

5.4 适用场景对比

06. WebSocket 帧结构简介

WebSocket 帧格式（简化）： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - -+ | Extended payload length continued, if payload len == 126 | +-------------------------------+-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Data | +---------------------------------------------------------------+ 关键字段： - FIN：是否为最后一帧 - opcode：文本(0x1)/二进制(0x2)/关闭(0x8)/Ping(0x9)/Pong(0xA) - Mask：客户端→服务器必须置1（掩码）

07. WebSocket 与 HTTP/2 的关系

很多人会问：HTTP/2 已经支持多路复用和服务器推送了，还需要 WebSocket 吗？

结论：HTTP/2 的服务器推送是“一个请求带多个响应”，而非服务器随时主动发消息。WebSocket 在实时双向通信上仍然不可替代。

08. 何时使用 WebSocket？

✅ 适合 WebSocket 的场景

• 即时通讯（微信网页版、Slack）
• 实时数据推送（股票、体育比分、物联网传感器）
• 多人协作（Figma、Google Docs）
• 在线游戏（棋牌、射击游戏）
• 实时日志/监控面板

❌ 不适合 WebSocket 的场景

• 简单的 CRUD API（用 REST + HTTP 更简单）
• 静态资源加载（图片、CSS、JS）
• 需要缓存、CDN 加速的内容
• 单向通知（SSE 更轻量）

09. 完整选择决策流程图

是否需要服务器主动推送消息？ │ ├── 否 ──────────────────────────────────→ 使用 HTTP │ └── 是 │ ▼ 实时性要求多高？ │ ├── 秒级以内（聊天、游戏、交易）────────→ WebSocket │ └── 秒级到分钟级（通知、订阅） │ ▼ 是否只需要服务器→客户端单向推送？ │ ├── 是 ──────────────────────────────────→ SSE（Server-Sent Events） │ （比 WebSocket 更简单） └── 否（需要客户端也能主动发）────────────→ WebSocket 附加考虑： - 现有基础设施：是否有 WebSocket 负载均衡支持？ - 客户端兼容性：IE 10 以下不支持 - 降级方案：能否回退到长轮询？

10. 对比总结表

11. 代码示例（极简对比）

HTTP 轮询（前端）

// 每 2 秒询问一次setInterval(async()=>{constres=awaitfetch('/api/messages');constdata=awaitres.json();console.log('新消息:',data);},2000);

WebSocket（前端）

constws=newWebSocket('wss://example.com/chat');ws.onmessage=(event)=>{console.log('收到服务器推送:',event.data);};// 发送消息ws.send('Hello Server');

12. 常见问题

Q1：WebSocket 能穿透代理和防火墙吗？

• HTTP/HTTPS 代理：ws://可能被拦截，wss://（TLS 加密）通常可以穿透。
• 企业防火墙：可能主动阻断非标准流量，需配置允许。

Q2：WebSocket 和 Socket（TCP Socket）有什么区别？

• WebSocket 是应用层协议，基于 HTTP 握手，运行在 80/443 端口，浏览器原生支持。
• TCP Socket 是传输层，无法直接在浏览器中使用（除非使用 WebRTC 数据通道）。

Q3：WebSocket 连接能保持多久？

• 理论上无限，但实际受网络中间设备（NAT、负载均衡）超时影响，需定期发送 Ping/Pong 保活。

Q4：WebSocket 安全吗？

• wss://相当于 HTTPS，使用 TLS 加密，安全。
• ws://是明文，不安全。

13. 总结

┌─────────────────────────────────────────────────────────────┐ │ HTTP vs WebSocket 核心口诀 │ ├─────────────────────────────────────────────────────────────┤ │ HTTP 像打电话：你问一句，我答一句，我不主动找你 │ │ WebSocket 像拉群：随时说话，双方都能主动发消息 │ │ │ │ 看网页用 HTTP，搞实时用 WebSocket │ │ 普通 API 用 HTTP，聊天游戏用 WebSocket │ │ 单向推送考虑 SSE，双向全双工上 WebSocket │ └─────────────────────────────────────────────────────────────┘

最终建议：

• 默认使用 HTTP，简单、无状态、易缓存
• 遇到实时双向通信需求（聊天、行情、协作），果断上 WebSocket
• 如果只是服务器单向推送（通知、订阅），SSE 可能是更轻量的选择