已有HTTP2双向流，为何仍需使用SSE？

嘿，这个问题确实容易让人困惑——我刚接触HTTP/2的时候也纠结过好久！咱们来拆解下SSE（服务器发送事件）和HTTP/2双向流（注意你提到了不是HTTP/2服务器推送，这点很关键）的核心差异，其实它们的定位、封装程度和适用场景都有不少区别：

1. 协议基础与兼容性 #

• SSE是基于HTTP/1.1的专属规范，本质是借HTTP长连接的特性，通过text/event-stream媒体类型实现服务器单向推送。它最大的优势是兼容性拉满——几乎所有现代浏览器原生支持，老版本也能靠polyfill兼容，完全不需要依赖HTTP/2环境。
• HTTP/2双向流是HTTP/2协议本身的底层特性，允许在同一个TCP连接上创建多个独立的双向流（每个流都能随时收发数据）。但它要求客户端和服务器都必须支持HTTP/2，而且没有封装好的“事件推送”语义，所有细节（比如重连、消息格式）都得自己实现。

2. 高层封装与开箱即用能力 #

• SSE自带一大堆语义化的开箱即用特性，省了超多开发成本：
  • 自动重连：连接断开后客户端会自动重试，还能通过retry字段自定义重连间隔
  • 事件分类：用event字段给消息打标签，客户端可以监听特定类型的事件
  • 数据分段：支持用data:多行传递数据，客户端会自动拼接成完整消息
  • 心跳机制：发送空的:消息就能维持连接活跃，避免被网关断开
• HTTP/2双向流只是底层传输能力，没有这些高层封装。你得自己从零实现重连逻辑、消息边界处理、事件类型区分等功能——灵活性拉满，但开发成本也高很多。

3. 传输方向与场景适配 #

• SSE是单向推送：只能服务器主动给客户端发数据，客户端如果要给服务器发消息，得单独发HTTP请求（比如POST）。它特别适合只需要服务器主动通知的场景：比如实时通知、股票行情更新、系统日志推送等。
• HTTP/2双向流是双向交互：同一个流里客户端和服务器都能随时收发数据，能力接近WebSocket。如果你的场景需要频繁双向通信（比如实时聊天、在线协作编辑），用HTTP/2双向流会更高效，因为不需要额外建立连接。

4. 连接资源利用率 #

• 在HTTP/1.1环境下，SSE会占用一个TCP连接（HTTP/1.1同一域名的并发连接数有限），如果有多个SSE订阅，可能会碰到连接数瓶颈；但在HTTP/2环境下，SSE可以复用同一个TCP连接的不同流，这个问题会缓解。
• HTTP/2双向流本身就是基于TCP连接复用的多流模型，不管多少个双向流，都不会额外占用TCP连接，资源利用率更高。

如果你的需求是简单的服务器单向推送，想要快速落地、兼容性好，选SSE绝对是最优解；如果需要双向交互，或者想最大化利用HTTP/2的性能优势，且愿意投入精力做底层封装，那HTTP/2双向流会更适合你。

内容的提问来源于stack exchange，提问作者Samarendra