非对等WebRTC架构核心要点：采集端→SFU→浏览器

作者：lansnow
来源：好好学习自留地
链接：https://mp.weixin.qq.com/s/EoZZxXEHSmhuKPUrVlVX1A

很多监控、工业相机、IPC 网页预览项目，采用「自研采集端推流 + SFU 中转 + 浏览器拉流观看」的非对等 WebRTC 架构，并非浏览器之间 P2P 通话。 采集端是自研程序，浏览器是黑盒接收方，两边能力不对等，会踩很多普通双向通话遇不到的坑。本文梳理整套架构的关键配置、避坑点与观测指标，适合设备网页低延时预览类项目参考。

整体架构说明

链路：自研采集端 (C/C++/Go) → SFU 服务 (MediaSoup/Janus/LiveKit) → 浏览器 (原生 WebRTC API，无插件)

采集端：WebRTC 推流 Publisher，负责采集、编码、RTP 打包、向上推流；

SFU：只做 RTP 包转发，默认不转码，一路输入可分发给多个浏览器；

浏览器：仅作为 Subscriber 拉流播放，不发送视频。

重要建议：内网设备不要直连浏览器做 P2P，NAT 穿透成功率低，优先使用 SFU 中转。

一、核心痛点：采集端与浏览器能力不对称

采集端代码完全可控，但浏览器 WebRTC 是黑盒，编码、SDP 解析、解码能力受浏览器版本约束。

编码协商SDP 协商逻辑：浏览器告知采集端自身支持的解码器，采集端必须在浏览器支持列表内选择编码。

Chrome/Edge：支持 H.264、VP8、VP9、部分支持 AV1

Safari：优先 H.264，VP8/VP9 兼容性差

最佳实践：选用 H.264 Constrained High，关闭 B 帧，SDP 正确填写profile‑level‑id、声明 no‑bframe，避免花屏、延迟飙升。不要默认使用 VP9，Safari 坑较多。

RTP 时间戳采集端自主生成 RTP 时间戳，浏览器依靠它做抖动缓冲、音视频同步。时间戳需要按采样时钟平稳递增，禁止随意跳跃，否则会出现冻屏、jitterbuffer 剧烈抖动；纯视频无音频场景：要么只下发 video 轨道；如需音频，使用静音虚拟音频，部分浏览器对空音频轨道会异常。

二、自研采集端：决定延迟与稳定性的主战场

低延迟、弱网表现大部分由采集端决定，浏览器只能做辅助。

1. 编码器配置

关闭 B 帧、lookahead=0，消除编码预读延迟，同时规避浏览器解码兼容问题；优先硬件编码 (NVENC/V4L2)，降低嵌入式 CPU 消耗；IDR 关键帧间隔建议 1‑2 秒。间隔过长，丢包后画面长时间无法恢复；间隔过短码率暴涨；网络丢包发生时，主动输出 IDR 关键帧，帮助浏览器快速恢复画面。

2. RTP 打包与 MTU 分片

WebRTC UDP MTU 约 1200 字节H.264 必须做 FU‑A 分片，保证每个 RTP 包不超限，大包不分片会直接丢包；分片逻辑放在采集端，不要交给 SFU；尽量只用标准 RTP 扩展头，务必开启 transport‑cc，这是带宽估计的基础。

3. 带宽估计 BWE

非对等架构：浏览器接收端计算带宽，通过transport‑cc RTCP 反馈回采集端。

很多自研实现只做 RTP 发送，忽略 transport‑cc，带宽自适应完全失效，网络变差直接疯狂丢包花屏。

采集端要解析 transport‑cc 反馈，动态调整输出码率；REMB 作为向下兼容备选，现代浏览器优先 transport‑cc。

4. NACK 与 FEC 策略（单向观看场景）

业务只有浏览器观看，没有上行视频，策略和双向通话不一样：追求最低延迟：关闭 NACK 重传，开启 ULPFEC 前向纠错，弱网靠冗余恢复，避免重传带来额外时延；网络条件好优先画质：开启 NACK + 少量 FEC。

