网络传输基础：UDP与TCP对比、RTP协议详解、RTCP协议详解、SRTP安全传输
做WebRTC开发，网络传输是绕不开的根基。很多初学者一上来就扎进SDP协商、ICE穿透，结果遇到丢包、延迟、花屏，完全摸不着头脑。说白了，这些问题十有八九都出在传输层。
这一章，我把WebRTC涉及的几个核心传输协议掰开揉碎讲清楚。UDP和TCP怎么选？RTP头部每个bit是干嘛的？RTCP怎么反馈网络状态？SRTP怎么保证安全？嗯，咱们一个一个来。
2.1 UDP vs TCP：为什么WebRTC选择了UDP？
先问个问题：视频通话里，你更在意“画面完整但卡5秒”，还是“画面偶尔花一下但一直流畅”？
答案很明显。WebRTC选UDP，不是因为TCP不好，而是因为TCP不适合实时通信。
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 保证送达，重传机制 | 尽力而为，不保证 |
| 有序性 | 保证数据包按序到达 | 不保证顺序 |
| 拥塞控制 | 有（窗口滑动、慢启动） | 无 |
| 头部开销 | 20-60字节 | 8字节 |
| 适用场景 | 文件传输、网页浏览 | 实时音视频、游戏 |
我在项目中遇到过好几次这样的坑：客户坚持要用TCP做视频通话，理由是“TCP更可靠”。结果呢？一旦网络出现抖动，TCP的拥塞控制就开始降速，重传堆积，延迟飙升到好几秒。画面倒是完整了，但对面的人已经聊到下一个话题了。
核心结论：WebRTC选择UDP，是因为实时通信可以容忍少量丢包，但不能容忍高延迟。丢掉的包可以通过FEC、NACK等上层机制补偿，但TCP的“保序+重传”在弱网下就是灾难。
避坑指南：我曾经在P2P穿透测试中，发现UDP包被运营商QoS限速。后来加了TURN服务器走TCP中继才解决。记住：UDP虽然好，但有些企业防火墙会直接丢弃UDP流量。这时候WebRTC会回退到TCP-over-TLS，但延迟会明显增加。
2.2 RTP协议详解：实时传输的“快递单”
RTP（Real-time Transport Protocol）是WebRTC传输音视频数据的核心协议。它不保证传输质量，只负责给每个数据包贴上“标签”——告诉接收方：这是第几帧、什么编码格式、时间戳是多少。
你可以把RTP想象成快递单。UDP是卡车，负责把包裹运过去；RTP就是贴在包裹上的面单，写着收件人、物品名称、重量等信息。
2.2.1 RTP头部结构
RTP头部固定12字节，后面可以跟扩展头。我刚开始看RFC 3550的时候，觉得这些字段很抽象。后来抓包分析了一次，就全明白了。
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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+几个关键字段，我挑重要的说：
- V（Version）：版本号，固定为2。目前没有RTPv3，别想太多。
- P（Padding）：填充位。有些加密算法要求块对齐，会在末尾补字节。接收方根据最后一个字节的值知道补了多少。
- X（Extension）：扩展头标志。WebRTC里经常用扩展头传一些元数据，比如绝对发送时间、帧标记等。
- CC（CSRC Count）：贡献源数量。混音场景下，多个音频源会列在这里。
- M（Marker）：标记位。视频里通常表示一帧的结束，音频里表示会话的开始。
- PT（Payload Type）：负载类型。告诉接收方数据是H264、VP8、Opus还是别的编码。
- Sequence Number：序列号。每发一个包加1，接收方靠它检测丢包和排序。
- Timestamp：时间戳。音频用采样率（如48000Hz），视频用90kHz时钟。接收方用它做播放同步。
- SSRC：同步源标识。每个RTP流有一个唯一的SSRC，用来区分不同的音视频流。
注意：序列号和时间戳是独立的。序列号用于丢包检测，时间戳用于播放时序。不要混淆！我曾经见过新手把序列号当时间戳用，结果音频播放速度忽快忽慢。
2.2.2 RTP扩展头
WebRTC在RTP扩展头里塞了不少东西。最常用的是RFC 5285定义的“one-byte header”格式。我简单列几个常见的扩展：
- 绝对发送时间（Absolute Send Time）：用于计算单向延迟。
- 传输序列号（Transport-wide Sequence Number）：用于带宽估计。
- 帧标记（Frame Marking）：标识关键帧、参考帧等，帮助接收方快速解码。
2.3 RTCP协议详解：让发送方知道网络状况
RTP只管发，不管收没收到。那怎么知道网络好不好？靠RTCP（RTP Control Protocol）。
RTCP周期性地在接收方和发送方之间交换统计信息。说白了，就是接收方告诉发送方：“你发的包我丢了5%，抖动有点大，建议降码率。”
2.3.1 RTCP报文类型
| 类型 | 名称 | 作用 |
|---|---|---|
| 200 | SR（Sender Report） | 发送方报告：包含发送的包数、字节数、NTP时间戳 |
| 201 | RR（Receiver Report） | 接收方报告：包含丢包率、累计丢包数、抖动、延迟 |
| 202 | SDES（Source Description） | 源描述：包含CNAME、工具名等 |
| 205 | NACK（Generic NACK） | 选择性重传请求：告诉发送方哪些包丢了 |
| 206 | FIR（Full Intra Request） | 请求关键帧：解码器崩溃时用 |
我最常用的是RR和NACK。RR里的丢包率直接驱动码率自适应算法，NACK则是WebRTC丢包重传的核心。
2.3.2 RTCP带宽控制
RTCP本身也会占用带宽。RFC 3550规定，RTCP流量不能超过会话总带宽的5%。其中，发送方报告占25%，接收方报告占75%。
嗯，这里有个细节：如果很多人同时发RTCP，会造成“RTCP风暴”。所以WebRTC里RTCP的发送间隔是动态计算的，参与者越多，间隔越长。
关键指标：接收方报告（RR）中的几个字段，是WebRTC抗丢包算法的输入：
- 丢包率（fraction lost）：最近一个周期内的丢包比例，直接触发FEC或NACK。
- 累计丢包数（cumulative lost）：从开始到现在总共丢了多少包。
- 到达间隔抖动（interarrival jitter）：反映网络稳定性，影响Jitter Buffer大小。
- LSR/DLSR：用于计算RTT（往返时间），是带宽估计的重要参数。
2.4 SRTP安全传输：给音视频数据加把锁
RTP数据是明文传输的。你想想看，如果视频通话被中间人抓包，画面和声音直接暴露，多可怕。所以WebRTC强制使用SRTP（Secure RTP）。
SRTP不是一个新的协议，而是在RTP基础上增加了加密和认证。它使用AES算法加密负载，用HMAC-SHA1保证完整性。
2.4.1 SRTP的工作流程
- 密钥协商：通过DTLS-SRTP握手，交换主密钥（Master Key）。
- 派生会话密钥：从主密钥派生出加密密钥、认证密钥、盐值（Salt）。
- 加密：对RTP负载进行AES加密（通常使用AES-CTR模式）。
- 认证：对RTP头部+负载计算HMAC，附加在包尾。
- 传输：加密后的SRTP包通过UDP发送。
个人经验：我曾经调试过一个SRTP解密失败的问题，折腾了两天。最后发现是DTLS握手时协商的密钥长度不匹配——发送方用了128位，接收方配置了256位。记住：SRTP的密钥派生算法是固定的，但密钥长度必须在握手阶段对齐。
2.4.2 SRTCP
RTCP同样需要保护，对应的就是SRTCP。它和SRTP使用相同的密钥体系，但加密算法略有不同。SRTCP的认证是强制性的——如果认证失败，整个RTCP包会被丢弃。
为什么RTCP的认证比RTP更严格？因为RTCP里包含丢包率、RTT等控制信息。如果攻击者伪造RTCP报告，可以让发送方误判网络状况，导致码率失控。
2.5 本章知识体系图
下面这张图把本章的核心协议和它们之间的关系串起来了。你可以看到UDP在最底层，RTP/RTCP在传输层之上，SRTP/SRTCP提供安全保护。
从这张图可以清楚看到：UDP在最底层提供传输能力，RTP/RTCP在UDP之上分别负责数据传输和控制反馈，SRTP/SRTCP则给它们加上安全层。每一层各司其职，缺一不可。
嗯，这一章的内容就到这里。UDP和TCP的选择、RTP的头部结构、RTCP的反馈机制、SRTP的安全保障——这些是WebRTC传输的基石。后面的章节里，我们会基于这些协议，深入讲解FEC、NACK、带宽估计等抗丢包技术。到时候你会发现，今天讲的这些细节，每一个都会用到。