企业官网建设流程全解析

easy-vibe 实时通信原理全解：Polling、SSE 与 WebSocket 的选型与实战

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

导读

在 AI 原生应用（如聊天机器人流式输出、实时行情面板、协同文档）中，浏览器如何持续获得服务端的新数据，是前端开发者必须掌握的核心能力。本文以 easy-vibe 课程仓库中「3-browser-and-frontend」附录章节为基础，系统讲解传统 HTTP 的「请求-响应」局限，以及短轮询（Polling）、服务器推送事件（SSE）、全双工 WebSocket 三种实时通信方案的原理、代码形态与适用场景，并结合仓库内置的交互式演示组件源码，帮助你在真实业务中做出正确的技术选型。

1. 传统 HTTP 的局限性：为什么「一问一答」不够用

HTTP 协议的设计初衷是文档检索，它的两个本质特征决定了其在实时场景中的天花板：

1. 无状态（Stateless）：服务端不记忆客户端之前的交互上下文；
2. 由客户端单向发起：只有客户端主动发起请求，服务端才能返回数据。

一次完整的交互流程是：客户端发起 HTTP 请求 → 服务端处理并返回响应 → 连接完成任务后释放逻辑请求（HTTP/1.1 虽然支持 Keep-Alive 长连接复用，但业务层面的「请求-响应」模型并未改变）。

在这个模型下，服务端永远无法主动将状态变化通知正在等待的客户端。聊天室的新消息、股票行情的价格变动、后台异步任务的完成……这些「服务端先知道」的变化，都需要另寻技术方案才能推送到浏览器。这正是本篇要解决的三个方案出现的背景。

本主题在仓库中的原始章节为 docs/de-de/appendix/3-browser-and-frontend/realtime-communication.md，仓库同时提供了多语言版本，例如 中文版。

2. 短轮询（Polling）：最简单，也最「贵」

2.1 工作原理

最直接的解决方案是短轮询（Short Polling）：客户端利用定时器（如setInterval），每隔一段固定时间自动向服务端发送 HTTP 请求，询问「有没有新数据」。

// 每 3 秒向服务端询问一次是否有新数据 setInterval(async () => { const res = await fetch('/api/messages/check'); const data = await res.json(); if (data.hasNew) { renderMessages(data.messages); } }, 3000);

2.2 仓库演示组件的实现印证

easy-vibe 仓库为本章配置了交互式演示组件 PollingDemo.vue，其核心逻辑与上方的代码形态完全一致：

• 点击「开始轮询」后立即执行一次performPoll()，随后setInterval(performPoll, 2500)每2.5 秒发起一次询问（对应源码 PollingDemo.vue#L105-L116）；
• 每次轮询模拟一次完整的请求-响应往返：客户端发送询问 → 服务端返回yes（有新消息）或no（无新消息）；
• 日志面板会记录每次轮询的时间戳与结果，直观展示「大多数轮询都在空转」的现象。

从源码可以看到，服务端「无新消息」时，浏览器依然要完成一次完整的 HTTP 请求与响应。这就是短轮询效率低下的根源。

2.3 技术特点与局限

• 优点：实现机制极其简单，完全依赖标准的 HTTP 协议和 AJAX/Fetch 技术，任何后端语言都能零成本支持。
• 缺点：
  • 产生巨大的网络开销与资源浪费。大多数时候服务端响应是「无新数据」，但无论有无数据，每次请求都必须携带完整的 HTTP 头部（Headers、Cookies 等）；
  • 在并发量较高的场景下，大量无意义的查询会占据网络与服务器资源；
  • 轮询间隔与实时性存在矛盾：间隔短则开销大，间隔长则数据延迟高。

典型适用场景：定时检查后台异步任务的完成状态（如导出文件是否生成）、低频率的状态刷新。这类场景对实时性要求不高，用短轮询换取实现简单是完全合理的取舍。

3. 服务器推送事件（SSE）：单向流式推送的轻量方案

3.1 工作原理

Server-Sent Events（SSE）提供了一种轻型的单向数据流推送架构，用来解决「频繁建立 HTTP 连接」的开销问题。

SSE 依然建立在 HTTP 协议之上，但客户端需要发起一个携带特殊请求头的请求：

// 客户端：发起 SSE 连接 const eventSource = new EventSource('/api/stream'); // 监听默认消息事件 eventSource.onmessage = (event) => { renderStreamText(event.data); }; // 监听自定义事件（如 news、quote） eventSource.addEventListener('news', (event) => { renderNews(JSON.parse(event.data)); });

关键点在于请求头Accept: text/event-stream。服务端识别该头后，在返回响应时保持底层的 TCP 连接不断开，随后即可通过这条持久通道持续推送文本数据：

GET /api/stream HTTP/1.1 Host: example.com Accept: text/event-stream HTTP/1.1 200 OK Content-Type: text/event-stream data: {"price": 3012.3}\n\n data: {"price": 3015.8}\n\n

