在 Web 开发中，实时通信技术的核心目标是实现客户端（Browser）与服务器之间低延迟、双向 / 单向的动态数据交互，而非传统 HTTP 的 “请求 - 响应” 模式。以下是 Web 端最常用的实时通信技术，从概念、原理特点、适用场景、对比选型进行详细解析。

一、WebSocket

1.1、核心概念

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

1.2、原理介绍

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

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 协议。

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

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

• 操作码：区分数据类型（0x01文本数据、0x02二进制数据、0x08断开连接）；
• 掩码：客户端发送数据必须加掩码（防止代理缓存污染），服务器返回数据无需加掩码；
• 优势：支持文本、图片、视频流等任意数据类型，双向通信延迟可低至毫秒级。

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

• 心跳保活：为避免 TCP 连接因 “长时间无数据” 被网络设备（如路由器）断开，WebSocket 内置Ping/Pong 心跳机制：服务器定期发送Ping帧，客户端必须回传Pong帧；若超时未收到Pong，判定连接失效并主动断开。；
• 主动断开：任何一方发送Opcode=0x08的关闭帧，双方确认后关闭 TCP 连接。

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

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

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

• 兼容现有网络环境：所有浏览器、网关、代理服务器都支持 HTTP；如果 WebSocket 设计成完全独立的协议，可能被现有网络设备拦截（无法穿透代理 / 防火墙）。
• 低成本建立 “长连接共识”：利用 HTTP 握手的 “请求 - 响应” 流程，让双方快速确认 “支持 WebSocket”，避免额外的协议协商开销。

4.2、WebSocket 和 HTTP 的关系

1.3、应用场景

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

• 即时通讯工具：如网页版微信、企业微信、在线客服系统等，需实时收发消息，WebSocket 可保证消息更实时。
• 实时协作工具：如腾讯文档、飞书文档等，多人同时编辑时，需实时同步光标位置、内容修改，WebSocket 可确保协作流畅。
• 金融行情更新：股票、期货等实时行情数据（每秒多次更新），通过 WebSocket 推送，比轮询更高效。
• 在线游戏：网页小游戏（如贪吃蛇联机版）需要实时同步玩家操作和游戏状态，WebSocket 可满足低延迟需求。
• 实时监控系统：如物联网设备监控（温度、湿度实时数据）、服务器性能监控，需持续接收设备 / 服务器推送的状态数据。
• 弹幕系统：视频网站的实时弹幕， thousands 级用户同时发送和接收弹幕，WebSocket 可支撑高并发推送。

二、Server-Sent Events（SSE）

2.1、核心概念

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

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

其优势在于原生支持自动重连、API 简单（EventSource接口）、服务器实现成本低，适合无需客户端回传数据的场景。与 WebSocket 相比，SSE 更专注于单向推送，实现和维护成本更低，是实时通知、日志展示等场景的理想选择。

• 关键特性：
• 单向通信：仅支持服务器向客户端推送数据，客户端无法通过 SSE 向服务器发送数据（需配合 HTTP 或 WebSocket 实现双向交互）；
• 长连接：一次连接建立后持续保持，避免短连接的反复握手开销；
• 自动重连：连接意外断开时，客户端会自动重试连接（默认间隔 3 秒）；
• 文本流：数据以 UTF-8 文本流格式传输，二进制数据需编码后发送。

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 原生支持断线重连，无需手动实现：

• 自动重连：若连接意外断开（如网络波动），客户端会在 3 秒后自动重试，并逐渐增加间隔（最多 30 秒）；
• 数据补发：重连时，客户端会在请求头中携带Last-Event-ID: 1000000（最后接收的事件 ID），服务器可基于此补发断点后的所有数据，避免数据丢失。

4. 事件流流程图

2.3、应用场景

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

