都HTML5了，Web端即时通讯技术到底该用什么？一文即懂！

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

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 向所有协作者推送当前编辑者的操作状态。
  

☞ 进一步学习：

• Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
• SSE技术详解：一种全新的HTML5服务器推送事件技术
• 使用WebSocket和SSE技术实现Web端消息推送
• 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
• 使用WebSocket和SSE技术实现Web端消息推送
• 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
• 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、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 可直接接收设备推送的音视频流。
  

☞ 进一步学习：

• 访谈WebRTC标准之父：WebRTC的过去、现在和未来
• WebRTC实时音视频技术的整体架构介绍
• 新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？
• WebRTC实时音视频技术基础：基本架构和协议栈
• 实时音视频入门学习：开源工程WebRTC的技术原理和使用浅析
• 零基础快速入门WebRTC：基本概念、关键技术、与WebSocket的区别等
  

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 可支撑高并发推送。
  

☞ 进一步学习：

• 新手快速入门：WebSocket简明教程
• WebSocket从入门到精通，半小时就够！
• 初步认识WebSocket技术
• 刨根问底HTTP与WebSocket的关系(上篇)
• 刨根问底WebSocket与Socket的关系
  

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）
  

8、参考资料  （js修订时加一下参考资料！嗯嗯，编辑修订时再搞不迟！）

[1] 零基础IM开发入门(二)：什么是IM聊天系统的实时性？
[2] P2P技术详解(一)：NAT详解——详细原理、P2P简介
[3] 新手入门贴：史上最全Web端即时通讯技术原理详解
[4] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
[5] SSE技术详解：一种全新的HTML5服务器推送事件技术
[6] Comet技术详解：基于HTTP长连接的Web端实时通信技术
[7] 使用WebSocket和SSE技术实现Web端消息推送
[8] 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
[9] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？
[10] WebSocket从入门到精通，半小时就够！
[11] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
[12] 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE
[13] 全民AI时代，大模型客户端和服务端的实时通信到底用什么协议？
[14] ChatGPT如何实现聊天一样的实时交互？快速读懂SSE实时“推”技术
[15] AI大模型爆火的SSE技术到底是什么？万字长文，一篇读懂SSE！
[16] 详解AI大模型实时通信为什么选SSE，而不是WebSocket和WebRTC