本文作者京东物流技术团队卢旭，有修订和改动。

1、引言

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

本文分享的是 Web 端最常用即时通讯技术（包括 WebSocket、SSE、WebRTC、轮询等）的原理、优缺点与适用场景等，以及生产环境下的高并发场景下的进阶实践。

2、方案1：Http轮询

轮询是 Web 实时通信的 “早期方案”，核心逻辑是客户端通过周期性发送 HTTP 请求，主动从服务器获取最新数据，本质是利用 HTTP 短连接模拟 “实时” 效果。

核心优势是兼容性强、实现简单，核心劣势是服务器开销大、实时性有限。

随着 WebSocket 和 SSE 的普及，轮询已逐渐退出主流实时场景，但在兼容性要求极高或低成本临时需求中，仍是一种可落地的选择（这里不再详细介绍）。

实际开发中，优先选择 WebSocket/SSE，仅在必要时考虑轮询。

☞ 进一步学习：网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket

3、方案2：SSE服务器“推”技术

3.1 基本概念

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

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

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

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

关键特性：

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

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

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

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

4）事件流流程图：

3.3 典型应用场景

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

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

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

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

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

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

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

☞ 进一步学习：

4、方案3：WebRTC实时通信

4.1 基本概念

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

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

其关键特性包括：

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

4.2 技术原理

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

1）信号协商（Signaling）：发现与连接准备。

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

交换的核心信息：

a. SDP（Session Description Protocol）：描述本地媒体能力（如支持的音视频编码格式、分辨率、采样率等），分为 “offer”（发起方提议）和 “answer”（接收方应答）；
b. ICE 候选地址（ICE Candidate）：包含本地网络可被访问的 IP 地址和端口（需穿透 NAT 网络地址转换）。

流程示例：

a. 客户端 A 生成 SDP offer 并通过信号服务器发送给客户端 B；
b. 客户端 B 收到 offer 后，生成 SDP answer 并通过信号服务器返回给 A；
c. 双方分别收集自身的 ICE 候选地址（如本地局域网地址、NAT 转换后的公网地址），并通过信号服务器互相发送；
d. 双方根据收到的 SDP 和 ICE 信息，确定最优通信路径。

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

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

ICE 工作原理：

a. 首先尝试 “主机候选地址”（本地局域网 IP），若双方在同一局域网，直接建立连接；
b. 若失败，尝试 “服务器反射候选地址”（通过 STUN 服务器获取 NAT 转换后的公网地址）；
c. 若仍失败（如严格对称 NAT 环境），则通过 TURN 服务器中转数据（作为最后的 fallback 方案）。

关键服务器：

a. STUN 服务器：帮助设备获取自身的公网 IP 和端口（用于 NAT 穿透）；
b. TURN 服务器：在 P2P 连接失败时，作为中继服务器转发数据（确保通信不中断，但增加延迟）。

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

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

媒体流传输（RTCPeerConnection）：

a. 客户端通过getUserMediaAPI 捕获摄像头、麦克风数据，生成MediaStream（媒体流）；
b. 通过RTCPeerConnection将媒体流编码（如 H.264、VP8 视频编码，OPUS 音频编码）后，通过 RTP（实时传输协议）发送给对方；
c. 接收方解码后，通过< video >或< audio >标签播放实时音视频。

数据通道（RTCDataChannel）：

a. 除音视频外，WebRTC 支持通过RTCDataChannel传输任意二进制或文本数据（如聊天消息、文件、游戏控制指令）；
b. 数据通道支持可靠传输（类似 TCP，保证数据有序、不丢失）和非可靠传输（类似 UDP，低延迟但可能丢包），可按需配置。

4.3 应用场景

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

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

☞ 进一步学习：

5、方案4：WebSocket协议

5.1 基本概念

WebSocket 是 Web 端实时通信的 “基础设施”，通过全双工长连接和轻量帧传输，解决了 HTTP 单向短连接的局限性，成为即时通讯、协作工具、实时监控等场景的首选技术。

其与 HTTP 并非替代关系，而是互补 ——HTTP 适用于 “请求 - 响应” 场景（如页面加载），WebSocket 适用于 “双向实时交互” 场景。

5.2 技术原理

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

1）握手阶段：基于 HTTP 升级协议。

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

客户端发起请求：发送特殊的 HTTP GET 请求，声明协议升级意向：

GET/wsHTTP/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 头冗余，传输效率极高。

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

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 的关系：

5.3 典型应用场景

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

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

☞ 进一步学习：

6、方案对比和选型建议

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

6.1 技术特性对比

6.2 核心优缺点分析

WebSocket：

优点：全双工通信、低延迟、支持任意数据类型，适合高频双向交互；

缺点：服务器需维护长连接（高并发场景需负载均衡），实现复杂度高于 SSE / 轮询。

SSE：

优点：服务器单向推送场景下实现简单（客户端EventSource开箱即用），自动重连，服务器资源消耗低；

缺点：仅支持单向通信，不支持二进制原生传输，IE 完全不兼容。

WebRTC：

优点：点对点通信（减少服务器带宽压力），音视频传输延迟极低，支持文件等二进制数据；

缺点：实现复杂（需处理 NAT 穿透、信号协商），浏览器兼容性细节差异大，依赖 STUN/TURN 服务器。

轮询：

优点：实现最简单，兼容性 100%（支持所有浏览器和服务器）；

缺点：实时性差（短轮询延迟高，长轮询服务器压力大），带宽浪费严重。

6.3 适用场景对比

7、Web端即时通讯的进阶难题

7.1 网络稳定性与连接可靠性

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

连接保活机制：

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

智能重连策略：

1）指数退避重连：重连间隔按指数增长（1s → 2s → 4s → 最大 30s），避免网络恢复时的请求风暴
2）网络感知重连：通过navigator.connection.effectiveType判断网络类型（如 2g/3g/4g），弱网环境下延长重连间隔。

数据补发机制：

1）WebSocket/SSE：重连后通过Last-Event-ID或自定义偏移量（如消息 ID）向服务器请求遗漏数据；
2）WebRTC：关键数据（如游戏操作）启用可靠传输模式（ordered: true），确保重连后补发。

7.2 数据安全与身份认证

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

7.3 高并发与扩展性问题

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

7.4 跨域与浏览器兼容性

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

跨域通信处理：

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

浏览器兼容性适配：

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