跳到主要内容

WebRTC定位与边界

判断一个需求该不该用 WebRTC，先回答一句话：**端到端延迟需要小于 500ms 吗？需要双向吗？**两个都是 yes，再考虑 WebRTC，否则有更便宜的选项。

1. WebRTC 在做什么​

WebRTC 提供三件事，缺一不构成 WebRTC：

  1. 媒体采集：从摄像头、麦克风、屏幕拿到原始流。
  2. 直接传输：在两个客户端之间建立加密的实时通道，绕开服务器或只走中继。
  3. 能力协商：让两端就编解码、分辨率、扩展头达成一致。

这三件事共同决定了它的延迟下界（理论上几十毫秒）和复杂度上界（要 NAT 穿透、要 SDP、要 DTLS）。

2. 与相邻技术的硬指标对比​

维度WebRTCLL-HLSHLS / DASHRTMPWebSocket
端到端延迟100~500ms1~3s6~30s1~5s取决于业务
方向全双工单向单向单向（推）全双工
媒体能力音视频 + 数据音视频音视频音视频仅数据
NAT 穿透内置 ICE不需要不需要不需要不需要
浏览器原生是是（有限）是否（已废）是
加密强制 DTLS-SRTPHTTPSHTTPSRTMPS 可选wss 可选
大规模分发SFU 级联，万级CDN 分发，百万级CDN 分发，百万级推流端应用层路由

结论：

  • 直播看比赛、看演唱会 → HLS / LL-HLS。
  • 主播推流到平台 → RTMP（推流）+ HLS（分发）。
  • 视频会议、连麦、互动直播 → WebRTC。
  • 远程协助、屏幕共享、实时控制 → WebRTC（DataChannel 控制 + 媒体）。
  • 业务消息、状态同步 → WebSocket，不要用 DataChannel。

3. 什么时候用 WebRTC​

适用：

  • 1v1 / 小型多人音视频通话。
  • 互动直播（连麦、PK、PIA）。
  • 屏幕共享、远程协助、远程桌面、云游戏（亚秒级延迟）。
  • 浏览器原生的低延迟数据通道（P2P 文件传输、实时多人协作的状态广播）。
  • WHIP / WHEP 标准化的低延迟直播推/拉流。

4. 什么时候不用 WebRTC​

  • 百万级单向直播：用 HLS/DASH + CDN，WebRTC 的 SFU 级联成本远高于 CDN。
  • 跨地域 IM / 业务消息：WebSocket 更稳，DataChannel 没有服务端持久化、没有离线消息。
  • 后端到后端的实时数据：用 gRPC streaming、Kafka，不需要 ICE/DTLS 这套包袱。
  • 小程序为主的场景：原生小程序不直接支持 WebRTC API，要走腾讯 TRTC、声网、即构等厂商 SDK。详见 07-平台与跨端。

5. 选型决策树​

6. 与 SIP/VoIP 的关系​

历史上 VoIP 走 SIP+RTP，企业 PBX、运营商电话都是这套。WebRTC 选了复用 RTP 协议但抛弃了 SIP 信令：

  • RTP / RTCP 仍是 WebRTC 媒体层的基础。
  • SDP 仍用，但语义被 JSEP 重新定义。
  • 信令完全交给业务（WebSocket、Socket.IO、MQTT 都行）。

如果业务要和传统电话互通，需要 SIP 网关（FreeSWITCH、Kamailio、Asterisk），不是 WebRTC 自己能解决的。

7. 失败模式​

选错的表现真实根因应该选什么
大规模直播平台用 SFU 扛万人WebRTC SFU 单实例上限低HLS/LL-HLS 主分发，WebRTC 只给连麦
用 DataChannel 替代 WebSocket没考虑断线重连、离线消息WebSocket / MQTT
用 WebRTC 做后端推流协议复杂、运维重RTMP / WHIP（推）+ HLS（分发）
用 P2P Mesh 扛 10 人会议上行带宽 N-1 倍爆炸SFU

8. 权威资料​