在 Web 开发中，实时通信技术的核心目标是实现客户端（Browser）与服务器之间低延迟、双向 / 单向的动态数据交互，而非传统 HTTP 的 “请求 - 响应” 模式。以下是 Web 端最常用的实时通信技术，从概念、原理特点、适用场景、对比选型进行详细解析。
一、WebSocket
1.1、核心概念
WebSocket 是 Web 端实时通信的 “基础设施”，通过 全双工长连接和 轻量帧传输，解决了 HTTP 单向短连接的局限性，成为即时通讯、协作工具、实时监控等场景的首选技术。其与 HTTP 并非替代关系，而是互补 ——HTTP 适用于 “请求 - 响应” 场景（如页面加载），WebSocket 适用于 “双向实时交互” 场景。
1.2、原理介绍
WebSocket 的工作流程分为 握手协议升级、 数据帧传输和 连接管理三个阶段：
1. 握手阶段：基于 HTTP 升级协议
WebSocket 连接的建立依赖 HTTP 协议完成 “握手”，本质是将 HTTP 连接升级为 WebSocket 连接；
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 计算而来（验证身份）
2. 数据传输：基于帧结构的高效通信
WebSocket 采用 二进制帧（Frame）格式传输数据，帧结构仅包含 “操作码（Opcode）、掩码、数据长度、数据载荷” 等核心字段（头部仅 2-14 字节），无 HTTP 头冗余，传输效率极高：
0x01文本数据、
0x02二进制数据、
0x08断开连接）；3. 连接管理：保活与断开
Ping帧，客户端必须回传
Pong帧；若超时未收到
Pong，判定连接失效并主动断开。；Opcode=0x08的关闭帧，双方确认后关闭 TCP 连接。4.为什么在握手阶段需要升级协议
WebSocket 并非完全脱离 HTTP，而是借助 HTTP 协议的 “握手流程” 完成 “协议切换”—— 通过一次 HTTP 请求，让客户端和服务端达成共识：“接下来我们用 WebSocket 协议通信，不再遵循 HTTP 规则”。
4.1.这个升级过程的核心价值是：
4.2、WebSocket 和 HTTP 的关系
1.3、应用场景
WebSocket 适用于 需要低延迟、双向实时通信的场景，典型案例包括：
二、Server-Sent Events（SSE）
2.1、核心概念
SSE（Server-Sent Events，服务器发送事件）是一种基于 HTTP 协议的 服务器向客户端单向实时推送数据的技术，专为 “服务器主动向客户端持续发送更新” 场景设计，是 Web 端实时通信的重要方案之一。
SSE 的核心是建立一个 持久化的 HTTP 长连接，让服务器可以随时向客户端推送数据，而无需客户端频繁发起请求。它是一种 “服务器到客户端” 的单向通信模式，与 WebSocket 的双向通信形成互补。
其优势在于原生支持自动重连、API 简单（
EventSource接口）、服务器实现成本低，适合无需客户端回传数据的场景。与 WebSocket 相比，SSE 更专注于单向推送，实现和维护成本更低，是实时通知、日志展示等场景的理想选择。
2.2、原理介绍
SSE 的工作流程基于 HTTP 长连接和特殊的文本流协议，主要分为 连接建立、 数据推送和 重连机制三个阶段：
1. 连接建立：基于 HTTP 的长连接初始化
客户端通过浏览器原生的
EventSourceAPI 发起连接请求，服务器返回符合 SSE 规范的响应头，建立持久化连接：
// 客户端创建 SSE 连接（仅支持 GET 方法）const sse = newEventSource('/service/stream');
浏览器会自动发送 HTTP 请求，携带特殊头信息（如
Accept: text/event-stream）。
HTTP/1.1200OK 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. 数据推送：基于规范的文本流格式
服务器通过 HTTP 长连接持续向客户端发送 “事件”，每个事件需遵循严格的文本格式，以
\n\n作为结束符：
# 格式 1：默认事件（客户端通过 onmessage 接收） data: 您有一条新消息\n data: 内容：Hello World\n\n # 多行 data 会合并为一条消息 # 格式 2：自定义事件名（客户端通过 addEventListener 接收） event: orderStatus # 事件名（如“订单状态更新”） id: 10086 # 事件 ID（用于重连时定位断点） data: 订单已发货\n\n # 格式 3：心跳保活（客户端忽略，仅维持连接） : 这是注释，无实际数据，防止长连接超时\n\n
3. 重连机制：自动恢复连接与数据补发
SSE 原生支持断线重连，无需手动实现：
Last-Event-ID: 1000000（最后接收的事件 ID），服务器可基于此补发断点后的所有数据，避免数据丢失。
4. 事件流流程图
2.3、 应用场景
SSE 适用于 服务器需主动向客户端单向推送数据的场景，典型案例包括：
三、WebRTC
3.1、核心概念
WebRTC（Web Real-Time Communication，网页实时通信）是一项 浏览器原生支持的实时通信技术标准，允许浏览器之间直接建立点对点（P2P）连接，实现音视频通话、数据传输等实时交互，无需依赖第三方插件或额外软件。
WebRTC 的核心目标是打破传统实时通信对中间服务器的强依赖，让浏览器之间能够 直接传输数据（音视频、文本、文件等），其关键特性包括：
getUserMedia捕获音视频、
RTCPeerConnection建立连接）；3.2、原理介绍
WebRTC 的工作流程可分为 信号协商、 P2P 连接建立和 媒体流传输三个核心阶段，其中 “信号协商” 需借助服务器，而实际数据传输则在客户端之间直接进行。
1. 信号协商（Signaling）：发现与连接准备
浏览器（客户端）无法直接知道对方的网络位置（IP 地址、端口），需通过 “信号服务器” 交换连接所需的元数据（如网络信息、媒体能力）：
2. P2P 连接建立：穿透 NAT 与防火墙
由于多数设备处于 NAT（网络地址转换）或防火墙后，直接建立 P2P 连接需解决 “地址可达性” 问题，WebRTC 通过 ICE（Interactive Connectivity Establishment）协议实现：
3. 媒体流传输：实时音视频与数据交互
连接建立后，WebRTC 通过两套核心 API 实现数据传输：
getUserMediaAPI 捕获摄像头、麦克风数据，生成
MediaStream（媒体流）；RTCPeerConnection将媒体流编码（如 H.264、VP8 视频编码，OPUS 音频编码）后，通过 RTP（实时传输协议）发送给对方；<video>或
<audio>标签播放实时音视频。RTCDataChannel传输任意二进制或文本数据（如聊天消息、文件、游戏控制指令）；3.3、应用场景
WebRTC 适用于 需要低延迟、点对点实时交互的场景，尤其在音视频通信领域应用广泛：
getDisplayMediaAPI 捕获屏幕流并实时传输。RTCDataChannel传输玩家操作指令，实现低延迟同步。
四、轮询
轮询是 Web 实时通信的 “早期方案”，核心逻辑是 客户端通过周期性发送 HTTP 请求，主动从服务器获取最新数据，本质是利用 HTTP 短连接模拟 “实时” 效果。核心优势是兼容性强、实现简单，核心劣势是服务器开销大、实时性有限。随着 WebSocket 和 SSE 的普及，轮询已逐渐退出主流实时场景，但在兼容性要求极高或低成本临时需求中，仍是一种可落地的选择（这里不再详细介绍）。实际开发中，优先选择 WebSocket/SSE，仅在必要时考虑轮询。
五、技术对比与选型建议
WebSocket、SSE、WebRTC 和轮询是 Web 端实时通信的四大核心技术，以下从技术特性、优缺点、适用场景三个维度进行对比分析：
5.1、技术特性对比
| 对比维度 | WebSocket | SSE（Server-Sent Events） | WebRTC | 轮询（短 / 长） |
| 通信方向 | 全双工（客户端↔服务器双向） | 单向（服务器→客户端） | 全双工（客户端↔客户端 P2P） | 伪双向（客户端请求→服务器响应） |
| 连接类型 | 基于 TCP 的长连接（HTTP 升级） | 基于 HTTP 的长连接 | 基于 UDP/TCP 的 P2P 长连接 | 短连接（短轮询）/ 挂起长连接（长轮询） |
| 延迟 | 极低（毫秒级，无 HTTP 头冗余） | 低（数据产生即推送，HTTP 头开销小） | 极低（100-200ms，音视频优化） | 高（短轮询取决于间隔）/ 中（长轮询） |
| 数据类型 | 文本、二进制（支持任意数据） | 文本（二进制需编码为 Base64） | 音视频流、文本、二进制（文件等） | 文本、二进制（需自定义格式） |
| 服务器依赖 | 高（需维护长连接，支持高并发） | 中（单连接推送，资源消耗低） | 低（仅信号协商需服务器，数据直连） | 高（短轮询请求密集，长轮询挂起连接） |
| 自动重连 | 需手动实现（配合心跳机制） | 原生支持（断线后自动重试） | 需手动实现（复杂网络环境下重连逻辑） | 需手动实现（定时器重试） |
| 兼容性 | 主流浏览器支持（IE 不支持） | 主流浏览器支持（IE 不支持） | 主流浏览器支持（需 HTTPS 环境） | 所有浏览器（基于 HTTP） |
| 典型协议 / API |
ws:///
wss://、
new WebSocket() |
EventSourceAPI |
RTCPeerConnection、
getUserMedia |
fetch/
XMLHttpRequest+ 定时器 |
5.2、核心优缺点分析
EventSource开箱即用），自动重连，服务器资源消耗低；5.3、适用场景对比
| 场景类型 | 首选技术 | 次选技术 | 不推荐技术 |
| 即时聊天 | WebSocket | 长轮询（兼容） | 短轮询、SSE |
| AI智能助手（流式输出） | SSE | WebSocket | 轮询 |
| 音视频通话 / 屏幕共享 | WebRTC | - | 其他技术（延迟高） |
| 实时协作工具（如腾讯文档） | WebSocket | - | 轮询、SSE |
| 股票 / 行情实时更新 | WebSocket/SSE | 长轮询 | 短轮询 |
| 在线游戏（实时交互） | WebSocket | WebRTC（P2P 游戏） | 轮询 |
| 日志 / 监控数据实时展示 实时通知（如订单更新） | SSE | WebSocket | 短轮询 |
| 兼容性要求极高（如 IE8） | 长轮询 | 短轮询 | 其他技术（不兼容） |
六、一些进阶问题
6.1、高并发与扩展性问题
当连接数达到数万甚至数十万级时，单台服务器难以承载，需解决 “连接瓶颈” 和 “负载均衡” 问题。
6.2、数据安全与身份认证
实时通信涉及用户敏感数据（如聊天内容、音视频），需解决 “身份验证” 和 “数据加密” 问题：通过身份认证机制和数据加密传输解决。
6.3、网络稳定性与连接可靠性
弱网环境（如 4G 切换、WiFi 信号差）会导致连接中断或数据丢失，需通过 “保活机制” 和 “重连策略” 保障可靠性：
Ping，客户端回
Pong），超时未响应则判定连接失效：:\n\n）作为心跳，防止长连接被网关超时关闭。RTCPeerConnection的
oniceconnectionstatechange监听连接状态，状态为
failed时触发重连。navigator.connection.effectiveType判断网络类型（如 2g/3g/4g），弱网环境下延长重连间隔。Last-Event-ID或自定义偏移量（如消息 ID）向服务器请求遗漏数据；ordered: true），确保重连后补发。6.4、跨域与浏览器兼容性
不同技术的跨域处理和浏览器支持存在差异，需针对性兼容：
Access-Control-Allow-Origin: *（或指定域名），并验证
Origin头防止恶意请求。Access-Control-*），且
EventSource仅支持 GET 请求，无法携带自定义头（需通过 URL 参数传递认证信息）。（在微信小程序中有版本和平台的兼容问题，这里暂不叙述）Socket.IO等库自动降级为长轮询（兼容 IE 8+）。fetch+ 长轮询模拟 SSE 功能（如
sse.js库）。fetch的支持（可降级为
XMLHttpRequest）七、其它
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70037994/viewspace-3098795/ ，如需转载，请注明出处，否则将追究法律责任。
