1. 短轮询（Short Polling）

原理 客户端每隔固定时间（如 5 秒）发起一次 HTTP 请求，询问服务器是否有新数据。服务器收到请求后立即返回响应（可能包含新数据，也可能为空）。

优点

• 实现简单，兼容性好，基于常规 HTTP 请求即可
• 无需特殊协议支持，适用于任何客户端和服务端环境

缺点

• 实时性一般：数据可能在两次轮询之间到达，用户需等待下一次请求才能获取
• 资源浪费大：频繁建立和关闭连接，大多数请求返回“无新数据”，增加服务器和网络压力

适用场景

• 实时性要求不高的场景，如天气信息、股票行情（非高频）、系统状态监控等
• 功能简单、开发周期短、无需维护复杂连接的中小型项目
• 对兼容性要求极高（如需要支持老旧浏览器或受限网络环境）的场景

---

2. 长轮询（Long Polling）

原理 客户端发起请求后，如果服务器没有新数据，会保持连接等待，直到有新数据或达到超时时间才返回响应。客户端收到响应后立即发起下一次请求，模拟“实时推送”的效果。

优点

• 实时性较好：有新数据时可立即返回，无需等待固定时间间隔
• 相比短轮询，无效响应减少，网络开销有所降低

缺点

• 服务器资源占用高：需要长时间维持大量连接，占用服务器线程或连接资源
• 仍需重复建立连接：每次响应后需重新发起请求，并未从根本上解决 HTTP 的“请求-响应”模式
• 实现复杂度略高于短轮询，需处理连接超时和重连逻辑

适用场景

• 实时性要求较高，但无法或不适合使用 WebSocket 的场景
• 用户量较小或连接数可控的内部系统、管理后台，像Apollo、Nacos配置中心就是用的长轮询
• 某些老旧环境或代理服务器对 WebSocket 支持不佳时，作为替代方案
• 即时聊天、消息通知等早期常见实现方式（在 WebSocket 普及前广泛使用）

---

3. WebSocket

原理 客户端与服务器通过一次 HTTP Upgrade 握手，建立一条持久的 TCP 连接。之后，双方可以在任意时间主动发送数据，实现真正的全双工通信。

优点

• 实时性强：数据可以即时双向传输，延迟极低
• 资源效率高：连接复用，无需反复建立和关闭连接，节省网络与服务器资源
• 功能强大：支持服务端主动推送和客户端主动发送，适用于高实时性交互场景

缺点

• 实现复杂度较高：需要处理连接保活（如心跳）、断线重连、协议兼容性等
• 依赖双方支持：客户端和服务器需支持 WebSocket 协议，部分老旧环境或特殊代理可能受限
• 连接管理成本较高，需考虑负载均衡、连接数上限等问题

适用场景

• 高实时性双向通信场景：在线聊天、实时协同编辑、在线游戏、直播弹幕、金融行情等
• 服务端需要主动推送数据的高频交互应用
• 移动端或现代浏览器环境，对性能和实时性要求较高的项目
• 微服务架构中需要长连接通信的内部服务

总结对比

维度	短轮询	长轮询	WebSocket
实时性	低（取决于轮询间隔）	较高	极高（毫秒级）
服务器资源	高（频繁请求）	较高（长连接占用）	较低（连接复用）
网络开销	高（大量空请求）	中	低（握手后少量控制帧）
实现复杂度	低	中	中高
适用场景	实时性要求低、简单项目	实时性中等、WebSocket受限场景	高实时性、双向通信场景