• AI智能助手：SSE 支持 AI 助手的流式输出，以 “打字机” 效果逐字逐句呈现给用户，提升用户体验，增强用户与 AI 助手的交互感 。
• 实时通知系统：社交应用的消息提醒（“收到新评论”），服务器可通过 SSE 实时推送通知，无需客户端频繁轮询。
• 日志 / 状态实时展示：如后端任务执行日志（部署进度、测试报告）、CI/CD 流水线状态，服务器可实时推送日志片段，客户端实时展示（类似终端输出）。
• 新闻 / 资讯推送：如实时新闻客户端、股票资讯，服务器在有新内容（突发新闻、股价变动）时，通过 SSE 立即推送给订阅用户。
• 监控数据展示：如服务器 CPU 使用率、网络流量等监控指标，每秒 / 每分钟推送一次更新，客户端实时绘制监控曲线。
• 多人协作中的状态同步：如在线文档的 “他人正在编辑” 状态提示，服务器可通过 SSE 向所有协作者推送当前编辑者的操作状态。

三、WebRTC

3.1、核心概念

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

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

• 点对点通信：数据主要在客户端之间直接传输（仅信号协商需服务器参与），减少延迟和服务器带宽压力；
• 原生浏览器支持：无需安装插件，通过 JavaScript API 即可调用（如getUserMedia捕获音视频、RTCPeerConnection建立连接）；
• 实时性强：基于 UDP 协议传输（部分场景降级为 TCP），延迟可低至 100-200 毫秒，满足实时交互需求；
• 安全性内置：所有数据强制加密传输（通过 SRTP 协议），防止窃听和篡改。

3.2、原理介绍

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

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 信息，确定最优通信路径。

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

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

• ICE 工作原理：
• 首先尝试 “主机候选地址”（本地局域网 IP），若双方在同一局域网，直接建立连接；
• 若失败，尝试 “服务器反射候选地址”（通过 STUN 服务器获取 NAT 转换后的公网地址）；
• 若仍失败（如严格对称 NAT 环境），则通过 TURN 服务器中转数据（作为最后的 fallback 方案）。
• 关键服务器：
• STUN 服务器：帮助设备获取自身的公网 IP 和端口（用于 NAT 穿透）；
• TURN 服务器：在 P2P 连接失败时，作为中继服务器转发数据（确保通信不中断，但增加延迟）。

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

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

• 媒体流传输（RTCPeerConnection）：
• 客户端通过getUserMediaAPI 捕获摄像头、麦克风数据，生成MediaStream（媒体流）；
• 通过RTCPeerConnection将媒体流编码（如 H.264、VP8 视频编码，OPUS 音频编码）后，通过 RTP（实时传输协议）发送给对方；
• 接收方解码后，通过<video>或<audio>标签播放实时音视频。
• 数据通道（RTCDataChannel）：
• 除音视频外，WebRTC 支持通过RTCDataChannel传输任意二进制或文本数据（如聊天消息、文件、游戏控制指令）；
• 数据通道支持可靠传输（类似 TCP，保证数据有序、不丢失）和非可靠传输（类似 UDP，低延迟但可能丢包），可按需配置。

3.3、应用场景

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

• 实时音视频通话：如网页版视频会议（腾讯会议网页版）、在线问诊（医生与患者视频沟通）、远程面试系统等，WebRTC 可提供 100-200ms 低延迟的音视频传输。
• 屏幕共享与远程协助：如在线教育中的老师屏幕共享、远程办公中的技术支持（协助操作对方电脑），通过getDisplayMediaAPI 捕获屏幕流并实时传输。
• 实时互动直播：如直播平台的连麦功能（主播与观众实时互动）、在线课堂的师生互动，WebRTC 可支持多人间的低延迟音视频交互。
• 浏览器端 P2P 文件传输：如基于网页的文件共享工具，用户可直接向其他在线用户发送文件，无需通过服务器中转（速度取决于双方带宽）。
• 实时游戏：如多人文本冒险游戏、简单实时对战游戏，通过RTCDataChannel传输玩家操作指令，实现低延迟同步。
• 物联网设备实时监控：如通过网页实时查看家用摄像头画面、工业设备监控视频，WebRTC 可直接接收设备推送的音视频流。

四、轮询

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

五、技术对比与选型建议

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

5.1、技术特性对比

