使用SSE（Server-Sent Events）协议实现服务器向客户端推送数据，是构建实时在线服务最高效且成本最低的方案，尤其适合单向数据流、实时通知等场景。
SSE协议到底是什么？它如何让服务器主动找上门
SSE协议的全称是Server-Sent Events，翻译过来就是服务器发送事件，它基于HTTP协议，让服务器能够主动向客户端推送数据，而不是客户端反复去问“有新消息吗”，这和我们常见的WebSocket完全是两码事：WebSocket是双向通道，SSE是服务器单向推送，客户端只能接收，不能发送。
从技术实现看,SSE非常简单，客户端只需要创建一个EventSource对象，指定一个URL，就能建立连接，服务器端则需要在响应头中设置Content-Type为text/event-stream，然后按固定格式发送数据，每个事件由若干行组成，以data:开头，后面跟具体内容，事件之间用空行分隔，比如说，服务器可以每隔几秒发一条data: {“message”:”hi”}，客户端就能实时收到。
这种机制决定了SSE特别适合那些服务器需要频繁向客户端推送信息的在线服务,比如股票行情、新闻推送、系统日志流、AI推理结果等，它不需要客户端额外安装插件，所有现代浏览器原生支持，在移动端和桌面端表现都很稳定。
SSE协议和WebSocket对比：哪个更适合实时在线服务
很多开发者会纠结一个问题：SSE协议和WebSocket哪个好？要回答这个问题，得看你的在线服务具体需要什么，行业共识认为，两者各有侧重，不能简单说谁更优。
从连接方向看，WebSocket支持双向通信，客户端和服务端可以随时互相发消息，SSE是单向的，只有服务器能推送，客户端只能接收，如果你的在线服务只需要服务器向客户端推送信息，比如实时比分、通知提醒，那么SSE更加轻量，因为不需要维护双向通道的握手和心跳。
从协议复杂度看，WebSocket需要先通过HTTP Upgrade升级协议，然后切换到自定义的帧格式，维护起来相对复杂，SSE直接跑在HTTP之上，不需要额外协议，后端写起来就像写普通HTTP接口一样简单，很多团队在开发初期选择SSE，就是因为它能快速上线，几乎零学习成本。
从浏览器兼容性看，SSE几乎支持所有主流浏览器，包括Chrome、Firefox、Safari、Edge，移动端也不成问题，WebSocket兼容性同样很好，但部分老旧的代理服务器可能会拦截WebSocket的升级请求，导致连接失败，SSE因为基于标准HTTP，天然能穿透大部分代理和防火墙。
从连接数限制看，大多数浏览器对同一个域名下的SSE连接数有限制，通常为6个左右，超过会被阻塞，WebSocket没有这个限制，但每个WebSocket连接会占用更多服务器资源，如果你的在线服务需要同时打开大量推送通道，比如仪表盘多面板，就需要考虑SSE的连接数限制，或者通过域名分片解决。
从重连机制看，SSE自带自动重连功能，一旦连接断开，客户端会定期尝试重新连接，服务器还可以通过Last-Event-ID字段告诉客户端从断点处继续，WebSocket则需要自己实现重连逻辑，虽然不复杂，但多了一件事。
综合来看,如果你的在线服务是单向推送、对实时性要求中等、希望快速开发，SSE是更合适的选择，如果涉及双向高频交互，比如在线游戏、协作编辑，那就选WebSocket。
SSE在实时数据推送场景中的典型应用
SSE最常见的场景是服务器向客户端持续推送变化数据,而且这些数据不需要客户端确认，以下是一些实际使用案例，涵盖了多个行业。
- 金融行情推送：股票、外汇、期货的实时价格变动，服务器每秒推送一次最新报价，客户端界面自动刷新，SSE不同于WebSocket，它不需要客户端发请求才更新，服务器可以自主控制推送频率。
- AI模型推理结果流式输出：现在很多大模型API都支持SSE格式，比如ChatGPT的流式回复，服务器每生成一个token就推送给客户端，用户看到的就是一个字一个字蹦出来的效果，体验非常好。
- 系统监控与日志实时流：运维人员通过SSE接收服务器日志、性能指标，不需要手动刷新页面，SSE的连接状态通过readyState属性可以随时监控，断线后自动重连，非常适合长时间运行的监控面板。
- 新闻与通知推送：社交平台、新闻网站用SSE向用户推送新消息、评论通知，相比轮询，SSE节省了大量带宽，因为只有在有数据时才发送。
在这些场景下,你可能会问SSE在线服务配置复杂吗？答案是非常简单。
SSE在线服务配置步骤详解
配置SSE访问在线服务,无论前端还是后端，代码量都非常少，下面以最常见的Node.js和浏览器为例，展示具体操作步骤。
第一步：搭建服务端
在Node.js中，使用Express框架可以快速搭建SSE端点，关键是设置响应头：
- Content-Type: text/event-stream
- Cache-Control: no-cache
- Connection: keep-alive
然后每隔一段时间发送数据,格式如下：
data: {"price": 123.45}
data: {"price": 123.67}每个事件由data:字段开始，如果有多行，可以用多个data:，最后用空行结束，还可以指定事件类型，用event:字段，方便客户端区分。
第二步：编写客户端
前端使用new EventSource('/stream')创建连接，然后监听三个事件：
- onmessage：收到任何未指定事件类型的数据时触发。
- onopen：连接建立时触发。
- onerror：连接出错或断开时触发。
EventSource对象会自动处理重连,你不需要写任何重试逻辑，如果服务器发送了Last-Event-ID，浏览器重连时会自动带上这个ID，让服务器从断点处继续推送。
第三步：处理连接断开
SSE的自动重连机制默认间隔几秒,可以用retry:字段自定义重连时间，服务器端需要定期检查连接是否存活，如果客户端断开，服务器应该停止发送数据并释放资源，这个检查可以通过监听request的close事件实现。
第四步：跨域与安全
如果前端和后端在不同域名,需要在服务器端设置CORS头，SSE的fetch请求遵循同源策略，跨域时浏览器会先发送预检请求，服务器需要回应Access-Control-Allow-Origin，如果涉及用户认证，可以在URL中带token，或者通过withCredentials字段传递cookie。
使用SSE协议的成本分析：真的免费吗
SSE协议本身是免费的,它基于HTTP，不需要额外授权费用，但使用SSE访问在线服务，隐形成本需要考虑。
- 带宽成本：SSE保持长连接，持续发送数据，如果推送频率很高，带宽消耗会显著增加，对于实时推送场景，服务器需要持续输出数据，这比轮询更省带宽，但比WebSocket稍高，因为HTTP头部开销大一些，不过多数情况下，这种差异可以忽略。
- 服务器资源：每个SSE连接都占用一个长连接，服务器需要维护这些连接的状态，如果并发连接数达到上万级别，服务器内存和句柄压力会比较大，现代服务器配合异步框架（如Node.js、Netty）可以轻松支撑数十万SSE连接，但老旧的同步模型会吃力，分发网络（CDN）支持：CDN通常不缓存SSE流，也不会主动转发长连接，所以SSE不适合通过CDN加速，如果在线服务面向全球用户，你需要考虑回源带宽和延迟，国内一线云厂商均已支持SSE穿透，但部分中小CDN可能不支持，这点需要提前测试。
从价格角度看,SSE没有额外软件许可费，基础设施成本主要取决于你的并发规模和数据量，对于大多数中小型在线服务，SSE的成本几乎可以忽略不计。
国内使用SSE协议需要注意什么
地域词：国内使用SSE有几点特殊之处，尤其对于面向国内用户的在线服务。
- 网络环境：国内运营商可能对长连接有超时限制，比如某些移动网络会断开空闲连接，SSE本身有自动重连，但如果连接频繁断开，用户体验会受影响，建议在服务端设置合理的心跳机制，每隔一定时间发送一个注释行（: heartbeat）来保持连接活跃。
- 备案与合规：SSE作为服务器推送技术，不涉及用户主动上传数据，但推送内容仍需遵守网信办规定，如果推送的是实时新闻、金融信息，需要对应的资质，如果使用SSE传输敏感数据，务必加密，可以通过HTTPS+SSE来实现。
- 浏览器兼容性：国内还有部分用户使用老旧浏览器（如IE），SSE在这些浏览器中不受支持，如果需要覆盖这些用户，可以降级到长轮询或使用polyfill，不过大多数现代浏览器和国产浏览器内核都已支持SSE，兼容性问题在逐年减少。
- 云服务厂商支持：国内主流云厂商如简米云、酷番云、华为云，其负载均衡和API网关均支持SSE长连接，但需要注意配置超时时间，部分云厂商的默认超时时间较短，需要手动调大。
服务器向客户端使用SSE协议访问在线服务常见问题解答
SSE有多大的并发限制？
浏览器对每个域名下的SSE连接数有限制,通常为6个，这是由HTTP/1.1的规范决定的，如果页面需要同时打开多个推送通道，可以通过域名分片、使用HTTP/2或切换到WebSocket来规避，服务器端则没有统一限制，取决于你的服务器资源，异步框架可以轻松支撑数万并发。
SSE可以传输二进制数据吗？
官方标准中SSE只支持UTF-8文本，不支持二进制数据，如果需要传输二进制，可以先将数据编码为Base64或使用其他文本格式，客户端再解码，但这样做会增加传输大小，如果二进制数据量很大，建议改用WebSocket。
SSE和长轮询相比有什么优势？
长轮询是客户端不断发起请求,服务器挂起请求直到有数据才返回，然后客户端立即再次发起请求，SSE的优势在于实时性更好，延迟更低，因为连接始终存在，不需要频繁建立和断开，同时SSE减少了请求头部的重复开销，服务器资源占用也更少，长轮询在兼容性上有优势，但性能上SSE全面领先。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/545743.html
