HTTP 协议的基础运作模式
互联网数据的传输基石是 HTTP 协议。要理解 SSE（Server-Sent Events，服务器发送事件），必须先厘清 HTTP 的标准运作模式。HTTP 协议本质上是一种基于“请求-响应”模型的无状态协议。在这种模型中，通信总是由客户端（通常是浏览器）发起的。客户端向服务器发送一个 HTTP 请求，服务器接收请求，处理数据，然后返回一个 HTTP 响应。一旦响应数据发送完毕，连接通常会被关闭，或者在空闲一段时间后断开。
这种设计在早期的互联网场景中非常高效，因为大多数网页浏览行为都是静态的：用户点击链接，获取页面，阅读内容。服务器不需要知道客户端在阅读页面时发生了什么，也不需要主动联系客户端。然而，随着 Web 应用的发展，动态获取数据的需求日益增加。例如，股票行情的实时更新、新闻推送或社交媒体的消息通知，这些场景都要求客户端能够及时感知服务器端的数据变化。
在标准 HTTP 模型下，如果客户端想要获取最新数据，必须再次发起一个新的请求。这种被动的方式导致了“轮询”技术的出现，即客户端每隔几秒钟自动发送一次请求询问服务器“有没有新数据”。这种做法虽然能模拟实时性，但效率极低，因为大量的请求可能得到的都是“没有新数据”的空回复，浪费了带宽和服务器资源。
为了解决服务器无法主动向客户端推送数据的问题，技术社区在 HTTP 协议的基础上演进出了多种方案，SSE 便是其中一种轻量级且优雅的解决方案。
SSE 的定义及其与 HTTP 的关系
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 请求）。这种设计非常适合“一次请求，多次推送”的场景。
HTTP 与 SSE 的关键差异分析
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 之间的区别，我们通过表格进行多维度对比。这有助于在实际架构选型时做出正确判断。
| 特性 | 标准 HTTP | SSE (Server-Sent Events) | WebSocket |
|---|---|---|---|
| 通信方向 | 单向（客户端请求 -> 服务器响应） | 单向（服务器推送 -> 客户端） | 双向全双工（客户端 <-> 服务器） |
| 连接生命周期 | 短连接（响应即断开） | 长连接（持续保持） | 长连接（持续保持） |
| 协议基础 | HTTP | HTTP | 握手阶段基于 HTTP，随后升级为 TCP |
| 数据格式 | 任意（文本、二进制） | 仅限 UTF-8 文本流 | 任意（文本、二进制） |
| 重连机制 | 无（需手动实现重试） | 浏览器内置自动重连 | 无（需手动实现心跳和重连） |
| 复杂程度 | 低 | 低（使用简单的 HTTP API） | 高（需要专门的协议处理） |
| 典型场景 | 网页浏览、API 调用 | 股票行情、日志监控、消息通知 | 在线游戏、聊天室、协作编辑 |
表格中可以看出，SSE 处于标准 HTTP 和 WebSocket 之间的一个平衡点。当业务场景只需要服务器向客户端单向广播数据（例如大屏展示、即时报价）时，SSE 比 WebSocket 更简单、更轻量，且不需要改变现有的 HTTP 基础设施（如负载均衡器、防火墙配置）。而相比于轮询式的标准 HTTP 请求，SSE 又极大地降低了延迟和服务器负载。
总结 SSE 的应用价值
SSE 并没有改变 HTTP 协议的底层逻辑，而是充分利用了 HTTP 长连接的特性。它将 HTTP 从一种“一问一答”的对讲机模式，转变为“广播电台”模式。
在实际开发中，如果应用程序的主要需求是“读取”实时数据，而非频繁地进行双向交互，SSE 是最佳选择。它避免了 WebSocket 协议升级带来的复杂性，同时提供了比 HTTP 轮询更好的性能表现。理解了 HTTP 是如何承载 SSE 的，也就掌握了在现有 Web 架构中实现低成本实时通信的关键钥匙。
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、API 调试、API 设计、API 测试、API Mock、自动化测试等功能于一体的 API 管理工具，Apifox 可以说是开发者提升效率的必备工具之一。
如果你正在开发项目需要进行接口调试，不妨试试 Apifox。注册过程非常简单，你可以直接在这里注册使用。
注册成功后可以先看看官方提供的示例项目，这些案例都是经过精心设计的，能帮助你快速了解 Apifox 的主要功能。
使用 Apifox 的一大优势是它完全兼容 Postman 和 Swagger 数据格式，如果你之前使用过这些工具，数据导入会非常方便。而且它的界面设计非常友好，即使是第一次接触的新手也能很快上手，快去试试吧！
