1. WebRTC低延迟传输概述：实时通信的挑战、架构与丢包重传要求
各位同学，咱们今天开篇聊点实在的。WebRTC 这玩意儿，说白了就是让浏览器和嵌入式设备能“面对面”说话，而且延迟要低到感觉不到。我最早接触它是在一个远程视频项目里，当时觉得这技术真神奇，后来深入内核才发现，坑也不少。
1.1 实时通信的核心挑战
实时通信，尤其是低延迟场景，面临的挑战很直接。你想想看，数据从 A 点传到 B 点，中间要经过编码、网络传输、解码、渲染。任何一个环节卡顿，用户都能感知到。
我总结下来，主要有三大拦路虎：
- 网络抖动（Jitter）：数据包到达时间不一致。有时候 10ms 到，有时候 200ms 到。接收端得有个缓冲区来平滑它，但缓冲区大了延迟就上去了。
- 丢包（Packet Loss）：这是最头疼的。网络拥塞、Wi-Fi 干扰、信号衰减，都会导致包丢了。丢一个关键帧，画面可能就花了。
- 带宽波动：网络带宽不是恒定的。上一秒 10Mbps，下一秒可能掉到 500Kbps。编码器得动态调整码率，不然就会卡顿。
核心矛盾：低延迟要求缓冲区小，但缓冲区小了，抗抖动和丢包的能力就弱。这是一个典型的“既要马儿跑，又要马儿不吃草”的难题。
我记得有一次调试一个远程驾驶项目，车辆在高速移动，网络环境极差。丢包率一度飙到 15%，画面直接卡成 PPT。那时候我就意识到，光靠 WebRTC 默认的 NACK（否定确认）重传机制根本不够用，必须得做定制优化。
1.2 WebRTC 架构简介
WebRTC 的架构，我习惯把它拆成三层来看：
- 信令层（Signaling）：负责建立连接。交换 SDP（会话描述协议）和 ICE（交互式连接建立）候选者。WebRTC 标准没规定信令协议，你可以用 SIP、XMPP，甚至自己写个 WebSocket。
- 传输层（Transport）：核心是 SRTP/SCTP 和 ICE。SRTP 加密媒体流，SCTP 用于数据通道。ICE 负责打洞，让两个设备能直接通信。
- 媒体引擎（Media Engine）：包括编码器（VP8/VP9/H264）、抖动缓冲区、丢包重传模块（NACK/FEC）。
咱们这门课重点关注的，就是传输层和媒体引擎里的丢包重传部分。尤其是嵌入式场景下，资源受限，不能像 PC 端那样随便开大缓冲区。
下面这张图，是我自己画的一个简化架构，方便你理解数据流：
个人经验：在嵌入式设备上，我建议把抖动缓冲区大小做成动态可调的。比如在远程驾驶场景，网络好的时候缓冲区可以缩到 20ms，网络差的时候自动扩大到 80ms。这个阈值调优，后面章节我会详细讲。
1.3 低延迟场景对丢包重传的要求
不同的低延迟场景，对丢包重传的要求天差地别。我挑两个典型的来说：
1.3.1 远程驾驶
远程驾驶对延迟极其敏感。想象一下，你坐在控制室里，通过摄像头画面操控几百公里外的车辆。从你打方向盘到车辆响应，端到端延迟超过 200ms，驾驶体验就会非常糟糕，甚至危险。
具体要求如下：
| 指标 | 要求 | 说明 |
|---|---|---|
| 端到端延迟 | < 100ms | 从摄像头采集到显示器渲染 |
| 丢包率容忍 | < 1% | 超过 1% 画面会出现明显马赛克 |
| 重传超时 | < 30ms | 超过这个时间，重传的包就没意义了 |
| FEC 冗余 | 10% - 20% | 前向纠错，减少重传依赖 |
我曾经参与过一个远程矿卡项目。矿区网络环境恶劣，丢包率经常到 5%。我们当时做了两件事：一是把 NACK 重传的 RTT 阈值从默认的 50ms 降到 20ms；二是启用了 VP8 的 SVC（可伸缩视频编码），这样即使丢包，也能保证基础层流畅。
避坑指南：千万不要在远程驾驶场景里用纯 FEC（前向纠错）。FEC 会增加带宽消耗，而且冗余包本身也会丢。我见过一个团队，FEC 冗余开到 50%，结果网络一拥塞，丢包反而更严重了。正确的做法是 FEC + NACK 混合使用，动态调整。
1.3.2 工业控制
工业控制场景，比如机器人远程操控、PLC 数据采集，对丢包重传的要求更苛刻。因为控制指令一旦丢失，可能导致设备误动作。
工业控制的核心要求：
- 确定性延迟：延迟必须稳定，不能忽高忽低。抖动超过 10ms 就可能影响控制精度。
- 零丢包：控制指令必须可靠到达。丢一个包，机械臂可能就偏了。
- 快速重传：重传必须在 10ms 内完成。超过这个时间，控制周期就错过了。
我建议在工业控制场景里，使用 WebRTC 的 Data Channel（数据通道）来传输控制指令，而不是走媒体流。Data Channel 基于 SCTP，支持可靠传输和部分可靠传输。你可以配置成“重传 3 次，超时 10ms 就放弃”，这样既保证了可靠性，又不会无限等待。
关键对比：远程驾驶更关注画面流畅度，可以容忍少量丢包（通过 FEC 修复）；工业控制更关注指令可靠性，必须零丢包，但可以接受稍高的延迟（比如 50ms）。
嗯，这一章的内容就到这里。咱们把 WebRTC 低延迟传输的挑战、架构和场景要求理清楚了。后面几章，我会带大家深入 WebRTC 的 NACK 和 FEC 源码，看看它们到底是怎么工作的，以及怎么在嵌入式平台上做优化。