1. 流媒体基础：RTSP协议原理、RTP/RTCP协议、流媒体传输模型、H.264编码基础

各位同学好，我是老张。在流媒体这行摸爬滚打了十几年，踩过的坑比走过的路还多。今天咱们开始《RTSP流媒体服务器搭建》的第一章，先把地基打牢。

很多人一上来就急着搭服务器，结果遇到花屏、卡顿、延迟高，完全不知道从哪下手。说白了，就是基础没吃透。这一章我会把RTSP、RTP/RTCP、传输模型和H.264编码这些核心概念串起来讲，结合我实际项目中的经验，帮你建立完整的知识框架。

1.1 RTSP协议原理——流媒体的遥控器

RTSP（Real Time Streaming Protocol），全称实时流协议。你可以把它想象成一个遥控器。它不负责传输视频数据本身，而是负责控制——比如播放、暂停、快进、后退。

我记得刚入行时，有个同事非说RTSP能传视频数据，结果抓包看了半天，发现RTSP报文里全是文本命令，真正的视频流在RTP里。嗯，这个误会很多人都有。

RTSP基于文本，使用类似HTTP的请求-响应模型。但它是有状态的——服务器需要记住客户端当前处于哪个阶段。

RTSP方法	功能	我在项目中遇到的坑
DESCRIBE	获取媒体描述信息（SDP）	有些摄像头返回的SDP格式不规范，解析时容易崩溃
SETUP	建立传输通道，协商端口	端口冲突是最常见的问题，尤其是UDP模式
PLAY	开始播放	Range头没处理好，会导致从头播放而非续播
PAUSE	暂停播放	某些老旧设备不支持PAUSE，直接断开连接
TEARDOWN	终止会话	忘记发TEARDOWN会导致服务器资源泄漏

RTSP的典型交互流程是这样的：

1. 客户端发送 OPTIONS 请求，询问服务器支持哪些方法
2. 服务器回复支持的方法列表
3. 客户端发送 DESCRIBE 请求，获取SDP描述
4. 服务器返回SDP，包含媒体类型、编码格式、传输参数
5. 客户端发送 SETUP 请求，指定传输模式（UDP/TCP）和端口
6. 服务器确认并分配资源
7. 客户端发送 PLAY 请求，开始接收数据
8. 播放过程中可发送 PAUSE 暂停
9. 结束播放时发送 TEARDOWN 释放资源

1.2 RTP/RTCP协议——真正的数据搬运工

RTSP只是指挥，真正干活的是RTP（Real-time Transport Protocol）和RTCP（RTP Control Protocol）。

RTP负责传数据。它把视频帧切成一个个包，加上时间戳、序列号、负载类型等头部信息。接收端根据这些信息重组帧、排序、同步播放。

RTCP负责反馈。它周期性地发送控制报文，包含丢包率、延迟抖动、接收带宽等统计信息。发送端可以根据这些信息调整码率或重传丢失的包。

我曾经在一个安防项目中，摄像头画面每隔几秒就卡一下。抓包分析发现RTP序列号有大量跳变——丢包严重。但RTCP报文显示接收端带宽充足，问题出在Wi-Fi信号干扰。后来换了有线，问题解决。你看，没有RTCP的反馈，你根本不知道问题在哪。

特性	RTP	RTCP
主要功能	传输实时数据	传输控制信息
传输方向	单向（发送端→接收端）	双向
报文频率	持续发送	周期性（通常每5秒一次）
端口号	偶数端口	奇数端口（RTP端口+1）
可靠性	不可靠（UDP）	不可靠（UDP）

1.3 流媒体传输模型——数据怎么从A到B

流媒体传输模型，说白了就是数据从摄像头到播放器之间怎么走。主要有三种模式：

• 单播（Unicast）：一对一传输。每个客户端独立建立连接，服务器需要为每个客户端发送一份数据。适合点播场景，但客户端多了服务器扛不住。
• 组播（Multicast）：一对多传输。服务器只发一份数据，网络设备复制给多个客户端。适合直播场景，节省带宽。但需要网络设备支持IGMP，公网基本用不了。
• 分发（Distribution）：服务器集群。边缘服务器从源站拉流，再分发给客户端。适合大规模直播，比如我参与过的春晚直播项目，用了三级分发架构。

你想想看，如果1000个客户端同时看一个直播，用单播的话服务器要发1000份同样的数据，带宽直接爆炸。用组播的话，服务器只发一份，网络自己复制。但组播在公网基本不可行——运营商不支持。所以实际项目中，分发模型用得最多。

1.4 H.264编码基础——视频是怎么压缩的

原始视频数据量巨大。一帧1080p的RGB图像，分辨率1920×1080，每个像素3字节，一帧就是6MB。30帧/秒的话，每秒180MB。这谁受得了？所以必须压缩。

H.264是目前最主流的视频编码标准。它通过消除冗余来压缩数据：

• 空间冗余：同一帧内相邻像素相似。用帧内预测（I帧）消除。
• 时间冗余：相邻帧之间内容相似。用帧间预测（P帧、B帧）消除。
• 视觉冗余：人眼对某些细节不敏感。用量化去掉不重要的信息。

H.264定义了三种主要帧类型：

帧类型	全称	特点	大小
I帧	关键帧	完整编码，不依赖其他帧	最大
P帧	前向预测帧	参考前面的I帧或P帧	中等
B帧	双向预测帧	参考前后帧，压缩率最高	最小

我建议你记住一个关键概念：GOP（Group of Pictures）。GOP是一组连续的帧，以I帧开头，后面跟着若干P帧和B帧。GOP长度决定了视频的压缩率和随机访问能力。

• GOP越短，压缩率越低，但随机访问越快（快进、跳转时等待时间短）
• GOP越长，压缩率越高，但随机访问越慢

在实际项目中，直播场景我一般用2秒的GOP（60帧左右），点播场景可以用4-5秒。为什么？直播需要快速切换频道，GOP太长的话，切换时得等下一个I帧，用户体验很差。

1.5 协议栈协作关系——它们怎么配合

好了，现在我们把所有东西串起来。一个完整的RTSP流媒体会话，协议栈是这样工作的：

1. 控制层（RTSP）：客户端和服务器通过RTSP协商要播放什么、怎么传。RTSP报文走TCP，保证可靠性。
2. 传输层（RTP/RTCP）：协商完成后，RTP开始传视频数据，RTCP周期性地反馈质量信息。RTP/RTCP默认走UDP，追求低延迟。
3. 编码层（H.264）：摄像头采集原始视频，用H.264编码成NAL单元。RTP把这些NAL单元打包成RTP包，加上时间戳和序列号。
4. 网络层（IP）：所有数据最终封装成IP包，在网络上传输。

你想想看，如果没有RTSP，客户端不知道服务器支持什么格式、不知道用哪个端口。如果没有RTP，数据没法按时序重组。如果没有RTCP，发送端不知道网络状况。如果没有H.264，原始视频数据量大到根本传不动。这四个东西缺一不可。