常用 Web 实时通信技术原理选型一篇通关

在 Web 开发中，实时通信技术的核心目标是实现客户端（Browser）与服务器之间低延迟、双向/单向的动态数据交互，而非传统 HTTP 的"请求-响应"模式。

以下是 Web 端最常用的实时通信技术，从概念、原理特点、适用场景、对比选型进行详细解析。

1. WebSocket

1.1. 核心概念

WebSocket 是 Web 端实时通信的"基础设施"，通过全双工长连接和轻量帧传输，解决了 HTTP 单向短连接的局限性，成为即时通讯、协作工具、实时监控等场景的首选技术。
其与 HTTP 并非替代关系，而是互补——HTTP 适用于"请求-响应"场景（如页面加载），WebSocket 适用于"双向实时交互"场景。

1.2. 原理介绍

WebSocket 的工作流程分为握手协议升级、数据帧传输和连接管理三个阶段：

1.2.1. 握手阶段：基于 HTTP 升级协议

WebSocket 连接的建立依赖 HTTP 协议完成"握手"，本质是将 HTTP 连接升级为 WebSocket 连接：

  • 客户端发起请求：发送特殊的 HTTP GET 请求，声明协议升级意向：
GET /ws HTTP/1.1
Host: example.com
Connection: Upgrade  # 告诉服务端：这是一个"升级请求"，不要按普通 HTTP 处理
Upgrade: websocket   # 核心：请求升级到 WebSocket 协议
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  # 随机字符串，用于服务端验证（防伪造请求）
Sec-WebSocket-Version: 13  # 客户端支持的 WebSocket 版本（必须是 13，现代标准）
  • 服务器响应确认：验证请求后返回 101 Switching Protocols 响应，确认升级：
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  # 由客户端的 Sec-WebSocket-Key 计算而来（验证身份）
  • 连接建立：握手成功后，底层 TCP 连接被复用，后续通信脱离 HTTP 协议。

1.2.2. 数据传输：基于帧结构的高效通信

WebSocket 采用二进制帧（Frame）格式传输数据，帧结构仅包含"操作码（Opcode）、掩码、数据长度、数据载荷"等核心字段（头部仅 2-14 字节），无 HTTP 头冗余，传输效率极高：

  • 操作码：区分数据类型（0x01 文本数据、0x02 二进制数据、0x08 断开连接）；

  • 掩码：客户端发送数据必须加掩码（防止代理缓存污染），服务器返回数据无需加掩码；

  • 优势：支持文本、图片、视频流等任意数据类型，双向通信延迟可低至毫秒级。

1.2.3. 连接管理：保活与断开

  • 心跳保活：为避免 TCP 连接因"长时间无数据"被网络设备（如路由器）断开，WebSocket 内置Ping/Pong 心跳机制：服务器定期发送 Ping 帧，客户端必须回传 Pong 帧；若超时未收到 Pong，判定连接失效并主动断开。

  • 主动断开：任何一方发送 Opcode=0x08 的关闭帧，双方确认后关闭 TCP 连接。

1.3. 为什么在握手阶段需要升级协议

WebSocket 并非完全脱离 HTTP，而是借助 HTTP 协议的"握手流程"完成"协议切换"——通过一次 HTTP 请求，让客户端和服务端达成共识：“接下来我们用 WebSocket 协议通信，不再遵循 HTTP 规则”。

这个升级过程的核心价值是：

  • 兼容现有网络环境：所有浏览器、网关、代理服务器都支持 HTTP；如果 WebSocket 设计成完全独立的协议，可能被现有网络设备拦截（无法穿透代理/防火墙）。

  • 低成本建立"长连接共识"：利用 HTTP 握手的"请求-响应"流程，让双方快速确认"支持 WebSocket"，避免额外的协议协商开销。

1.4. WebSocket 和 HTTP 的关系

WebSocket 和 HTTP 的关系

1.5. 应用场景