推送数据的格式是 Event Stream 文本格式：每个事件由data:行组成，事件之间以空行分隔。

3.2 仓库演示组件的实现印证

仓库中的 SSEDemo.vue 演示了典型的 SSE 应用——实时行情推送：

• 点击「连接」后，客户端与服务端之间建立一条持久管道（界面中用流动的管道动画表示）；
• 点击「推送数据」，服务端模拟推送随机行情：SSE 3012.3、Moutai ¥1750、CATL Limit Up等（对应源码 SSEDemo.vue#L90-L103）；
• 数据沿单向通道从服务端流向客户端，客户端只负责接收渲染，无需向服务端发送内容。

该演示精准体现了 SSE 的定位：连接持久化、单向推送、低开销。

3.3 技术特点与局限

• 优点：
  • 连接持久化，网络开销小；
  • 浏览器原生支持断线自动重连机制（EventSource API 内置），服务端还可以通过发送id:字段让客户端在重连时携带 Last-Event-ID 实现断点续传；
  • 非常适合单向传输流式数据：大语言模型的文本逐字输出、实时交易行情推送、新闻或系统通知推送。
• 缺点：通信通道是单向的。如果客户端需要向服务端发送控制指令或新数据，必须另外建立普通的 HTTP 请求（典型的「SSE 下行 + POST 上行」组合模式）。

4. WebSocket：真正的全双工实时通信协议

4.1 工作原理

当应用场景涉及高频的双向交互（多人在线动作游戏、精密的协同文档编辑、实时音视频信令）时，单向推送已经不够用。我们需要一种既能降低通信开销、又能实现真正双工通信的技术——WebSocket。

WebSocket 是一种独立的网络通信协议（基于 TCP），但它精妙地借助 HTTP 协议完成初始建连，整个过程分为三个阶段：

① 握手阶段（Handshake）：客户端发送一个特殊的 HTTP 请求，声明希望升级为新协议：

GET /ws HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13

② 连接质变（Protocol Switch）：服务端若支持并同意该协议，则回复状态码101 Switching Protocols，同时返回Sec-WebSocket-Accept响应头完成校验。

③ 彻底自由（Full-Duplex）：此时 HTTP 的规范使命结束，底层 TCP 连接被移交给 WebSocket 协议。此后客户端与服务端享有平等的全双工通信权利，双方可随时收发极简格式的数据帧。

// 客户端：建立 WebSocket 连接并双向通信 const ws = new WebSocket('wss://example.com/ws'); ws.onopen = () => { // 连接建立后，客户端可以主动发消息 ws.send(JSON.stringify({ type: 'move', x: 120, y: 80 })); }; ws.onmessage = (event) => { // 服务端也可以随时主动推送 updateGameState(JSON.parse(event.data)); };

4.2 仓库演示组件的实现印证

仓库中的 WebSocketDemo.vue 与本章的<WebSocketDemo />组件对应，演示了连接建立后的双向消息收发。与 PollingDemo、SSEDemo 的单向动画不同，WebSocket 演示中客户端与服务端两侧都可以主动发起消息，直观呈现「平等收发权」。

4.3 技术特点与局限

• 优点：
  • 支持真正意义上的双向实时通信；
  • 数据帧的头部信息极小（仅数字节，相比 HTTP 头部动辄几百字节），通信延迟低、吞吐效率高；
  • 支持原生二进制数据（ArrayBuffer、Blob）的传输，适合游戏状态同步、音视频数据等场景。
• 缺点：
  • 架构与开发复杂性较高：需要专门的 WebSocket 服务端实现、额外的协议处理与消息协议设计；
  • 由于维护着持久长连接，对服务器端的系统架构、负载均衡策略（需要支持连接亲和性/会话保持）和心跳监测设计（防空闲断连、检测死连接）提出了更严格的工程要求。

5. 总结：三种方案的技术选型对比

选型决策建议

在实际工程中，开发者应依据具体业务场景对实时性与双向交互频率的要求，在系统的维护复杂度和通信效率之间取得平衡：

• 对实时性要求不高、实现优先 →短轮询（或升级为 Long Polling 长轮询作为过渡方案）；
• 服务端单向推送、且希望获得浏览器原生断线重连 →SSE（尤其适合对接大模型流式输出，这也是 AI 原生应用中最常见的组合）；
• 高频双向交互、低延迟、需要二进制传输 →WebSocket。

延伸阅读

本主题属于 easy-vibe 课程「浏览器与前端」知识附录，读者可以继续深入仓库中的相关章节：

• 附录章节入口：docs/de-de/appendix/3-browser-and-frontend/index.md（以及 中文版索引）
• 交互式演示组件源码：PollingDemo.vue、SSEDemo.vue、WebSocketDemo.vue
• 与实时通信相关的后端与架构知识：API 设计、异步任务队列

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe