互联网数据的传输基石是 HTTP 协议。要理解 SSE(Server-Sent Events,服务器发送事件),必须先厘清 HTTP 的标准运作模式。HTTP 协议本质上是一种基于“请求-响应”模型的无状态协议。在这种模型中,通信总是由客户端(通常是浏览器)发起的。客户端向服务器发送一个 HTTP 请求,服务器接收请求,处理数据,然后返回一个 HTTP 响应。一旦响应数据发送完毕,连接通常会被关闭,或者在空闲一段时间后断开。
这种设计在早期的互联网场景中非常高效,因为大多数网页浏览行为都是静态的:用户点击链接,获取页面,阅读内容。服务器不需要知道客户端在阅读页面时发生了什么,也不需要主动联系客户端。然而,随着 Web 应用的发展,动态获取数据的需求日益增加。例如,股票行情的实时更新、新闻推送或社交媒体的消息通知,这些场景都要求客户端能够及时感知服务器端的数据变化。
在标准 HTTP 模型下,如果客户端想要获取最新数据,必须再次发起一个新的请求。这种被动的方式导致了“轮询”技术的出现,即客户端每隔几秒钟自动发送一次请求询问服务器“有没有新数据”。这种做法虽然能模拟实时性,但效率极低,因为大量的请求可能得到的都是“没有新数据”的空回复,浪费了带宽和服务器资源。
为了解决服务器无法主动向客户端推送数据的问题,技术社区在 HTTP 协议的基础上演进出了多种方案,SSE 便是其中一种轻量级且优雅的解决方案。
SSE 全称是 Server-Sent Events,即服务器发送事件。它并不是一种全新的独立协议,而是基于 HTTP 协议的一种应用扩展。从网络协议栈的角度来看,SSE 依然使用标准的 HTTP 请求和响应。
HTTP 和 SSE 的关系可以理解为“父集与子集”或“基础与扩展”的关系。SSE 依赖于 HTTP 连接,但改变了 HTTP 响应的处理方式。在普通 HTTP 请求中,服务器返回完整的响应内容后,通信就结束了。而在 SSE 中,服务器在接收到客户端的请求后,返回的不是一次性数据,而是一个持续不断的“数据流”。

客户端通过标准的 HTTP 协议发起请求,但在请求头中或通过特定的 API 告知服务器,它希望建立一个 SSE 连接。服务器响应时,会将响应头中的 Content-Type 设置为 text/event-stream。这个特殊的 MIME 类型告诉客户端:这个响应不会立即结束,后续还会有更多的数据源源不断地传输过来。连接建立后,服务器可以随时向客户端发送文本数据,直到其中一方显式关闭连接。
这种机制使得 SSE 成为一种单向的、持久的通信通道。数据只能由服务器流向客户端,客户端无法通过同一个 SSE 连接向服务器发送数据(如果客户端需要发送数据,仍需发起新的标准 HTTP 请求)。这种设计非常适合“一次请求,多次推送”的场景。
SSE 虽然基于 HTTP,但在行为模式上已经产生了本质区别。普通的 HTTP 请求是“短跑”,目标是尽快完成数据传输并释放资源;SSE 则是“马拉松”,目标是维持连接以进行持续的数据同步。
SSE 引入了自动重连机制,这是标准 HTTP 请求所不具备的。在 EventSource 的实现中,如果网络出现波动导致连接中断,浏览器会自动尝试重新连接服务器,无需编写额外的重试代码。
此外,SSE 支持自定义事件类型。在前面的示例中,我们只处理了默认的 message 事件。实际上,服务器可以发送不同类型的事件,让客户端进行分类处理。
在服务端代码中,可以通过添加 event: 事件名\n 字段来实现:
// 修改服务端发送逻辑的示例
res.write('event: stockUpdate\n');
res.write('data: {"symbol": "AAPL", "price": 150}\n\n');
res.write('event: newsAlert\n');
res.write('data: 重大新闻播报...\n\n');
客户端则可以使用 addEventListener 监听特定事件:
eventSource.addEventListener('stockUpdate', (e) => {
console.log('股票更新', e.data);
});
为了更清晰地界定 HTTP、SSE 以及另一种常见的实时通信技术 WebSocket 之间的区别,我们通过表格进行多维度对比。这有助于在实际架构选型时做出正确判断。

表格中可以看出,SSE 处于标准 HTTP 和 WebSocket 之间的一个平衡点。当业务场景只需要服务器向客户端单向广播数据(例如大屏展示、即时报价)时,SSE 比 WebSocket 更简单、更轻量,且不需要改变现有的 HTTP 基础设施(如负载均衡器、防火墙配置)。而相比于轮询式的标准 HTTP 请求,SSE 又极大地降低了延迟和服务器负载。
SSE 并没有改变 HTTP 协议的底层逻辑,而是充分利用了 HTTP 长连接的特性。它将 HTTP 从一种“一问一答”的对讲机模式,转变为“广播电台”模式。
在实际开发中,如果应用程序的主要需求是“读取”实时数据,而非频繁地进行双向交互,SSE 是最佳选择。它避免了 WebSocket 协议升级带来的复杂性,同时提供了比 HTTP 轮询更好的性能表现。理解了 HTTP 是如何承载 SSE 的,也就掌握了在现有 Web 架构中实现低成本实时通信的关键钥匙。

END