WebSocket 适用于需要低延迟、双向实时通信的场景，典型案例包括：

  • 即时通讯工具：如网页版微信、企业微信、在线客服系统等，需实时收发消息，WebSocket 可保证消息更实时。

  • 实时协作工具：如腾讯文档、飞书文档等，多人同时编辑时，需实时同步光标位置、内容修改，WebSocket 可确保协作流畅。

  • 金融行情更新：股票、期货等实时行情数据（每秒多次更新），通过 WebSocket 推送，比轮询更高效。

  • 在线游戏：网页小游戏（如贪吃蛇联机版）需要实时同步玩家操作和游戏状态，WebSocket 可满足低延迟需求。

  • 实时监控系统：如物联网设备监控（温度、湿度实时数据）、服务器性能监控，需持续接收设备/服务器推送的状态数据。

  • 弹幕系统：视频网站的实时弹幕，数千级用户同时发送和接收弹幕，WebSocket 可支撑高并发推送。

2. Server-Sent Events（SSE）

2.1. 核心概念

SSE（Server-Sent Events，服务器发送事件）是一种基于 HTTP 协议的服务器向客户端单向实时推送数据的技术，专为"服务器主动向客户端持续发送更新"场景设计，是 Web 端实时通信的重要方案之一。

SSE 的核心是建立一个持久化的 HTTP 长连接，让服务器可以随时向客户端推送数据，而无需客户端频繁发起请求。
它是一种"服务器到客户端"的单向通信模式，与 WebSocket 的双向通信形成互补。

其优势在于：

  • 原生支持自动重连
  • API 简单（EventSource 接口）
  • 服务器实现成本低
  • 适合无需客户端回传数据的场景

与 WebSocket 相比，SSE 更专注于单向推送，实现和维护成本更低，是实时通知、日志展示等场景的理想选择。

2.1.1. 关键特性

  • 单向通信：仅支持服务器向客户端推送数据，客户端无法通过 SSE 向服务器发送数据（需配合 HTTP 或 WebSocket 实现双向交互）；

  • 长连接：一次连接建立后持续保持，避免短连接的反复握手开销；

  • 自动重连：连接意外断开时，客户端会自动重试连接（默认间隔 3 秒）；

  • 文本流：数据以 UTF-8 文本流格式传输，二进制数据需编码后发送。

2.2. 原理介绍

SSE 的工作流程基于 HTTP 长连接和特殊的文本流协议，主要分为连接建立、数据推送和重连机制三个阶段：

2.2.1. 连接建立：基于 HTTP 的长连接初始化

客户端通过浏览器原生的 EventSource API 发起连接请求，服务器返回符合 SSE 规范的响应头，建立持久化连接：

  • 客户端请求：
// 客户端创建 SSE 连接（仅支持 GET 方法）
const sse = new EventSource('/service/stream');

浏览器会自动发送 HTTP 请求，携带特殊头信息（如 Accept: text/event-stream）。

  • 服务器响应头：
HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8  # 核心：标识为 SSE 流
Cache-Control: no-cache  # 禁止缓存，确保客户端接收实时数据
Connection: keep-alive   # 保持 HTTP 长连接
Access-Control-Allow-Origin: *  # 跨域配置（如需）

响应头必须明确指定 text/event-stream 类型，告知客户端"这是持续的事件流"。

2.2.2. 数据推送：基于规范的文本流格式

服务器通过 HTTP 长连接持续向客户端发送"事件"，每个事件需遵循严格的文本格式，以 \n\n 作为结束符：

# 格式 1：默认事件（客户端通过 onmessage 接收）
data: 您有一条新消息
data: 内容：Hello World

# 格式 2：自定义事件名（客户端通过 addEventListener 接收）
event: orderStatus  # 事件名（如"订单状态更新"）
id: 10086           # 事件 ID（用于重连时定位断点）
data: 订单已发货

# 格式 3：心跳保活（客户端忽略，仅维持连接）
: 这是注释，无实际数据，防止长连接超时

2.2.3. 重连机制：自动恢复连接与数据补发

