手把手教你用CMake和Ninja在Windows上编译免费Aseprite（附Skia配置避坑指南）
2026/5/16 9:28:06
SSE（Server-Sent Events，服务器发送事件）和WebSocket都是实现「服务器主动向客户端推送数据」的技术，但核心设计、通信模式、适用场景差异显著。面试回答时，建议先总述核心区别，再从通信特性、协议基础、使用成本、场景适配四个维度拆解，最后结合实际场景给出选型逻辑，既体现原理理解，又落地项目实践。
一、核心总述
SSE是基于HTTP的单向推送协议，仅支持服务器→客户端的单方向数据传输，主打“简单、低成本、内置重连”；WebSocket是独立的全双工通信协议，支持客户端↔服务器双向实时通信，主打“低延迟、高灵活、双向交互”。两者的核心差异源于协议设计目标：SSE聚焦“极简的单向推送”，WebSocket聚焦“全场景的双向实时交互”。
二、关键维度对比（面试核心）
| 维度 | SSE（Server-Sent Events） | WebSocket |
|---|---|---|
| 通信方向 | 单向（服务器→客户端） 客户端仅能通过HTTP请求（如POST）被动回传数据，无法主动推 | 全双工（双向） 连接建立后，双方可随时互发数据，无需额外请求 |
| 协议基础 | 基于HTTP/1.1，复用HTTP协议栈（端口80/443） 响应头固定： Content-Type: text/event-stream，本质是“长连接的HTTP响应流” | 独立应用层协议（RFC6455） 先通过HTTP“握手”（发送 Upgrade: websocket请求）升级连接，之后脱离HTTP，用自定义帧格式传输 |
| 连接特性 | 1. 浏览器内置自动重连（通过retry字段控制重连间隔，断开后自动重试）2. 连接轻量，无需手动维护心跳（服务器发空注释帧 :保活即可） | 1. 无内置重连，需手动实现（监听onclose事件，自行写重连逻辑）2. 需手动维护心跳（ping/pong帧），否则易被网关断开连接 |
| 数据格式/传输 | 仅支持UTF-8文本格式 服务器按固定格式（ event/data/id/retry字段）发送事件流，浏览器自动解析为EventSource事件（支持事件分类） | 支持文本（UTF-8）+二进制数据（如图片、视频流） 数据帧无HTTP头开销，传输效率更高，可自定义格式（JSON/Protobuf等） |
| 兼容性/使用成本 | 1. 兼容性：IE不支持，其余现代浏览器全支持 2. 成本极低： 客户端： new EventSource('/sse')几行代码搞定服务器：仅需按格式输出文本流 | 1. 兼容性：IE10+支持，覆盖更广 2. 成本较高： 客户端：需处理握手、重连、帧解析 服务器：需实现WebSocket协议（如Netty/Spring WebSocket），且需配置网关允许 Upgrade请求 |
| 网关/代理适配 | 完全兼容HTTP网关/CDN（无需额外配置），因为本质是HTTP请求 | 部分老旧网关/代理会拦截Upgrade握手请求，需额外配置（如Nginx开启proxy_set_header Upgrade $http_upgrade;） |
三、核心原理拆解（补充深度）
1. SSE的底层工作逻辑
SSE的核心是“HTTP长连接的响应流”：
- 客户端发起GET请求，服务器返回
200 OK并设置text/event-stream响应头，且不关闭连接； - 服务器持续向客户端推送格式化文本（如
data: 订单状态更新为已发货\n\n），每段数据以\n\n结尾，浏览器的EventSource会自动解析并触发onmessage事件； - 连接断开后，浏览器根据
retry字段（默认3秒）自动重新发起请求，无需前端写重连代码。
2. WebSocket的底层工作逻辑
WebSocket分“握手+通信”两步：
- 握手阶段：客户端发送HTTP请求，携带
Upgrade: websocket、Sec-WebSocket-Key等头，服务器验证后返回101 Switching Protocols，连接升级为WebSocket； - 通信阶段：双方通过“帧（Frame）”传输数据（如文本帧、二进制帧、ping/pong帧），帧头仅2-10字节，远轻于HTTP头，且支持分片传输大数据。
四、适用场景（结合项目落地，面试加分）
1. 优先选SSE的场景（单向推送）
- 实时通知：订单状态更新、系统告警、消息提醒（如你仿Coze项目中MCP工具调用的状态推送：“工具执行中/成功/失败”）；
- 数据监控：后台仪表盘实时数据（如CPU使用率、接口QPS）、日志流推送；
- 极简需求：无需客户端回传数据，追求“零配置、低开发成本”。
2. 优先选WebSocket的场景（双向交互）
- 即时通信：在线聊天（如Coze的实时对话）、弹幕、客服对话；
- 实时协作：多人在线编辑文档、在线游戏（需客户端频繁发操作指令，服务器实时回传结果）；
- 高频双向交互：金融行情（客户端订阅/取消订阅，服务器推实时行情）、物联网设备控制（客户端发指令，服务器推设备状态）。
五、面试总结（精简版）
SSE和WebSocket的核心区别是“单向极简” vs “双向灵活”：
- SSE基于HTTP，单向推送、内置重连、成本极低，适合仅需服务器推数据的场景（如通知、监控）；
- WebSocket是独立协议，全双工、低延迟、支持二进制，适合需要双向实时交互的场景（如聊天、游戏）。
在我仿Coze的项目中，MCP工具调用的状态推送用了SSE（仅需服务器推执行状态，无需客户端回传），而实时对话模块若要优化体验，会考虑WebSocket（用户发消息、AI实时回，双向交互更高效）。这种选型的核心是“匹配场景需求，避免过度设计”——SSE能满足的单向推送需求，无需用复杂的WebSocket。