有了 HTTP，为什么还需要 WebSocket？
前言
我们天天都在用 HTTP，但你一定见过这些场景：
- 聊天消息实时弹出
- 直播弹幕滚动
- 游戏画面实时同步
- 协同文档多人编辑
- 股票 / 行情实时刷新
这些用 HTTP 也能做，但又卡又费流量。于是 WebSocket 出现了。
本文用最直白的话讲清楚：HTTP 到底差在哪？WebSocket 好在哪？两者区别与适用场景。
一、先搞懂：HTTP 天生的 “短板”
HTTP 有两个无法改变的特性：
1. HTTP 是 单向通信
- 只能：客户端 → 服务端 发请求
- 服务端不能主动推消息给客户端
- 想拿新数据？必须客户端再发一次请求
2. HTTP 是 短连接、无状态
- 一次请求 = 一次响应 = 连接关闭
- 下一次又要重新建立连接
- 头部巨大、冗余、浪费流量
3. 实时需求 = HTTP 噩梦
想实时？只能用这几种笨办法：
① 轮询（Polling）
每隔 1s 发一次请求。
- 缺点：绝大多数请求无效，浪费服务器资源。
② 长轮询（Long Polling）
发请求 → 服务端挂起 → 有数据再返回。
- 缺点：还是 HTTP，还是单向，还是有开销。
结论：HTTP 天生不适合做 “实时、高频繁、双向” 通信。
二、WebSocket 是什么？
WebSocket 是一种全双工、长连接、基于 TCP 的应用层协议。
特点：
- 一次握手，永久连接
- 客户端 ↔ 服务端 双向自由发消息
- 服务端可以主动推送
- 头部极小，极省流量
- 真正实时、低延迟
三、HTTP 与 WebSocket 核心区别
1. 通信方式
- HTTP：单向客户端问，服务端答。
- WebSocket：全双工两边随时可以发消息。
2. 连接状态
- HTTP：短连接，请求完就断
- WebSocket：长连接，一直保持
3. 服务端能否主动推送
- HTTP：不能
- WebSocket：能
4. 开销
- HTTP：每次带大量 Header
- WebSocket：仅握手时带头部，后续极小
5. 适用场景
- HTTP：页面、接口、资源获取
- WebSocket：聊天、弹幕、游戏、实时数据、协同编辑
四、WebSocket 建立过程（极简原理）
WebSocket 是从 HTTP 升级上来的，不是新端口。
- 客户端发送 HTTP 请求，带上特殊头：
Connection: Upgrade
Upgrade: websocket
- 服务端返回 101 状态码：
101 Switching Protocols
- 协议切换成功 → TCP 长连接建立
- 之后再也不用 HTTP 那一套，直接双向传输数据
五、WebSocket 优点总结
- 真正实时推送
- 减少连接开销，一次握手永久使用
- 数据帧极轻量，没有冗余头部
- 全双工通信，两边都能主动发
- 跨域、兼容浏览器、成熟稳定
六、典型使用场景（一看就懂）
- 在线聊天（微信网页版、客服系统）
- 直播弹幕、礼物通知
- 实时游戏
- 股票 / 币价 / 实时排名
- 多人协同编辑（如腾讯文档）
- 后台日志实时推送
- 设备状态实时监控
七、误区澄清（非常重要）
❌ 错误：WebSocket 可以替代 HTTP
✅ 正确：两者互补，不是替代关系
- 页面、图片、接口、提交表单 → HTTP
- 实时消息、推送、高频繁通信 → WebSocket
❌ 错误：WebSocket 比 HTTP 更安全
✅ 正确：安全取决于是否用 wss（WebSocket + TLS）
- ws:// = 明文
- wss:// = 加密，对应 https
八、一句话总结
- HTTP：单向、短连接、被动响应，适合获取资源。
- WebSocket：双向、长连接、主动推送，适合实时通信。
- 有了 HTTP 为什么还要 WebSocket？因为 HTTP 做不到服务端主动推送，也做不到低成本实时通信。