5. RTCP 发送

定时发送 SR 发送报告，浏览器依靠 SR 做媒体时间同步；长时间不发送 SR，浏览器会判定流已死亡，主动断开。

6. 采集端稳定性

监控设备、PeerConnection、编码状态；摄像头拔插等异常要做处理；网络短时抖动优先发送 IDR 恢复画面，不要直接销毁重建连接，避免频繁 ICE 握手；7×24 小时运行的设备，必须做内存泄漏监控。

三、SFU 中间层注意事项

尽量透传原始 RTP 包、transport‑cc 扩展头，不能吞掉 RTCP 报文，否则带宽估计失效；

SFU 做流复制，采集端仅上传一路流，减轻边缘设备带宽压力；

防火墙开放 UDP 端口，采集端向外主动连接 SFU；

可选 Simulcast 多码流，浏览器按需订阅档位，代价是采集端 CPU 会升高。

四、浏览器端：只能 hint，不能强制控制

浏览器 jitterbuffer、BWE、丢包恢复都是内置黑盒逻辑，JS 只能给提示，无法底层修改。

jitterBufferDelayHint：JS 设置期望缓冲时长，只是提示，网络抖动大浏览器会自动抬高缓冲，不要指望靠这个实现强制低延迟，真正降延迟核心在采集端。

渲染优化：video 标签使用playsinline，MediaStream 直接绑定 video 硬件渲染；尽量避开额外 canvas 二次绘制，会增加延迟。

事件监听：监听iceconnectionstatechange、track 状态，实现指数退避自动重连，避免短时间疯狂重连压垮服务。

Safari 特殊兼容：WebRTC 限制多，长会话容易内存泄漏、异常断流，需要单独做兼容性测试。

监控：通过getStats读取关键指标：jitterBufferDelay、接收帧率、丢弃帧、RTT、丢包率，用来观测真实播放质量。

五、ICE/STUN/TURN 部署建议

采集端（内网设备）主动向外连接 SFU，这条链路一般不需要 TURN；

浏览器到 SFU：需要 STUN 做 NAT 探测；

企业内网环境准备 TURN 做兜底；

不推荐采集端和浏览器 P2P 直连，内网设备穿透成功率低。

六、无音频场景处理（监控 / 工业相机高频）

很多设备只有视频流，没有真实音频;

现代浏览器：直接只推送 video 轨道即可；

老旧浏览器兼容：生成静音 Opus 虚拟音频轨道，维持媒体时钟，会消耗少量带宽。

七、观测核心指标

采集端

编码耗时、RTP 发送队列长度（队列堆积 = 延迟上涨信号）、IDR 触发次数、实际发送码率。

SFU

入包丢包率、转发延迟。

浏览器 (getStats)

jitterBufferDelay、解码帧率、丢弃帧、RTT、丢包数量。

端到端真实时延，可通过 RTP 扩展头携带采集端时间戳，浏览器读取计算。

八、避坑清单

✅ 推荐做法

采集端输出无 B 帧 H.264，启用 transport‑cc；

使用 SFU 中转，一路推流多路分发；采集端做好 RTP FU‑A 分片，合理设置 IDR 间隔；

浏览器直接 video 硬件渲染，减少 JS 图像处理；

浏览器通过 getStats 做质量监控上报。❌ 禁止 / 尽量避免内网采集设备直接 P2P 对接浏览器；

编码器开启 B 帧、大 lookahead；

忽略 transport‑cc，带宽估计完全失效；

RTP 包不做分片，超过 MTU；

浏览器过度依赖jitterBufferDelayHint，不做弱网兜底；

7×24 小时运行的采集端，缺少内存泄漏检测。

扩展：Simulcast 多码流，采集端输出多档码流，浏览器自适应订阅，适合网络波动大的场景，代价是 CPU 开销上升。