SSE 原生支持断线重连，无需手动实现：

  • 自动重连：若连接意外断开（如网络波动），客户端会在 3 秒后自动重试，并逐渐增加间隔（最多 30 秒）；

  • 数据补发：重连时，客户端会在请求头中携带 Last-Event-ID: 1000000（最后接收的事件 ID），服务器可基于此补发断点后的所有数据，避免数据丢失。

2.2.4. 事件流流程图

事件流流程图

2.3. 应用场景

SSE 适用于服务器需主动向客户端单向推送数据的场景，典型案例包括：

  • AI 智能助手：SSE 支持 AI 助手的流式输出，以"打字机"效果逐字逐句呈现给用户，提升用户体验，增强用户与 AI 助手的交互感。

  • 实时通知系统：社交应用的消息提醒（“收到新评论”），服务器可通过 SSE 实时推送通知，无需客户端频繁轮询。

  • 日志/状态实时展示：如后端任务执行日志（部署进度、测试报告）、CI/CD 流水线状态，服务器可实时推送日志片段，客户端实时展示（类似终端输出）。

  • 新闻/资讯推送：如实时新闻客户端、股票资讯，服务器在有新内容（突发新闻、股价变动）时，通过 SSE 立即推送给订阅用户。

  • 监控数据展示：如服务器 CPU 使用率、网络流量等监控指标，每秒/每分钟推送一次更新，客户端实时绘制监控曲线。

  • 多人协作中的状态同步：如在线文档的"他人正在编辑"状态提示，服务器可通过 SSE 向所有协作者推送当前编辑者的操作状态。

3. WebRTC：点对点实时通信

3.1. 核心概念

WebRTC（Web Real-Time Communication，网页实时通信）是一项浏览器原生支持的实时通信技术标准，允许浏览器之间直接建立点对点（P2P）连接，实现音视频通话、数据传输等实时交互，无需依赖第三方插件或额外软件。

WebRTC 的核心目标是打破传统实时通信对中间服务器的强依赖，让浏览器之间能够直接传输数据（音视频、文本、文件等），其关键特性包括：

  • 点对点通信：数据主要在客户端之间直接传输（仅信号协商需服务器参与），减少延迟和服务器带宽压力；

  • 原生浏览器支持：无需安装插件，通过 JavaScript API 即可调用（如 getUserMedia 捕获音视频、RTCPeerConnection 建立连接）；

  • 实时强劲：基于 UDP 协议传输（部分场景降级为 TCP），延迟可低至 100-200 毫秒，满足实时交互需求；

  • 安全性内置：所有数据强制加密传输（通过 SRTP 协议），防止窃听和篡改。

3.2. 原理介绍

WebRTC 的工作流程可分为信号协商、P2P 连接建立和媒体流传输三个核心阶段，其中"信号协商"需借助服务器，而实际数据传输则在客户端之间直接进行。

3.2.1. 信号协商（Signaling）：发现与连接准备

浏览器（客户端）无法直接知道对方的网络位置（IP 地址、端口），需通过"信号服务器"交换连接所需的元数据（如网络信息、媒体能力）：

  • 交换的核心信息：

    • SDP（Session Description Protocol）：描述本地媒体能力（如支持的音视频编码格式、分辨率、采样率等），分为 offer（发起方提议）和 answer（接收方应答）；

    • ICE 候选地址（ICE Candidate）：包含本地网络可被访问的 IP 地址和端口（需穿透 NAT 网络地址转换）。

  • 流程示例：

    • 客户端 A 生成 SDP offer 并通过信号服务器发送给客户端 B；

    • 客户端 B 收到 offer 后，生成 SDP answer 并通过信号服务器返回给 A；

    • 双方分别收集自身的 ICE 候选地址（如本地局域网地址、NAT 转换后的公网地址），并通过信号服务器互相发送；

    • 双方根据收到的 SDP 和 ICE 信息，确定最优通信路径。

3.2.2. P2P 连接建立：穿透 NAT 与防火墙

