F
Member
浏览器与服务端要持续换数据时，常见三条路：HTTP 长轮询、Server-Sent Events（SSE）和 WebSocket。都能“接近实时”，但方向性、开销与代理友好程度不同。
一、长轮询
客户端发起请求，服务端有数据再返回；客户端立刻再发下一次。实现简单，复用普通 HTTP，穿透代理相对容易。代价是：高频事件下请求次数多，延迟受“一问一答”节奏限制，服务端挂起连接的压力也不小。适合事件稀疏、兼容性要求高、不想上特殊协议的场景。超时与重试策略要设计好，否则容易自己把自己打成洪峰。
二、SSE
SSE 在一条 HTTP 响应里持续推送文本事件流，主要是服务端到客户端的单向通道。浏览器原生支持、自动重连机制成熟，适合行情摘要、通知、日志流这类“下行多、上行少”的应用。上行仍走普通 HTTP 即可。对需要强双向、二进制帧的场景，SSE 就不那么顺手；代理缓冲也可能让“实时”变“一阵阵”。
三、WebSocket
WebSocket 先经 HTTP 升级，再变成全双工帧通道，适合聊天、协同编辑、游戏状态、双向遥控等高频双向交互。它降低了反复建连的开销，但要自己处理心跳、重连、背压与消息边界；部分中间件、CDN 与公司代理对长连接支持不一致，运维复杂度更高。也不是所有“实时”都必须 WebSocket：若几乎只有服务端推送，SSE 往往更轻。
选型先问：单向还是双向？文本事件还是二进制？事件频率与连接数？再问基础设施是否友好。协议本身解决不了后端扇出与消息堆积，那是另一层问题。
无论选哪种协议，消息幂等与去重都要在业务层设计好，网络重传会把同一事件送多次。
讨论问题：
1. 你们生产环境更卡在代理/负载均衡对长连接的支持，还是业务背压？
2. 只有下行推送时，为什么仍有人坚持上 WebSocket？
3. 断线重连后的漏消息补偿，一般怎么做？
一、长轮询
客户端发起请求，服务端有数据再返回；客户端立刻再发下一次。实现简单，复用普通 HTTP，穿透代理相对容易。代价是：高频事件下请求次数多，延迟受“一问一答”节奏限制，服务端挂起连接的压力也不小。适合事件稀疏、兼容性要求高、不想上特殊协议的场景。超时与重试策略要设计好，否则容易自己把自己打成洪峰。
二、SSE
SSE 在一条 HTTP 响应里持续推送文本事件流，主要是服务端到客户端的单向通道。浏览器原生支持、自动重连机制成熟，适合行情摘要、通知、日志流这类“下行多、上行少”的应用。上行仍走普通 HTTP 即可。对需要强双向、二进制帧的场景，SSE 就不那么顺手；代理缓冲也可能让“实时”变“一阵阵”。
三、WebSocket
WebSocket 先经 HTTP 升级，再变成全双工帧通道，适合聊天、协同编辑、游戏状态、双向遥控等高频双向交互。它降低了反复建连的开销，但要自己处理心跳、重连、背压与消息边界；部分中间件、CDN 与公司代理对长连接支持不一致，运维复杂度更高。也不是所有“实时”都必须 WebSocket：若几乎只有服务端推送，SSE 往往更轻。
选型先问：单向还是双向？文本事件还是二进制？事件频率与连接数？再问基础设施是否友好。协议本身解决不了后端扇出与消息堆积，那是另一层问题。
无论选哪种协议，消息幂等与去重都要在业务层设计好，网络重传会把同一事件送多次。
讨论问题：
1. 你们生产环境更卡在代理/负载均衡对长连接的支持，还是业务背压？
2. 只有下行推送时，为什么仍有人坚持上 WebSocket？
3. 断线重连后的漏消息补偿，一般怎么做？