4. 网络传输基础：UDP vs TCP、RTP 协议详解、RTCP 协议详解、SRTP 安全传输
做实时通信，说白了就是在跟网络的不确定性较劲。我刚开始接触 WebRTC 时，最困惑的就是：为什么非要用 UDP？TCP 不是更可靠吗？后来踩过几次坑才明白，这里面的门道可不少。
4.1 UDP vs TCP：实时通信的生死抉择
先说说我的一个惨痛教训。几年前做一款视频会议产品，初期为了"稳定"，我坚持用 TCP 传输媒体流。结果呢？一旦网络出现丢包，TCP 就开始重传，视频卡成幻灯片，音频断断续续。用户投诉电话都快被打爆了。
为什么会这样？你想想看，TCP 为了保证数据完整，丢包了就要重传。但在实时通信里，你重传一个 500ms 前的视频帧，用户早就该看下一帧了。这就是典型的"可靠但没用"。
核心结论：实时通信选 UDP，不是因为 UDP 更好，而是因为 TCP 的可靠性在实时场景下反而成了负担。
来看个对比：
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 保证送达，顺序一致 | 尽力而为，可能丢包 |
| 延迟 | 较高（重传导致） | 低（无重传机制） |
| 适用场景 | 文件传输、网页浏览 | 音视频、游戏、DNS |
我个人习惯把 UDP 比作"快递员"，TCP 则是"挂号信"。快递员可能丢件，但送得快；挂号信绝对丢不了，但慢。实时通信要的是快，丢几帧画面用户可能察觉不到，但卡顿 1 秒谁都受不了。
避坑指南：我曾经在弱网环境下测试，发现 UDP 丢包率达到 20% 时，视频还能勉强看。换成 TCP，丢包率 5% 就开始卡顿。所以别迷信 TCP 的"可靠"，在实时通信里，及时性比可靠性更重要。
4.2 RTP 协议详解：媒体数据的"快递单"
UDP 只管把数据扔出去，但扔的是什么？怎么组装？这就轮到 RTP（实时传输协议）登场了。
RTP 说白了就是给媒体数据贴了个标签。每个 RTP 包都包含：
- 序列号：用来排序，防止乱序
- 时间戳：告诉接收方这个包应该在什么时间播放
- SSRC：同步源标识，区分不同的流（比如麦克风和摄像头）
- 负载类型：告诉接收方这是 H.264 视频还是 Opus 音频
我记得有一次排查问题，发现视频花屏。抓包一看，RTP 序列号跳了 200 多，但时间戳却连续。这说明发送端在疯狂丢帧，但播放时间没调整。嗯，这就是典型的"发送端扛不住了"。
RTP 的头部结构其实很简单：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+看到没？就 12 字节的固定头部。轻量、高效，这就是 RTP 的设计哲学。
注意：RTP 本身不保证服务质量。它只负责"贴标签"，至于丢包了怎么办、延迟高了怎么办，那是上层应用和 RTCP 的事。
4.3 RTCP 协议详解：通信的"体检报告"
光有 RTP 还不够，你得知道网络状况怎么样。RTCP（实时传输控制协议）就是干这个的。
RTCP 会定期发送报告，包含：
- 丢包率：丢了几个包？占比多少？
- 往返时延：从发送到接收再回来，花了多久？
- 抖动：网络延迟的波动有多大？
- 累计丢包数：从开始到现在总共丢了多少？
我建议你把 RTCP 想象成"体检报告"。RTP 是干活的人，RTCP 是检查身体的人。没有 RTCP，你就像闭着眼睛开车，撞了才知道。
RTCP 报告有两种主要类型：
| 类型 | 发送者 | 内容 |
|---|---|---|
| SR（发送者报告） | 主动发送媒体的一方 | 发送的包数、字节数、时间戳信息 |
| RR（接收者报告） | 接收媒体的一方 | 丢包率、抖动、延迟 |
实际项目中，RTCP 的发送频率很关键。发太频繁浪费带宽，发太少又不够实时。标准建议是 RTCP 带宽占总带宽的 5%，但我在项目中习惯根据场景调整——视频会议可以降到 2%，直播可以升到 8%。
实战经验：我曾经遇到一个诡异的问题：视频偶尔卡顿，但丢包率显示为 0。后来发现是 RTCP 报告周期太长，丢包发生在报告间隔内，被平均掉了。解决方案是把 RTCP 间隔从 5 秒缩短到 1 秒，问题立刻暴露。
4.4 SRTP 安全传输：给媒体数据加把锁
说到安全，很多人觉得"我就做个视频通话，谁闲得没事来偷听？" 嗯，我以前也这么想，直到有一次在咖啡厅演示产品，被同行用 Wireshark 抓包抓了个正着……
SRTP（安全实时传输协议）就是在 RTP 基础上加了加密和认证。它使用 AES 加密算法，确保：
- 机密性：别人抓了包也看不懂
- 完整性：数据没有被篡改
- 重放保护：防止攻击者重复发送旧包
SRTP 的密钥管理通常通过 DTLS-SRTP 来完成。流程大概是：
- 双方通过 DTLS 握手协商密钥
- 协商出 SRTP 需要的加密参数
- 后续所有 RTP 包都用这个密钥加密
我建议你在 WebRTC 中默认开启 SRTP。性能开销其实很小，现代 CPU 都有 AES 硬件加速，加密解密几乎不占资源。但带来的安全性提升是巨大的。
小技巧：调试时可以用 chrome://webrtc-internals 查看 SRTP 是否启用。如果看到 cryptoSuite 字段有值，说明加密已生效。
4.5 知识体系总览
说了这么多，我画张图帮你理清思路：
从这张图可以看得很清楚：UDP 是地基，RTP 是房子，RTCP 是监控系统，SRTP 是门锁。四者缺一不可。
好了，这一章的内容就到这里。记住一句话：实时通信的本质，是在不可靠的网络上，用可靠的设计，提供可用的服务。