由于多数设备处于 NAT（网络地址转换）或防火墙后，直接建立 P2P 连接需解决"地址可达性"问题，WebRTC 通过ICE（Interactive Connectivity Establishment）协议实现：

  • ICE 工作原理：

    • 首先尝试"主机候选地址"（本地局域网 IP），若双方在同一局域网，直接建立连接；

    • 若失败，尝试"服务器反射候选地址"（通过 STUN 服务器获取 NAT 转换后的公网地址）；

    • 若仍失败（如严格对称 NAT 环境），则通过 TURN 服务器中转数据（作为最后的 fallback 方案）。

  • 关键服务器：

    • STUN 服务器：帮助设备获取自身的公网 IP 和端口（用于 NAT 穿透）；

    • TURN 服务器：在 P2P 连接失败时，作为中继服务器转发数据（确保通信不中断，但增加延迟）。

3.2.3. 媒体流传输：实时音视频与数据交互

连接建立后，WebRTC 通过两套核心 API 实现数据传输：

  • 媒体流传输（RTCPeerConnection）：

    • 客户端通过 getUserMedia API 捕获摄像头、麦克风数据，生成 MediaStream（媒体流）；

    • 通过 RTCPeerConnection 将媒体流编码（如 H.264、VP8 视频编码，OPUS 音频编码）后，通过 RTP（实时传输协议）发送给对方；

    • 接收方解码后，通过 <video> 或 <audio> 标签播放实时音视频。

  • 数据通道（RTCDataChannel）：

    • 除音视频外，WebRTC 支持通过 RTCDataChannel 传输任意二进制或文本数据（如聊天消息、文件、游戏控制指令）；

    • 数据通道支持可靠传输（类似 TCP，保证数据有序、不丢失）和非可靠传输（类似 UDP，低延迟但可能丢包），可按需配置。

3.3. 应用场景

WebRTC 适用于需要低延迟、点对点实时交互的场景，尤其在音视频通信领域应用广泛：

  • 实时音视频通话：如网页版视频会议（腾讯会议网页版）、在线问诊（医生与患者视频沟通）、远程面试系统等，WebRTC 可提供 100-200ms 低延迟的音视频传输。

  • 屏幕共享与远程协助：如在线教育中的老师屏幕共享、远程办公中的技术支持（协助操作对方电脑），通过 getDisplayMedia API 捕获屏幕流并实时传输。

  • 实时互动直播：如直播平台的连麦功能（主播与观众实时互动）、在线课堂的师生互动，WebRTC 可支持多人间的低延迟音视频交互。

  • 浏览器端 P2P 文件传输：如基于网页的文件共享工具，用户可直接向其他在线用户发送文件，无需通过服务器中转（速度取决于双方带宽）。

  • 实时游戏：如多人文本冒险游戏、简单实时对战游戏，通过 RTCDataChannel 传输玩家操作指令，实现低延迟同步。

  • 物联网设备实时监控：如通过网页实时查看家用摄像头画面、工业设备监控视频，WebRTC 可直接接收设备推送的音视频流。

4. 轮询：早期的实时通信方案

轮询是 Web 实时通信的"早期方案"，核心逻辑是客户端通过周期性发送 HTTP 请求，主动从服务器获取最新数据，本质是利用 HTTP 短连接模拟"实时"效果。
核心优势是兼容强劲、实现简单，核心劣势是服务器开销大、实时性有限。
随着 WebSocket 和 SSE 的普及，轮询已逐渐退出主流实时场景，但在兼容性要求极高或低成本临时需求中，仍是一种可落地的选择（这里不再详细介绍）。
实际开发中，优先选择 WebSocket/SSE，仅在必要时考虑轮询。

5. 技术对比与选型建议

WebSocket、SSE、WebRTC 和轮询是 Web 端实时通信的四大核心技术，以下从技术特性、优缺点、适用场景三个维度进行对比分析：

5.1. 技术特性对比

技术特性对比

5.2. 核心优缺点分析

5.2.1. WebSocket

  • 优点：全双工通信、低延迟、支持任意数据类型，适合高频双向交互；
  • 缺点：服务器需维护长连接（高并发场景需负载均衡），实现复杂度高于 SSE/轮询。

