一句话定义：实时传输协议（Real-time Transport Protocol，RTP）是给音视频数据包贴上「序号」和「播放时刻」的标准信封，它跑在 UDP 上，追求的是*准时*，而不是*一个不丢*。
打个比方：RTP 像一队贴了编号和「建议送达时间」的快递。快递员（UDP）不保证送到，但只要送到了，收件人凭编号就知道有没有缺件、凭时间就知道该现在播还是稍等半秒。
为什么不用 TCP
TCP 保证不丢、不乱、不重复，代价是「丢了就必须等重传」。这在实时场景里很致命，因为 TCP 有队头阻塞（head-of-line blocking）：第 100 号包丢了，101、102 就得在缓冲区里排队，等重传到齐才一起交给播放器。网络一抖，画面先卡住再「快进追帧」，通话里就是明显的断续感。
现实是：200 毫秒前那句话没听清，比这句话干脆消失更难受。此外 TCP 遇到丢包会主动压低发送速率，网络越差越卡。语音通话的端到端延迟预算通常只有几百毫秒，等不起。
所以实时音视频的选择是：网络层用 UDP 尽力而为地送，RTP 在应用层自己补上序号和时间戳，把「绝对可靠」降级成「来得及就补，来不及就用近似值糊过去」。
丢包靠什么补
常见手段按代价从低到高：
- 抖动缓冲 + 丢包隐藏（Packet Loss Concealment，PLC）：接收端先用缓冲区吸收网络抖动，真的缺包时，用前后帧推断出一个近似波形顶上去。听感上是「糊了一下」，而不是「断了一下」。
- 前向纠错（Forward Error Correction，FEC）：发送端多发一点冗余包，丢一个还能算回来，代价是占带宽。不少语音编码器（如 Opus）也内建了带内 FEC。
- 重传：靠 RTCP 反馈告诉对方「第 100 号没收到」（NACK），如果剩余时间还够，就补发一次。视频里关键帧丢了，还可以请求一个关键帧（PLI/FIR）。
- 自适应：同时降低码率、降分辨率、切更抗丢包的编码参数。
序号和时间戳各管什么
| 字段 | 管什么 | 典型用途 |
|---|---|---|
| 序号（Sequence Number） | 「顺序」与「完整性」 | 检测丢包、乱序重排、统计丢包率 |
| 时间戳（Timestamp） | 「什么时候播」 | 按采样率标记媒体时刻、去抖动、音视频同步 |
| SSRC | 「谁发的、哪一路」 | 区分同一会议中的多路流 |
一句话记住：序号管「有没有丢、该怎么排」，时间戳管「该在几点几分播」。序号是相对的、每包加一；时间戳跟采样时钟走，同一帧拆成多个包时时间戳是相同的，这样接收端才知道它们属于同一时刻。
与 RTP 搭档的是 RTCP（RTP Control Protocol），它不运媒体，只回传丢包率、往返时延和同步信息，让发送端知道该不该降码率。
对从业者的意义
实时语音对话、数字人、直播连麦、远程会议——只要涉及「边说边听」，底下几乎都是 RTP 这一套。做 AI 语音应用时，你遇到的「机器人反应慢半拍」「声音断续」，往往不是模型慢，而是抖动缓冲配得太大、丢包没兜住、或者忘了看 RTCP 的时延反馈。具体参数与实现细节，各家框架不同，以官方文档为准。