在什么情况下你会使用 WebSocket、SSE 或 long-polling 而非普通 HTTP？

Question

IT Interview Practice · Accepted Answer

普通 HTTP 是**请求/响应（request/response）**：客户端发问，服务器作答，结束。这对**实时（real-time）**功能（聊天、实时仪表盘、通知、协同编辑）很不合适，因为在这些场景中*服务器*需要在有新数据时随时推送。这些选项是绕开 HTTP 由客户端发起的模型的各种办法，沿着一条复杂度谱系排列：

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** 是到处都能用的兜底方案：客户端发出一个普通请求，服务器把它挂起直到有数据，然后客户端立即再次请求。它在普通 HTTP 上近似实现了推送，但每条消息浪费一个请求周期并增加延迟。

**SSE（Server-Sent Events）**是一条轻量、已标准化的**单向**流（server → client），承载于一个长期存活的 HTTP response 之上。当只有服务器推送时它很理想——实时 feed、通知、进度、流式的 LLM token。它简单，运行在普通 HTTP/2 上（无需特殊基础设施），并自动重连。局限：它是单向的且仅限文本。

**WebSocket** 把一条 HTTP 连接升级为一条持久的、**全双工（full-duplex）**的 TCP 通道，双方随时都能以极小的每消息开销发送。将它用于真正双向、低延迟的交互：聊天、多人游戏、协同编辑器、交易。代价在运维——它是一条有状态的连接，proxy、load balancer 和 autoscaler 都必须为它配置，且你必须自己构建重连、心跳和背压（backpressure）。

**经验法则：**默认用普通 HTTP；用 **SSE** 做 server→client 的流；只有在你真正需要双向实时时才动用 **WebSocket**；把 **long-polling** 留作通用兜底。

## 为什么这很重要

选择一种实时传输是一个经典的高级设计决策，其中天真的答案（“凡事都用 WebSocket”）通常是错的。面试官想看到你把工具与*通信模式*匹配——单向 vs 双向、延迟需求、消息量——并且你权衡有状态、长期存活连接的**运维成本**：sticky session、扩展、proxy 超时和重连逻辑。认识到 SSE 常常比 WebSocket 更简单地覆盖“服务器推送更新”，且 long-polling 仍是一个稳健的兜底，表明真实的生产经验，而不是伸手去抓最花哨的选项。

为什么这很重要

相关问题