5.2.2. SSE

  • 优点：服务器单向推送场景下实现简单（客户端 EventSource 开箱即用），自动重连，服务器资源消耗低；
  • 缺点：仅支持单向通信，不支持二进制原生传输，IE 完全不兼容。

5.2.3. WebRTC

  • 优点：点对点通信（减少服务器带宽压力），音视频传输延迟极低，支持文件等二进制数据；
  • 缺点：实现复杂（需处理 NAT 穿透、信号协商），浏览器兼容性细节差异大，依赖 STUN/TURN 服务器。

5.2.4. 轮询

  • 优点：实现最简单，兼容性 100%（支持所有浏览器和服务器）；
  • 缺点：实时性差（短轮询延迟高，长轮询服务器压力大），带宽浪费严重。

5.3. 适用场景对比

适用场景对比

6. 一些进阶问题

6.1. 高并发与扩展性问题

当连接数达到数万甚至数十万级时，单台服务器难以承载，需解决"连接瓶颈"和"负载均衡"问题。

6.2. 数据安全与身份认证

实时通信涉及用户敏感数据（如聊天内容、音视频），需解决"身份验证"和"数据加密"问题：通过身份认证机制和数据加密传输解决。

6.3. 网络稳定性与连接可靠性

弱网环境（如 4G 切换、WiFi 信号差）会导致连接中断或数据丢失，需通过"保活机制"和"重连策略"保障可靠性：

6.3.1. 连接保活机制

  • WebSocket：实现 Ping/Pong 心跳（服务器定时发 Ping，客户端回 Pong），超时未响应则判定连接失效。
  • SSE：服务器定期发送注释帧（:\n\n）作为心跳，防止长连接被网关超时关闭。
  • WebRTC：通过 RTCPeerConnection 的 oniceconnectionstatechange 监听连接状态，状态为 failed 时触发重连。
  • 长轮询：设置合理超时时间（如 30 秒），客户端收到超时响应后立即重试，避免连接长期闲置。

6.3.2. 智能重连策略

  • 指数退避重连：重连间隔按指数增长（1s → 2s → 4s → 最大 30s），避免网络恢复时的请求风暴。
  • 网络感知重连：通过 navigator.connection.effectiveType 判断网络类型（如 2g/3g/4g），弱网环境下延长重连间隔。
  • 数据补发机制：
    • WebSocket/SSE：重连后通过 Last-Event-ID 或自定义偏移量（如消息 ID）向服务器请求遗漏数据；
    • WebRTC：关键数据（如游戏操作）启用可靠传输模式（ordered: true），确保重连后补发。

6.4. 跨域与浏览器兼容性

不同技术的跨域处理和浏览器支持存在差异，需针对性兼容：

6.4.1. 跨域通信处理

  • WebSocket：支持跨域，服务器需在握手阶段返回 Access-Control-Allow-Origin: *（或指定域名），并验证 Origin 头防止恶意请求。
  • SSE：同 WebSocket，依赖 HTTP 跨域头（Access-Control-*），且 EventSource 仅支持 GET 请求，无法携带自定义头（需通过 URL 参数传递认证信息）。（在微信小程序中有版本和平台的兼容问题，这里暂不叙述）
  • WebRTC：信令服务器需配置跨域，媒体流传输本身不涉及跨域（P2P 直连）。
  • 轮询：通过 CORS 或 JSONP（仅 GET）处理跨域，同普通 HTTP 请求。

6.4.2. 浏览器兼容性适配

  • WebSocket：IE 不支持，需用 Socket.IO 等库自动降级为长轮询（兼容 IE 8+）。
  • SSE：IE 完全不支持，可通过 fetch + 长轮询模拟 SSE 功能（如 sse.js 库）。
  • WebRTC：不同浏览器对编码格式支持不同（如 Safari 不支持 VP8），需在 SDP 协商时指定兼容编码（如 H.264）；移动端需处理摄像头权限请求差异。
  • 轮询：无兼容性问题，但需注意老旧浏览器对 fetch 的支持（可降级为 XMLHttpRequest）。

7. 参考资源