2. 实时通信基础
实时音视频通信与普通文件下载、网页浏览有着本质区别。文件下载可以容忍几秒甚至几分钟的延迟，只要最终数据完整即可；而一通语音或视频通话，如果延迟超过 400ms，双方就会明显感到"抢话"；如果抖动超过 50ms，声音就会断续、画面就会卡顿。因此，理解实时通信的核心需求，是掌握 RTP/RTCP 协同机制的前提。
一、实时音视频传输的四大核心需求
实时音视频传输的核心诉求可以归纳为四个维度，它们彼此制约，构成了编解码与流控协同设计的出发点：
- 低延迟（Latency）：端到端延迟通常要求控制在 150ms 以内（ITU-T G.114 建议），超过 400ms 通话体验急剧下降。延迟来源包括采集、编码、网络传输、抖动缓冲、解码和渲染。
- 低抖动（Jitter）：网络到达间隔的波动必须被接收端抖动缓冲吸收，否则播放会出现断续。抖动缓冲越大越平滑，但延迟越高，二者需要权衡。
- 容忍丢包（Loss Tolerance）：实时流不能像 TCP 那样重传等待，丢包必须通过 FEC、NACK、PLC（丢包隐藏）等机制在有限时间内补偿。
- 带宽自适应（Adaptive Bitrate）：网络带宽动态变化时，编码码率、分辨率、帧率需要实时调整，避免拥塞崩溃或画质浪费。
二、RTP/RTCP 在协议栈中的位置
RTP（Real-time Transport Protocol，RFC 3550）负责承载实时媒体数据，RTCP（RTP Control Protocol）负责传输控制信息（如丢包率、抖动、往返时延、接收报告）。二者通常成对使用，RTP 走偶数端口，RTCP 走相邻的奇数端口。
在协议栈中，RTP 位于应用层与传输层之间，它本身不负责可靠传输，而是依赖下层 UDP 提供多路复用与校验，同时借助 RTCP 反馈实现闭环控制。下图展示了 RTP/RTCP 与 UDP、TCP、SRTP 以及应用层编解码器之间的层次关系：
三、RTP 与 UDP、TCP、SRTP 的关系
RTP 本身不绑定传输层协议，但实践中几乎总是运行在 UDP 之上。原因在于 TCP 的重传与拥塞控制会引入不可预测的延迟，且 TCP 的队头阻塞（Head-of-Line Blocking）会导致一个丢包阻塞后续所有数据，这对实时流是致命的。UDP 虽然不保证可靠，但提供了低开销、低延迟的传输基础，把可靠性补偿交给上层（RTP/RTCP + FEC/NACK）按需处理。
SRTP（Secure RTP，RFC 3711）是在 RTP 之上增加的安全层，提供加密、消息认证和防重放保护。它不改变 RTP 的实时语义，只是对载荷和头部进行加密与完整性校验。WebRTC 强制使用 SRTP，密钥通过 DTLS 握手协商（DTLS-SRTP）。
| 协议 | 层次 | 可靠性 | 典型用途 | 与 RTP 的关系 |
|---|---|---|---|---|
| UDP | 传输层 | 不可靠、无连接 | 实时媒体承载 | RTP 的首选下层 |
| TCP | 传输层 | 可靠、有序 | 信令、穿透、文件 | 一般不承载 RTP，仅作备选 |
| RTP | 应用层（媒体） | 不保证可靠 | 音视频数据封装 | 核心媒体通道 |
| RTCP | 应用层（控制） | 不保证可靠 | QoS 反馈与同步 | 与 RTP 成对使用 |
| SRTP | 安全层 | 加密+认证 | WebRTC、VoIP 加密 | 包裹 RTP/RTCP |
四、典型应用场景与端口约定
RTP/RTCP 广泛应用于 VoIP、视频会议、直播、WebRTC、IPTV 等领域。不同场景对延迟、丢包、带宽的敏感度不同，但都依赖 RTP 的序列号与时间戳实现乱序重排和播放同步，依赖 RTCP 的接收报告实现闭环流控。
# 典型 RTP/RTCP 端口分配（RFC 3550 建议）
# RTP 使用偶数端口，RTCP 使用相邻奇数端口
m=audio 49170 RTP/AVP 0 # RTP 端口 49170
m=video 49172 RTP/AVP 96 # RTP 端口 49172
# 对应 RTCP 端口：49171、49173
# WebRTC 中 SRTP 的典型 SDP 片段
m=audio 9 UDP/TLS/RTP/SAVPF 111
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 nack
a=rtcp-fb:111 transport-cc