5.2、核心优缺点分析

• 2.1. WebSocket
• 优点：全双工通信、低延迟、支持任意数据类型，适合高频双向交互；
• 缺点：服务器需维护长连接（高并发场景需负载均衡），实现复杂度高于 SSE / 轮询。
• 2.2. SSE
• 优点：服务器单向推送场景下实现简单（客户端EventSource开箱即用），自动重连，服务器资源消耗低；
• 缺点：仅支持单向通信，不支持二进制原生传输，IE 完全不兼容。
• 2.3. WebRTC
• 优点：点对点通信（减少服务器带宽压力），音视频传输延迟极低，支持文件等二进制数据；
• 缺点：实现复杂（需处理 NAT 穿透、信号协商），浏览器兼容性细节差异大，依赖 STUN/TURN 服务器。
• 2.4. 轮询
• 优点：实现最简单，兼容性 100%（支持所有浏览器和服务器）；
• 缺点：实时性差（短轮询延迟高，长轮询服务器压力大），带宽浪费严重。

5.3、适用场景对比

六、一些进阶问题

6.1、高并发与扩展性问题

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

6.2、数据安全与身份认证

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

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

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

• 连接保活机制
• WebSocket：实现 Ping/Pong 心跳（服务器定时发Ping，客户端回Pong），超时未响应则判定连接失效：
• SSE：服务器定期发送注释帧（:\n\n）作为心跳，防止长连接被网关超时关闭。
• WebRTC：通过RTCPeerConnection的oniceconnectionstatechange监听连接状态，状态为failed时触发重连。
• 长轮询：设置合理超时时间（如 30 秒），客户端收到超时响应后立即重试，避免连接长期闲置。
• 智能重连策略
• 指数退避重连：重连间隔按指数增长（1s → 2s → 4s → 最大 30s），避免网络恢复时的请求风暴
• 网络感知重连：通过navigator.connection.effectiveType判断网络类型（如 2g/3g/4g），弱网环境下延长重连间隔。
• 数据补发机制：
• WebSocket/SSE：重连后通过Last-Event-ID或自定义偏移量（如消息 ID）向服务器请求遗漏数据；
• WebRTC：关键数据（如游戏操作）启用可靠传输模式（ordered: true），确保重连后补发。

6.4、跨域与浏览器兼容性

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

• 跨域通信处理
• WebSocket：支持跨域，服务器需在握手阶段返回Access-Control-Allow-Origin: *（或指定域名），并验证Origin头防止恶意请求。
• SSE：同 WebSocket，依赖 HTTP 跨域头（Access-Control-*），且EventSource仅支持 GET 请求，无法携带自定义头（需通过 URL 参数传递认证信息）。（在微信小程序中有版本和平台的兼容问题，这里暂不叙述）
• WebRTC：信令服务器需配置跨域，媒体流传输本身不涉及跨域（P2P 直连）。
• 轮询：通过 CORS 或 JSONP（仅 GET）处理跨域，同普通 HTTP 请求。
• 浏览器兼容性适配
• WebSocket：IE 不支持，需用Socket.IO等库自动降级为长轮询（兼容 IE 8+）。
• SSE：IE 完全不支持，可通过fetch+ 长轮询模拟 SSE 功能（如sse.js库）。
• WebRTC：不同浏览器对编码格式支持不同（如 Safari 不支持 VP8），需在 SDP 协商时指定兼容编码（如 H.264）；移动端需处理摄像头权限请求差异。
• 轮询：无兼容性问题，但需注意老旧浏览器对fetch的支持（可降级为XMLHttpRequest）

七、其它

• WebSocket：https://www.w3.org/TR/websockets/，介绍了 WebSocket API 的相关内容。
• SSE：https://developer.mozilla.org/en-US/docs/Web/API/EventSource，对 SSE 的使用方法和相关 API 进行了详细说明。
• WebRTC：https://www.w3.org/TR/webrtc/，定义了一组 ECMAScript API，允许媒体和通用应用数据在浏览器或设备之间进行实时发送和接收。