Server-Sent Events(SSE)每次推送事件都携带头信息吗？仅连接建立时发送？

SSE 头信息的传输规则 #

SSE 仅在初始连接建立阶段发送一次 HTTP 响应头，后续所有事件推送都不会重复携带头信息。

SSE 是基于 HTTP 长连接实现的单向推送协议，连接建立时服务端会返回符合 SSE 规范的响应头，示例如下：

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
Access-Control-Allow-Origin: *

连接建立完成后，该 HTTP 连接会持续保持打开状态，后续服务端推送的内容仅为 SSE 协议定义的事件格式内容，没有额外的 HTTP 头开销，标准事件格式如下：

data: 新闻Feed更新的具体内容\n
id: 1001\n
event: feedUpdate\n\n

其中除了业务内容外，仅携带极短的协议标记字段，整体开销极低。

带宽对比与选型建议 #

你不需要担心 SSE 重复携带头导致带宽过高的问题，它和 WebSocket 的带宽消耗差异极小：

• WebSocket 同样是在初始握手阶段发送一次 HTTP 头，后续推送的帧也仅有2-10字节的帧头开销，和 SSE 的协议标记开销基本处于同一量级。普通新闻Feed推送（通常单条消息几十到上百字节，推送频率不高）的场景下，两者的带宽差异完全可以忽略，不会成为性能瓶颈。

你原本倾向 SSE 的判断是完全合理的，单向推送场景下 SSE 比 WebSocket 优势更明显：

• 原生特性更适配：SSE 内置自动重连、断线后按事件ID补传消息的能力，不需要额外开发就能保证用户断线重连后不会错过新闻更新，刚好匹配新闻Feed的推送需求。
• 实现成本更低：客户端直接使用原生EventSourceAPI即可接入，服务端不需要处理 WebSocket 的帧解析逻辑，基于普通 HTTP 服务就能实现，开发和调试成本都更低。
• 兼容性更好：HTTP 协议下的 SSE 连接几乎不会被常规代理、防火墙拦截，WebSocket 则可能在部分严格的企业网络环境下被拦截。

只有当你后续需要扩展双向交互能力（比如用户实时点赞、评论同步），或者需要推送二进制内容时，才需要考虑切换到 WebSocket。

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