Http与WebSocket
WebSocket vs HTTP 的区别
WebSocket 和 HTTP 都是基于 TCP 的协议，但它们的设计目标和工作方式有很大区别。
1. HTTP 的特点
- 短连接（Stateless）：每个请求都是独立的，客户端发送请求，服务器处理后返回响应，连接就关闭。
- 单向通信：客户端主动请求，服务器被动响应，服务器 不能主动推送消息。
- 请求-响应模式：每次通信都要 带完整的 HTTP 头部，导致开销较大。
- 适用于：
- 普通网页访问（浏览器请求 HTML、CSS、JS）
- RESTful API 调用
- 需要短时交互的请求（如一次性数据获取）
HTTP 通信示例
GET /api/data HTTP/1.1
Host: example.com
服务器返回：
HTTP/1.1 200 OK
Content-Type: application/json{"data": "Hello, World!"}
2. WebSocket 的特点
- 长连接（Stateful）：建立连接后，客户端和服务器可以 持续通信，不会关闭连接。
- 双向通信：客户端和服务器都可以 主动发送 数据，不需要等请求。
- 低开销：初次建立 WebSocket 连接时，使用 HTTP 进行 握手，之后数据传输时 不再使用 HTTP 头部，减少带宽占用。
- 适用于：
- 实时数据推送（股票、行情、聊天）
- 多人在线协作（游戏、直播弹幕）
- 长时间保持连接的应用（IM 聊天、远程桌面）
WebSocket 连接示例
- 客户端发起 WebSocket 握手（基于 HTTP）
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9YZrdzR==
Sec-WebSocket-Version: 13
- 服务器响应
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
- 后续数据传输
- 客户端 主动发送 消息：
{"message": "Hello, Server!"}
- 服务器 **主动推送** 消息：
{"message": "Hello, Client!"}
3. 主要区别
| 对比项 | HTTP | WebSocket |
|---|---|---|
| 连接方式 | 短连接（每次请求都要新建连接） | 长连接（建立后可持续通信） |
| 通信方式 | 单向（客户端请求，服务器响应） | 双向（客户端和服务器都能主动发送数据） |
| 请求模式 | 请求-响应 | 事件驱动 |
| 服务器主动推送 | 不支持 | 支持 |
| 适用场景 | 网页、API（短时数据交互） | 实时应用（行情、聊天、游戏） |
| 传输开销 | 大（每次通信带 HTTP 头部） | 小（握手后只传数据） |
| 协议支持 | 所有浏览器支持 | 现代浏览器支持 |
4. 什么时候用 HTTP，什么时候用 WebSocket？
✅ 用 HTTP 的场景：
- 普通网页请求（HTML、CSS、JS、图片等）
- API 接口调用（如 RESTful API）
- 不需要实时通信，只需要获取一次性数据
✅ 用 WebSocket 的场景：
- 股票行情（实时价格更新）
- 在线聊天（双向即时通讯）
- 游戏服务器（玩家数据同步）
- 远程桌面、Web 远程控制
- 直播弹幕、协作编辑
5. 总结
- HTTP 是短连接，每次请求都要重新建立连接，适用于静态数据获取。
- WebSocket 是长连接，允许服务器主动推送数据，适用于实时交互的应用。
- WebSocket 先用 HTTP 进行握手，然后切换到 WebSocket 协议进行双向通信。
- 如果你的应用需要****低延迟、高频数据更新，比如 行情、IM、游戏，WebSocket 更合适。
http长连接
HTTP 也有长连接，但它和 WebSocket 的长连接完全不同。
1. HTTP 长连接（Keep-Alive）
是什么？
- HTTP 1.0 默认是 短连接，每次请求 都会新建 TCP 连接。
- HTTP 1.1 默认开启 Keep-Alive，允许 复用 TCP 连接，但仍然是 请求-响应模式。
- 长连接 ≠ 实时通信，只是 多个请求可以复用同一个 TCP 连接，减少连接建立的开销。
如何使用 HTTP 长连接？
客户端请求
GET /api/data HTTP/1.1
Host: example.com
Connection: keep-alive
服务器响应
HTTP/1.1 200 OK
Connection: keep-alive
这样，TCP 连接不会立即关闭，后续请求可以继续复用。
缺点
- 服务器 不能主动推送数据，每次数据传输还是 请求-响应模式。
- 连接虽然保持了，但 仍然需要客户端主动请求，服务器不能实时通知客户端。
2. HTTP/2 长连接
如何改进？
- HTTP/2 使用一个 TCP 连接，支持 多个请求并行传输，避免 HTTP 1.1 的 队头阻塞（Head-of-Line Blocking）。
- 支持服务器推送（Server Push），但应用层不常用。
HTTP/2 Server Push 示例
服务器 可以提前推送资源，但 不能动态推送数据：
HTTP/2 200 OK
Link: </styles.css>; rel=preload
客户端收到 HTML 时，**服务器会主动推送 ****styles.css**，减少请求次数。
缺点
- 只能提前推送 静态资源，不适合 实时数据（如 WebSocket 那样的持续推送）。
- 仍然是请求-响应模型，服务器不能随时发送数据。
3. SSE（Server-Sent Events）
是什么？
- SSE 是 基于 HTTP 长连接的服务器推送技术。
- 适用于：服务器主动推送消息（但只支持文本数据）。
SSE 示例
客户端请求
GET /events HTTP/1.1
Accept: text/event-stream
服务器响应
HTTP/1.1 200 OK
Content-Type: text/event-streamdata: {"message": "Hello, Client!"}
缺点
- 只能 服务器推送到客户端，但 客户端不能发送消息（不像 WebSocket 双向通信）。
- 只支持 文本数据，不支持 二进制。
- TCP 连接不能复用，每个 SSE 连接 占用一个 TCP 连接。
4. WebSocket vs HTTP 长连接
| 特性 | HTTP Keep-Alive | HTTP/2 Server Push | SSE | WebSocket |
|---|---|---|---|---|
| 是否是长连接 | ✅ | ✅ | ✅ | ✅ |
| 双向通信 | ❌（请求-响应） | ❌（只能预推送） | ❌（单向服务器推送） | ✅（全双工） |
| 服务器主动推送 | ❌ | ✅（但仅静态资源） | ✅ | ✅ |
| 客户端主动发送 | ✅（但每次都要请求） | ✅（但仅首个请求） | ❌（只能接收） | ✅ |
| 适用场景 | API 请求复用 TCP 连接 | 静态资源预加载 | 服务器推送消息（如股票行情） | 实时交互（如聊天、游戏） |
5. 总结
- HTTP Keep-Alive 只是 复用 TCP 连接，但仍然是 请求-响应模式。
- HTTP/2 支持 Server Push，但只能预推送静态资源，不能动态推送数据。
- SSE 适用于 服务器向客户端推送数据，但不能双向通信。
- WebSocket 才是真正的实时长连接，支持 全双工，适用于 IM、行情推送、游戏。
什么时候用 WebSocket 而不是 HTTP 长连接？
- 如果你需要服务器主动推送数据（实时性要求高），比如 股票、IM 聊天、推送通知 → 用 WebSocket。
- 如果只是 API 请求多，但服务器不需要主动推送 → HTTP Keep-Alive/HTTP/2 就足够了。
对接 WebSocket API，必须用 WebSocket，不能用 HTTP 长连接，否则你只能不断轮询，而不是实时接收数据。