服务器主动发送客户端（Server-Sent Events, SSE）是一种基于HTTP的单向实时通信机制，适用于新闻推送、股票行情等需要服务端高频下发数据且无需客户端频繁回传的场景，其核心优势在于原生支持、自动重连及低资源消耗。
在传统的Web开发模式中,客户端（浏览器）通常是发起请求的一方，等待服务器响应，这种“轮询”或“长轮询”模式在实时性要求极高的场景下显得笨重且低效，为了解决这一痛点，现代Web标准引入了Server-Sent Events（SSE）技术，它允许服务器向客户端持续推送数据，而无需客户端发起新的请求，这种机制不仅简化了代码逻辑，还显著降低了服务器负载和延迟。
SSE与WebSocket的技术选型对比
许多开发者在面临实时通信需求时,往往在SSE和WebSocket之间犹豫不决，业内专家指出，选择哪种技术取决于具体的业务场景和数据流向。
通信方向与数据格式
SSE本质上是单向通信,数据只能从服务器流向客户端，这意味着它非常适合“推送”类应用，如社交媒体动态、监控报警或IoT设备状态更新，相比之下，WebSocket是全双工通信，允许客户端和服务器同时发送数据，如果你的应用需要大量的双向交互，如在线聊天室或多人在线游戏，WebSocket是更合适的选择。
连接稳定性与重连机制
在移动端网络环境复杂的情况下,连接稳定性至关重要，SSE基于HTTP协议，天然支持TCP连接的保持，当网络波动导致连接断开时，SSE规范定义了自动重连机制，客户端会在短时间内自动尝试恢复连接，无需开发者编写复杂的重试逻辑，而WebSocket虽然也能实现重连，但通常需要开发者手动处理心跳检测和重连策略，增加了开发复杂度。
浏览器兼容性与开发成本
从兼容性来看,SSE在所有现代浏览器中均得到原生支持，包括移动端浏览器，开发者只需使用标准的JavaScript API
EventSource 即可实现，无需引入额外的第三方库，WebSocket虽然也广泛支持，但在某些老旧的代理服务器或防火墙环境中可能会遇到拦截问题，SSE的数据格式通常为纯文本或JSON，解析简单；而WebSocket支持二进制数据，适合传输大型文件。
服务器主动发送客户端的核心实现原理
理解SSE的工作原理是高效应用该技术的基础,SSE通过HTTP长连接保持通道开放，服务器以特定的格式流式传输数据。
HTTP头字段配置
服务器在响应SSE请求时,必须设置特定的HTTP头字段，最关键的是 Content-Type: text/event-stream，这告诉浏览器这是一个SSE流。Cache-Control: no-cache 确保数据不被缓存，保证实时性。
数据格式规范
SSE的数据传输遵循特定的文本格式,每条消息由字段组成，常见的字段包括：
- data：消息体内容，可以是JSON字符串或纯文本，如果数据跨越多行，每行末尾需保留换行符。
- id：消息的唯一标识符，客户端会记录最后接收到的ID，用于断线重连时告知服务器从何处继续发送。
- event：自定义事件类型，默认事件名为 “message”，开发者可以定义如 “notification” 或 “update” 等自定义事件，以便客户端区分处理不同来源的数据。
- retry：指定客户端在连接断开后重新连接前的等待时间（毫秒）。
服务端代码示例
以Node.js为例，实现一个简单的SSE服务器并不复杂，开发者需要创建一个HTTP服务器，监听连接事件，并在连接建立后持续写入数据。
const http = require('http');const server = http.createServer((req, res) => {if (req.url === '/stream') {res.writeHead(200, {'Content-Type': 'text/event-stream','Cache-Control': 'no-cache','Connection': 'keep-alive'});
// 模拟每秒发送一条数据 let count = 0; const interval = setInterval(() => { count++; res.write(`data: ${JSON.stringify({ time: new Date().toISOString(), count })}nn`); if (count >= 10) { clearInterval(interval); res.end(); } }, 1000);server.listen(3000);
高并发场景下的性能优化策略
虽然SSE比轮询高效,但在面对数万甚至数百万并发连接时，服务器资源消耗依然显著，据统计，多数情况下，未优化的SSE实现容易成为系统瓶颈。
连接管理
每个SSE连接都会占用一个文件描述符和一定的内存,对于Node.js等单线程事件循环模型，过多的连接可能导致事件循环阻塞，建议采用集群部署，利用Nginx等反向代理进行负载均衡，应实现连接超时机制，及时清理空闲或断开的连接，释放资源。
数据压缩与批处理
在网络带宽有限的情况下,数据压缩能显著提升传输效率，虽然SSE本身不支持gzip压缩（因为流式传输会破坏压缩块），但可以通过减少数据频率或合并多条消息为一条JSON数组来降低开销，将每秒10条消息合并为每秒1条包含10个数据的数组，虽然牺牲了部分实时性，但大幅降低了HTTP头部开销和网络交互次数。
断线重连优化
在移动网络环境下,断线是常态，客户端应实现指数退避算法，即第一次重连等待1秒，第二次2秒，第三次4秒，以此类推，避免在服务器端造成DDoS攻击般的压力，服务器应记录每个连接的最后接收ID，确保重连后数据不丢失、不重复。
实际应用场景与最佳实践
SSE并非万能钥匙,明确其适用边界能避免技术选型失误。
实时仪表盘与监控
在运维监控系统中,服务器主动发送客户端的场景极为常见，Kubernetes集群的状态变更、服务器CPU使用率波动等，这些场景只需要单向推送，且对数据一致性要求不高，允许短暂的数据延迟，使用SSE可以实现低延迟的可视化更新，且对前端开发极其友好。
新闻与社交媒体推送
对于新闻网站或社交平台,用户希望第一时间看到新文章或新动态，SSE可以高效地将新内容推送到用户浏览器，相比WebSocket，SSE的单向特性正好契合这种“订阅-发布”模式，且更容易通过现有的HTTP基础设施（如CDN、代理）进行缓存和路由。
注意事项与局限
尽管SSE优势明显,但开发者需注意其局限性，SSE不支持二进制数据，若需传输图片、文件等二进制内容，需将其编码为Base64，这会增加约33%的数据体积，SSE连接数受限于浏览器并发连接数，通常每个域名限制在6个左右，虽然现代浏览器对此有所放宽，但在极端场景下仍需注意，SSE无法保证消息的严格顺序和送达确认，若业务强依赖消息确认机制，应结合应用层ACK逻辑或选择WebSocket。
Q&A：关于服务器主动发送客户端的常见问题
SSE是否支持双向通信？
不支持,SSE是单向通信协议，数据只能从服务器流向客户端，若需双向通信，必须使用WebSocket或HTTP/2的多路复用特性结合轮询。
如何在SSE中实现消息确认机制？
SSE本身不提供消息确认,开发者可在应用层实现：客户端收到数据后，通过独立的HTTP POST请求向服务器发送ACK信号，服务器收到ACK后标记该消息已送达。
SSE在移动端浏览器的兼容性如何？
据工信部及相关浏览器厂商公开信息显示,SSE在iOS Safari 6+、Android Chrome 30+等主流移动端浏览器中均得到良好支持，但在部分老旧的国产定制ROM浏览器中可能存在兼容性问题，建议进行降级处理。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/466993.html
