实时通信：SSE vs WebSocket vs Polling

把 SSE/WebSocket/轮询放在一起对比：通信方向、可靠性、基础设施约束与典型场景。

#type / synthesis #status / growing #tech / network #platform / browser #resource / http #resource / javascript

[!info] related notes

所属 MOC: http-and-frontend-networking-moc

概念: sse, web-socket, polling

流式响应: frontend-streaming-data-handling, frontend-streaming-response-patterns, ai-chat-and-streaming-ui

常见坑: sse-connection-cache-issue

实时通信：SSE vs WebSocket vs Polling

范围

这篇是“选型关系笔记”，不重复解释每个概念的所有细节，只把关键差异讲清楚并给出跳转。

抓住 3 个问题

你需要双向吗？（客户端是否也要频繁发消息）
你需要二进制/低延迟吗？
你的基础设施是否会干扰长连接？（代理/CDN/负载均衡/超时）

对比要点

SSE
- 单向：server -> client
- 基于 HTTP，浏览器 EventSource 通常自带重连语义
- 很适合“流式输出/通知/行情/日志”这类持续推送
WebSocket
- 双向：全双工
- 握手借用 HTTP，但成功后升级为 WebSocket 帧协议
- 更适合“双方都要频繁交互”的场景（协作编辑、实时游戏、IM 等）
Polling（短轮询/长轮询）
- 不需要特殊协议，兼容性好
- 成本在于额外请求开销与延迟；但在某些受限网络/代理环境里更稳

典型建议

“模型/AI 回复逐字输出”这类单向流：优先 SSE（或 HTTP streaming）。
需要客户端也持续上行：优先 WebSocket。
环境受限或只需低频更新：Polling 仍然是一个简单可靠的退路。

下一步阅读