1. WebRTC 推流全景：架构概览、推流链路拆解、卡顿的本质是什么？

各位好，我是你们这趟 WebRTC 卡顿排查之旅的向导。说实话，我入行头两年，最怕听到的就是用户说「画面卡住了」。那时候我 debug 全靠猜，运气好能蒙对，运气不好就通宵抓包。后来我才明白——卡顿不是玄学，是链路里某个环节的必然结果。

这一章，我们先搭好骨架。把 WebRTC 推流这件事从头到尾拆开，看看数据是怎么从摄像头一路跑到远端播放器的。只有看清了全貌，后面聊排查手段才有落脚点。

1.1 推流架构：谁在干活？

一个典型的 WebRTC 推流系统，说白了就三个角色：

• 推流端（Publisher）：采集摄像头、麦克风数据，编码后打包发送。
• 信令服务器（Signaling Server）：帮双方交换 SDP、ICE 候选，不传媒体数据。
• 媒体服务器（SFU/MCU）：接收推流，转发给拉流端。SFU 是主流，只转发不混流。
• 拉流端（Subscriber）：接收媒体流，解码渲染。

我习惯把信令服务器比作「媒人」——只负责牵线，不参与过日子。真正影响卡顿的，是推流端 → 媒体服务器 → 拉流端这条媒体管道。

1.2 推流链路拆解：一帧画面走过的路

你想想看，一帧画面从摄像头到用户屏幕，中间要经历多少道工序？我把它拆成 7 步：

1. 采集：摄像头捕获原始帧，YUV 或 RGB 格式。分辨率、帧率在这里定。
2. 预处理：降噪、美颜、分辨率缩放。这一步容易吃 CPU。
3. 编码：用 H.264/VP8/VP9 压缩成 I/P/B 帧。码率、GOP 大小在这决定。
4. 打包：编码后的数据切片成 RTP 包，加上序列号、时间戳。
5. 网络传输：RTP 包走 UDP 发往媒体服务器。丢包、抖动、带宽瓶颈都发生在这。
6. 服务器转发：SFU 收到包，按需转发给拉流端。可能涉及转码或 Simulcast 层级切换。
7. 接收端解码渲染：拉流端收包、排序、解码、送显。JitterBuffer 在这里抗抖动。

这里有一张表，总结了每步的关键指标和常见问题：

链路环节	关键指标	常见卡顿原因
采集	fps、分辨率	摄像头性能不足、分辨率过高
预处理	CPU 占用、处理耗时	美颜/滤镜算法过重
编码	编码耗时、码率波动	码率设置不合理、编码器过载
打包	RTP 包大小、时间戳间隔	MTU 分片不合理、时间戳异常
网络传输	丢包率、RTT、抖动	带宽不足、Wi-Fi 干扰、跨运营商
服务器转发	转发延迟、丢包	SFU 过载、Simulcast 切换延迟
解码渲染	解码耗时、渲染帧率	设备解码能力不足、JitterBuffer 配置不当

1.3 卡顿的本质：到底什么是「卡」？

用户说「卡」，其实包含三种完全不同的现象。我当年踩过坑，用户报卡，我查了半天网络，结果是编码器配置问题。所以先得统一语言：

• 帧率卡顿（FPS Drop）：画面像幻灯片，一帧一帧跳。本质是单位时间内渲染的帧数低于预期。原因可能是采集帧率低、编码太慢、网络丢包导致帧不完整、解码跟不上。
• 延迟卡顿（Latency Spike）：画面流畅，但延迟突然变大。比如对方张嘴 3 秒后才听到声音。本质是数据在链路某处被排队了。常见于网络拥塞、JitterBuffer 缓冲过大。
• 花屏/马赛克（Artifact）：画面出现色块、条纹。本质是视频数据丢失或损坏，解码器用错误数据重建了画面。通常由网络丢包引起，也可能是编码器 B 帧参考链断裂。

为什么会这样？我画了一张图，把卡顿的根因按链路位置归类：

1.4 一个真实案例：我踩过的「假卡顿」坑

讲个故事。去年有个客户反馈，他们的直播推流每隔几分钟就卡一次，每次持续 3-5 秒。他们怀疑是网络问题，换了 CDN、升级了带宽，问题依旧。

我远程上去一看，推流端 CPU 占用 80%，编码器是软件 x264。再细查，发现他们的摄像头采集分辨率是 4K，但推流只用了 720p。也就是说，每次采集完都要做一次 4K→720p 的缩放，这个缩放操作吃掉了大量 CPU。

解决方案很简单：把摄像头采集分辨率直接设为 720p。CPU 降到 30%，卡顿消失。

1.5 本章小结

这一章我们搭好了认知框架：

• WebRTC 推流涉及推流端、信令、媒体服务器、拉流端四个角色，卡顿主要发生在媒体管道。
• 一帧画面要经过采集→预处理→编码→打包→网络→转发→解码渲染 7 步，每一步都可能成为瓶颈。
• 卡顿的本质是帧率下降、延迟突增或数据损坏，根因可能藏在链路的任何一环。

嗯，骨架有了。后面每一章，我们会拿着这把「链路手术刀」，一刀一刀切开每个环节，看看到底是什么在作祟。