2. WebRTC架构总览
做 WebRTC 开发，说白了就是在跟音视频数据打交道。你想想看，如果连这些数据长什么样、怎么存、怎么传都不清楚，那后面调优、排错基本就是瞎蒙。这一节我把几个最核心的概念掰开揉碎讲清楚，都是我这些年踩坑换来的经验。
采样率：声音的「像素」
先说说音频。声音在现实中是连续的波形，但计算机只能处理离散的数字。把连续信号变成离散数字的过程，就叫采样。
采样率，就是每秒钟采多少个点。单位是 Hz（赫兹）。
| 采样率 | 常见场景 | 我的评价 |
|---|---|---|
| 8,000 Hz | 传统电话 | 能听清，但声音闷 |
| 16,000 Hz | VoIP / WebRTC 默认 | 够用，清晰度还行 |
| 44,100 Hz | CD 音质 | 音乐级，WebRTC 很少用 |
| 48,000 Hz | 专业音频 / 视频录制 | 高保真，带宽扛不住 |
这里有个经典定理——奈奎斯特采样定理：采样率必须大于信号最高频率的两倍，才能完整还原。人声最高频率大概 4,000 Hz，所以 8,000 Hz 的采样率刚好够用。但为什么 WebRTC 推荐 16,000 Hz？因为留点余量，语音质量更好。
比特率：数据量的「水龙头」
比特率，也叫码率。它表示每秒钟传输或存储的比特数，单位是 bps（bit per second）。
你可以把比特率想象成水龙头。开大了，数据量大，画质/音质好；关小了，数据量小，但质量会下降。
比特率 = 采样率 × 位深度 × 通道数（未压缩时）
举个例子：16,000 Hz × 16 bit × 1 通道 = 256,000 bps ≈ 256 kbps
但实际 WebRTC 里，我们不会传裸数据。因为 256 kbps 的音频裸流，在弱网环境下根本跑不动。所以就有了编解码器。
编解码器：压缩的艺术
编解码器，就是一套压缩和解压缩的算法。它的目标很简单：用更少的比特，保留尽可能多的质量。
WebRTC 里最常用的视频编解码器有两个：H.264 和 VP8。音频方面，Opus 是绝对的主力。
H.264
- 硬件支持好。几乎所有手机、电脑的芯片都内置了 H.264 硬编解码。
- 压缩率高。同等画质下，比 VP8 省带宽。
- 但专利问题复杂。虽然 WebRTC 里免费用，商用场景要小心。
VP8
- 完全开源，无专利风险。
- 软件编码，兼容性好，但 CPU 消耗比 H.264 高。
- 同等码率下，画质略逊于 H.264。
| 特性 | H.264 | VP8 |
|---|---|---|
| 硬件加速 | 广泛支持 | 较少 |
| 压缩效率 | 高 | 中等 |
| CPU 消耗 | 低（硬编） | 高（软编） |
| 专利风险 | 有 | 无 |
| WebRTC 默认 | 是（部分浏览器） | 是（Chrome 早期） |
音频编解码器：Opus 是王者
WebRTC 音频编解码器，我几乎只用 Opus。为什么？
- 支持 6 kbps 到 510 kbps 的码率范围。
- 采样率从 8,000 Hz 到 48,000 Hz 自适应。
- 延迟极低，默认 20ms 一帧。
- 而且完全免费。
你想想看，一个编解码器能同时搞定语音和音乐，还能根据网络状况自动调整码率，这不就是为 WebRTC 量身定做的吗？
知识体系总览
下面这张图，把这一节的核心概念串起来了。建议你多看几遍，理清它们之间的关系。
实际项目中的选择建议
我个人习惯，在 WebRTC 项目里这样配：
- 音频：Opus 编解码器，采样率 16,000 Hz，比特率 32 kbps。语音通话足够清晰，带宽占用低。
- 视频：优先 H.264 硬编。如果目标平台不支持，降级到 VP8。分辨率 640×480，比特率 500 kbps 起步。
- 弱网环境：开启 Simulcast（ simulcast 是啥后面会讲），让接收端根据网络自动选流。
chrome://webrtc-internals，里面能看到实时的比特率、丢包率、编解码器信息。我排查问题第一步就是看这里。
嗯，这一节的内容就这些。采样率、比特率、编解码器，这三个概念是音视频通信的基石。你理解了它们，后面看 WebRTC 的带宽估计、码率控制、流切换这些高级话题，就会轻松很多。