1. RTP协议概述：从背景到实战定位

大家好，我是你们这趟RTP之旅的向导。做了十几年流媒体，我经手过的RTP流如果连起来，大概能绕地球……嗯，反正不少。今天咱们正式开篇，聊聊RTP/RTCP协议族到底是个什么来头，它在整个流媒体世界里站在哪个位置，以及它跟RTSP、WebRTC这些“邻居”到底是什么关系。

说实话，很多新手一上来就扎进RTP的报文细节里，结果越看越懵。我个人的习惯是，先搞清楚“它为什么存在”，再看“它怎么工作”。所以这一章，咱们先把地图摊开。

1.1 RTP/RTCP协议族背景

RTP的全称是实时传输协议（Real-time Transport Protocol）。它最早是在1996年由IETF标准化，也就是RFC 1889，后来被RFC 3550取代。你想想看，90年代中期，互联网刚开始普及，大家还在用56k猫拨号上网，那时候就想在网络上打电话、看视频了。但TCP这种“可靠但慢”的协议，显然不适合实时场景——你愿意等3秒钟让画面重传，还是愿意直接看一个有点花屏但流畅的画面？

所以，RTP被设计出来的核心目的就一个：在不可靠的IP网络上，传输具有实时特征的数据。它不保证送达，不保证顺序，但它保证“时效性”。

而RTCP（RTP Control Protocol）是RTP的“孪生兄弟”，它负责提供质量反馈和会话控制。RTP负责“干活”，RTCP负责“汇报”。

我记得有一次在项目中，客户抱怨视频通话质量差，但RTP流看起来一切正常。后来我抓包一看，RTCP报文被防火墙拦截了，发送端收不到接收端的丢包反馈，自然也就没法调整码率。嗯，这里要注意：RTCP虽然只是“辅助”协议，但它在实际系统中往往决定了用户体验的生死。

1.2 RTP在流媒体协议栈中的位置

很多初学者会问：RTP跟UDP、TCP是什么关系？它跟HTTP又是什么关系？

说白了，RTP是应用层协议，但它通常跑在传输层的UDP之上。为什么选UDP而不是TCP？因为UDP没有重传机制，延迟低，适合实时场景。但UDP不可靠，所以RTP自己实现了一套“轻量级”的可靠性机制——比如序列号、时间戳、负载类型标识等。

我们来看一下典型的流媒体协议栈分层：

层级	协议/组件	作用
应用层	RTSP / SIP / WebRTC (JS API)	会话控制、信令协商
表示层	RTP / RTCP	实时数据传输、质量反馈
传输层	UDP (主要) / TCP (少数场景)	端到端传输、端口复用
网络层	IP	路由、寻址
链路层	以太网 / WiFi / 4G/5G	物理传输

你看，RTP夹在应用层和传输层之间。它不负责“建立连接”，那是RTSP或SIP的事；它也不负责“可靠传输”，那是TCP的事。RTP只做一件事：把音视频数据打包成标准格式，打上时间戳和序列号，然后扔给UDP发送出去。

我曾经遇到过一个坑：有人把RTP直接跑在TCP上，结果因为TCP的拥塞控制和重传机制，导致视频延迟飙升到好几秒。所以，除非你的网络环境极端恶劣（比如防火墙只允许TCP 80端口），否则我强烈建议用UDP。

1.3 RTP与RTSP/WebRTC的关系

这是很多人容易混淆的地方。RTP、RTSP、WebRTC，它们到底谁是谁？

我打个比方：

• RTSP 就像电视遥控器——它负责“播放”、“暂停”、“快进”、“停止”这些控制指令。它不传输视频数据本身。
• RTP 就像电视信号线——它负责把音视频数据从发送端传到接收端。
• WebRTC 则是一个“全家桶”——它包含了信令（类似RTSP的功能）、RTP传输、NAT穿透、加密等一整套方案。

具体来说：

RTP与RTSP

RTSP（Real Time Streaming Protocol）是一个控制协议，它通过C/S模式管理媒体流。典型的流程是：客户端先通过RTSP与服务器握手，协商好媒体格式和传输参数，然后RTSP告诉服务器“开始发送”，服务器就开始用RTP推流。

RTSP本身不传输数据，它只是“指挥官”。RTP才是“士兵”。

我记得在做一个IPTV项目时，RTSP的DESCRIBE响应里携带了SDP（Session Description Protocol），里面描述了RTP的负载类型、时钟频率、端口号等信息。如果SDP写错了，RTP流根本解不出来。所以，RTSP和RTP是“你中有我，我中有你”的关系。

RTP与WebRTC

WebRTC是近年来最火的实时通信框架。它内部使用的传输协议就是RTP——准确地说，是SRTP（Secure RTP），即加密版的RTP。

但WebRTC对RTP做了一些“魔改”：

• 它使用DTLS-SRTP进行密钥协商，而不是传统的SDP带外传输。
• 它引入了FEC（前向纠错）和NACK（选择性重传）来提升抗丢包能力。
• 它使用ICE（交互式连接建立）来穿越NAT和防火墙。

所以，你可以把WebRTC理解为“RTP的豪华升级版”。如果你掌握了RTP的核心机制，再去看WebRTC的源码，会发现很多概念都是相通的。

1.4 本章知识体系总览

为了让你对本章内容有个整体印象，我画了一张图。这张图展示了RTP在整个流媒体生态中的位置，以及它跟周边协议的关系。

从这张图你可以看到，RTP不是孤立存在的。它下面依赖UDP/IP，上面被RTSP或WebRTC调用，旁边还有RTCP做辅助。理解了这张图，你就知道RTP在整个体系里扮演什么角色了。

1.5 为什么你要学RTP？

可能有人会问：现在WebRTC这么火，直接用WebRTC不就行了？为什么还要学RTP？

我的回答是：RTP是流媒体的“底层语言”。就像你学编程，不能只会用框架，还得懂底层原理。WebRTC封装了RTP，但如果你不懂RTP，遇到问题你连抓包分析都无从下手。

举个例子：有一次线上视频卡顿，我用Wireshark抓了RTP包，发现时间戳出现了跳跃——发送端时钟漂移了。如果我不懂RTP的时间戳机制，我可能只会怀疑网络问题，而不会想到是发送端硬件时钟不准。

所以，学RTP不是为了“复古”，而是为了让你在遇到问题时，能像老中医一样“望闻问切”，一眼看出病根在哪。