实时通信与传输选择
为什么“实时”不是一个单一技术点
很多需求被统称为实时：
- 消息提醒
- 聊天
- 订单状态变化
- 协作光标
- 行情更新
- 日志流
但这些需求的真正技术要求并不一样。
有些只是“希望尽快知道变化”。
有些则需要：
- 持续双向通信
- 低延迟
- 大量消息
- 连接状态管理
所以“实时”首先不是一个 API 名字。
它是一组不同强度的时效需求。
最容易混淆的几种方案
最常见的实时传输方案通常包括：
- polling
- long polling
- Server-Sent Events
- WebSocket
它们不是简单的新旧替代关系。
更好的理解是：
它们在连接形态、复杂度和基础设施要求上做了不同交换。
polling 为什么没有你想象中那么“落后”
polling 的模型很简单：
客户端定时发请求问服务器有没有新数据。
它的缺点很明显：
- 可能浪费请求
- 实时性受轮询间隔限制
但它的优点也很真实：
- 简单
- 稳定
- 容易和现有 HTTP 基础设施融合
所以它不应该被一概讲成“过时方案”。
long polling 在解决什么问题
long polling 仍然基于请求-响应模型。
区别是服务端不一定立刻返回。
它会等到：
- 有新数据
- 或者超时
再结束这次请求。
然后客户端再发起下一次。
这让它在很多场景下比固定间隔 polling 更及时，也减少了空轮询。
SSE 是什么
SSE 是 Server-Sent Events。
它可以先理解成：
服务端向客户端持续推送文本事件流的一种 HTTP 机制。
关键点在于：
- 单向
- 服务端到客户端
- 基于 HTTP
所以它很适合：
- 通知流
- 状态更新流
- 日志流
但不适合天然需要客户端持续向服务端发消息的场景。
WebSocket 又是什么
WebSocket 提供的是持久化、全双工连接。
简单说：
连接建立后，客户端和服务端都能主动发消息。
这让它非常适合：
- 聊天
- 协作编辑
- 游戏
- 高频双向交互
但它的复杂度也会更高。
为什么不能把 WebSocket 讲成“实时通信终极答案”
因为更强能力通常意味着更高成本。
WebSocket 会引入：
- 长连接管理
- 心跳
- 断线重连
- 会话与鉴权
- 水平扩展与连接分发
如果你的需求只是偶尔推送状态变化，WebSocket 可能就过重了。
SSE 和 WebSocket 的差别，最该记住什么
不是“一个新，一个更新”。
而是：
- SSE 更偏服务器单向推送
- WebSocket 是双向长连接
这个差别会直接决定工程选择。
为什么很多产品其实根本不需要“真实时”
这是一个很重要的判断点。
用户说“实时”，有时真正意思只是：
- 几秒内能看到更新就行
如果需求是这个级别，polling 或 long polling 可能已经足够。
不必一上来就上最重方案。
连接管理为什么是实时系统的隐藏成本
很多团队初看实时通信时，关注点都在“消息能不能传到”。
真正麻烦的往往是：
- 连接多久存活
- 断线怎么办
- 页面切后台怎么办
- 多 tab 怎么处理
- 鉴权过期怎么办
这也是为什么实时通信不是“换个 API”而已。
它会把系统复杂度明显抬高。
WebSocket 为什么常和心跳、重连一起讨论
因为长连接天然会面临：
- 网络波动
- 中间代理超时
- 连接失效
所以一旦选择 WebSocket，通常就要顺带设计：
- heartbeat
- reconnect
- reconnect backoff
- 消息补偿或重同步
如果这些没设计好，系统看起来是实时，实际稳定性会很差。
SSE 为什么在某些场景下很优雅
因为它保留了 HTTP 语境的很多好处。
它对“服务端持续给客户端推消息”这种模式非常贴合。
比如：
- 任务进度
- 状态广播
- 后台作业结果
如果你不需要双向通信，SSE 往往比 WebSocket 更轻。
polling 到底什么时候仍然合理
通常在这些情况：
- 更新频率不高
- 实时性要求没有到秒内极限
- 系统想尽量复用普通 HTTP 基础设施
- 团队不想承担长连接复杂度
很多业务系统、管理后台、订单状态页，其实都可以从这里开始。
实时方案选择，本质在权衡什么
通常在权衡：
- 时效要求
- 双向性需求
- 基础设施复杂度
- 扩展成本
- 浏览器与网络环境稳定性
这也是为什么没有一种方案能天然适合所有产品。
浏览器 API 之外，还要看什么
还要看：
- 代理层是否支持
- 网关和负载均衡策略
- 鉴权和会话模型
- 消息是否可丢
- 断线后如何恢复
如果只从前端 API 视角选方案，很容易低估整体成本。
常见误区
1. 用户说“实时”，就默认 WebSocket
这很常见，也很容易过度设计。
2. 只看传输延迟，不看连接治理成本
实际系统经常死在连接治理而不是消息本身。
3. 把 SSE 讲成“简化版 WebSocket”
这样会模糊它的单向特性。
4. 以为 polling 一定过时
它在很多需求里仍然是最稳妥方案。
中国互联网语境里的常见实时场景
比较典型的包括：
- IM
- 直播互动
- 电商订单状态
- 协作类工具
- 运营大屏和监控看板
这些场景差别很大。
真正成熟的判断不是“都上 WebSocket”。
而是先按消息强度和交互模型分类。
海外语境里，为什么更常把实时传输和协作产品绑在一起看
很多海外产品会更早碰到：
- 协作文档
- 设计工具
- 开发者工具
- 通知流平台
这会让 WebSocket、SSE、重连策略、presence 机制更早进入主线讨论。
但本质判断仍然一样：
要根据交互结构选传输，不要根据热度选传输。
这类主题为什么很适合做表达训练
因为它太容易被讲成：
- WebSocket 是实时通信
这不够。
更好的表达应该继续说明：
- polling、long polling、SSE、WebSocket 的关系
- 为什么“实时”不是单一等级需求
- 为什么连接管理才是很多系统真正的复杂度来源
建议实践
实践 1：实现 polling 与 SSE 对照 demo
练什么：
理解“尽快知道变化”和“持续推送”的差异。
最小交付物：
一个状态更新 demo。
验收标准：
- 能比较两种方案的请求行为
- 能说明各自适合什么场景
常见误区：
- 只比代码长短，不比传输模型
实践 2：做一个最小 WebSocket 聊天
练什么：
理解双向长连接与连接治理。
最小交付物：
一个可发可收的最小聊天室。
验收标准：
- 有基本重连逻辑
- 能处理连接断开与恢复
常见误区：
- 只实现 happy path，不处理断线
实践 3：给一个业务需求做传输选型说明
练什么：
把“技术热度”转换成“产品需求判断”。
最小交付物：
一页传输方案选型说明。
验收标准：
- 能说明为什么不是所有场景都该上 WebSocket
- 能明确 trade-off
常见误区：
- 只说“这个更先进”