SSE、WebSocket、普通 HTTP 与长短轮询有什么区别？

核心回答

长短轮询与 SSE 都基于 HTTP；它们与普通请求的区别在于等待和返回更新的方式。WebSocket 则提供持续的双向消息通道。

• 普通 HTTP 请求/响应：客户端发起一次请求，服务器返回本次结果，适合查询、提交和上传等交互。响应结束不代表底层连接一定关闭，后续请求可以复用连接。
• 短轮询：客户端按间隔重复请求。有无更新都及时返回，实现简单，但会有空请求，发现更新的延迟受轮询间隔影响。
• 长轮询：没有新数据时，服务器暂时挂起请求；有数据或超时后返回，客户端再发起下一次请求。能减少空响应，但仍有请求续接和超时管理成本。
• SSE：客户端发起 HTTP 请求，服务器在同一个响应中持续发送 UTF-8 事件流，适合进度、通知和模型文本输出。事件流里的业务数据从服务器发向客户端；原生 EventSource 提供事件解析和自动重连等能力。
• WebSocket：握手后，双方可以在同一消息通道中主动发送文本或二进制消息，适合聊天、协作和高频交互。需要管理连接、心跳、重连以及应用消息恢复。

选型先看是否需要持续更新、是否需要双向主动发消息：偶尔查状态可用普通请求或短轮询；希望及时收到更新且沿用请求/响应可用长轮询；主要由服务端持续推送可用 SSE；持续双向交互再考虑 WebSocket。

流式响应和双向交互怎样区分？

例如用户提交一个问数问题，后端持续返回处理进度和查询结果，主要数据流是服务端到客户端，SSE 就能满足需求。用户取消任务或提交下一条问题，可以另发 HTTP 请求，不必因为页面也有输入操作就选择 WebSocket。

如果双方都要频繁主动发消息，例如协作文档持续同步操作和状态，WebSocket 的同一消息通道更合适。但选用了 WebSocket，也可以继续用普通 HTTP 上传文件或提交任务，不必把所有接口都塞进这个通道。

普通 HTTP 也可以持续传输响应体；SSE 在流式响应上约定了事件格式，如 data、event、id 字段和事件边界，并不等同于所有流式 HTTP。SSE 保持 HTTP 响应语义；经典 HTTP/1.1 WebSocket 握手通过协议升级建立消息通道，后续按 WebSocket 消息帧通信。

长轮询则通常在收到一批数据后结束本次响应，再发新请求；SSE 可以在一次持续的响应里接收多条事件，因此更新频繁时可减少重复请求和响应头的开销。

自动重连是否意味着不会丢消息？

重连和补齐消息是两件事。 原生 EventSource 在可恢复的断线后会重连；服务端发送的 id 可以让客户端记录事件位置，重连时通过 Last-Event-ID 告知服务端，retry 可以调整重连等待时间。

但协议不会替服务端保存历史消息。要接着上次的位置恢复，服务端还需要保留可重放事件、按 ID 补发，客户端处理可能重复的事件；超出保留范围时，可重新拉取快照。任务正常结束后，也应按业务结束事件关闭客户端事件源，避免再次重连。

有些接口通过 POST 返回 SSE 格式的流，例如问数项目的查询接口。这时需要相应的流式客户端，不能把原生 EventSource 的解析、重连和事件 ID 处理直接当成所有流式客户端都有的功能。

WebSocket 在连接正常时提供有序的消息传输，但断线、进程重启和业务处理失败仍会留下恢复问题。浏览器原生 WebSocket API 不自动提供重连和历史消息补发；需要时应设计退避重连、消息 ID、业务确认、补发和幂等。Ping/Pong 或心跳主要帮助判断连接活性，不等于业务消息已经处理成功。

连接和代理方面有什么成本？

短轮询容易部署，但间隔过短会放大空请求；长轮询需要维持挂起请求并处理续接。SSE 和 WebSocket 都需要长期维护活跃通道，关注连接或流数量、内存、空闲超时和慢客户端积压，服务端不能为慢连接无限缓存消息。

SSE 使用 HTTP，也要检查反向代理是否缓冲响应、事件能否及时刷新、空闲连接是否被关闭。WebSocket 则要确认代理支持相应握手和转发，并在多实例部署时安排消息路由；重连后可能进入其他实例，恢复状态不能只靠原连接内存。

这些成本不能简单换算成“一个请求就新建一条 TCP”或“SSE 永远只有固定连接数”。HTTP/1.1 可以复用连接，HTTP/2 可以在同一连接上承载多个流；实际限制还取决于浏览器、HTTP 版本和网关配置。

对应教程

参考资料