文章目录
- 引言
- 1.Long Polling (长轮询)
- 2. SSE (Server-Sent Events)
- 3. WebSocket
- 对比总结
引言
作为后端开发人员（Java/Go），你肯定遇到过需要实时将服务器数据推送到客户端的场景。传统的 HTTP 请求-响应模式无法满足这种需求。
为了解决这个问题，演变出了三种主流方案：Long Polling (长轮询)、SSE (Server-Sent Events)和WebSocket。
以下是这三者的深度对比与技术解析。
1.Long Polling (长轮询)
这里通过一个日常场景来引入长轮询的知识介绍，我们日常生活工作和学习都会用手机扫码登录或者授权，你有没有细心发现这样的现象？即如果你长时间不去扫码进行授权，过了一段时间这个二维码就会失效，需要重新刷新才能重新授权。这其实就是长轮询的应用😯
长轮询是对传统短轮询（Short Polling）的一种优化。它本质上仍然是 HTTP 请求，但通过“挂起”请求来模拟实时性。
工作原理：
- 客户端发起 HTTP 请求（例如
GET /poll）。 - 关键点：服务器收到请求后，如果没有新数据，不立即返回，而是将请求挂起（Hold 住连接），直到有新数据产生或达到超时时间（如 30秒）。
- 一旦有数据或超时，服务器返回响应。
- 客户端收到响应后，处理数据，并立即再次发起新的请求，周而复始。
- 客户端发起 HTTP 请求（例如
优点：
- 兼容性极高：基于标准 HTTP，几乎所有浏览器和服务器都支持，无需特殊协议升级。
- 容错性：因为每次都是新请求，网络抖动后的重连机制就是天然的（发起下一个请求即可）。
缺点：
- 开销大：虽然比短轮询好，但每次重新连接都要重新发送 HTTP Header（鉴权信息等），对于频繁的小数据推送，带宽浪费严重。
- 有延迟：数据推送到下一次请求建立之间存在微小的时间差。
- 服务器资源占用：服务器需要维护大量挂起的线程（Java 早期 BIO 时代这是噩梦，NIO/Go 协程缓解了这个问题）。
适用场景：扫码登录确认、低频的通知推送、老旧系统改造
2. SSE (Server-Sent Events)
SSE 是一种基于 HTTP 的轻量级单向通信机制。
工作原理：
- 客户端发起请求，Header 中声明
Accept: text/event-stream。 - 服务器响应
Content-Type: text/event-stream，并保持连接不断开。 - 服务器通过这个连接不断地写入数据流（Stream），格式通常是
data: <content>\n\n。 - 关键点：这是单向的，只能服务器发给客户端。客户端如果想发数据给服务器，需要另外发起一个标准的 HTTP 请求。
- 客户端发起请求，Header 中声明
优点：
- 轻量级：使用简单，基于 HTTP 协议，对防火墙和负载均衡器友好。
- 断线自动重连：浏览器原生支持 SSE，断网后会自动尝试重连。
- 开发简单：Go (
gin框架) 和 Java (Spring WebFlux) 处理 SSE 都非常容易。
缺点：
- 单向通信：只适合“读”场景。
- 文本传输：默认传输文本，传输二进制数据需要 Base64 编码，效率较低。
- 连接数限制：HTTP/1.1 下浏览器对同一域名的并发连接数有限制（通常 6 个），如果打开多个 Tab 页可能会阻塞。HTTP/2 可以解决这个问题。
适用场景：ChatGPT 的打字机效果、股票行情更新、体育比分直播、服务器日志监控、MCP tool开发等
3. WebSocket
WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。
工作原理：
- 握手：客户端发起 HTTP 请求，Header 包含
Upgrade: websocket和Connection: Upgrade。 - 升级：服务器同意升级，返回
101 Switching Protocols。 - 传输：连接建立后，HTTP 协议的概念消失，双方通过 TCP 通道直接传输二进制或文本帧（Frame）。双方可以随时互相发送数据。
- 握手：客户端发起 HTTP 请求，Header 包含
优点：
- 全双工：真正的双向实时通信。
- 高性能：建立连接后，数据传输只有极小的帧头开销（不像 HTTP 每次都要带 Header）。
- 低延迟：无需轮询，数据即时到达。
缺点：
- 复杂性：需要处理心跳检测、断线重连、粘包拆包（框架通常已封装）等状态管理。
- 负载均衡麻烦：因为是长连接，状态存储在内存中。在集群环境下，通常需要 Nginx 配置 IP Hash 或者使用 Redis Pub/Sub 来同步集群消息。
- 防火墙/代理限制：部分企业内网防火墙可能会拦截非 HTTP 流量或长时间不断的连接。
适用场景：在线多人游戏、即时聊天室 (IM)、协同编辑文档、极高频的实时交易平台。
对比总结
| 特性 | Long Polling (长轮询) | SSE (Server-Sent Events) | WebSocket |
|---|---|---|---|
| 通信方向 | 双向 (伪) | 单向(Server -> Client) | 全双工 |
| 协议 | HTTP | HTTP | TCP (经 HTTP 握手) |
| 数据格式 | 任意 | 文本 (UTF-8) | 二进制 / 文本 |
| 开销 | 高 (Header重复发送) | 低 (长连接) | 极低(轻量帧头) |
| 实现难度 | 中等 | 简单 | 复杂 |
| 浏览器限制 | 无 | HTTP/1.1 限制 6 个连接 | 无明显限制 |
这三个知识点是后台面试经常问到的，如果你的简历经历是带有高性能网络通信服务器等背景的（IM）等等，那则是必须要会回答的❤️
