一、什么是 RTSP​协议

1.1 RTSP 协议简介​

RTSP，全称实时流传输协议（Real Time Streaming Protocol），是一种位于应用层的网络协议。它主要用于在流媒体系统中控制实时数据（如音频、视频等）的传输，并不直接负责媒体数据的传输，而是像一个 “遥控器”，通过发送一系列指令（如播放、暂停、快进、后退等）来对媒体流的传输过程进行管理和控制。​

1.2 RTSP传输基本原理

我们所说的RTSP传输并不是只依靠RTSP协议，还要依赖RTP、RTCP、SDP协议共同实现媒体数据流的传输和控制。

1.2.1 RTSP​

• 作用：RTSP 主要负责对实时媒体流的传输进行控制，协调客户端和服务器之间的交互。它可以建立和终止媒体会话，以及对媒体流的播放状态进行控制。​

• 传输方式：RTSP 本身通常使用 TCP 进行传输。这是因为 RTSP 的控制指令需要可靠的传输，确保指令能够准确无误地到达对方，避免因指令丢失或错误而导致的控制混乱。​

1.2.2 RTP

• 作用：RTP（Real-time Transport Protocol，实时传输协议）主要负责实时媒体数据（如音频、视频）的实际传输，RTP包是音视频数据的载体。它能够为实时数据提供时间戳、序列号等信息，帮助接收端正确地重组和播放媒体数据。​
• 传输方式：RTP 通常基于 UDP 进行传输。由于 UDP 具有传输速度快、延迟低的特点，能够很好地满足实时媒体数据对实时性的要求。虽然 UDP 不保证数据传输的可靠性，可能会出现数据包丢失的情况，但对于音频、视频等实时数据来说，少量的数据包丢失对播放效果的影响相对较小，而实时性更为重要。

1.2.3 RTCP

• 作用：RTCP（Real-time Transport Control Protocol，实时传输控制协议）与 RTP 配合使用，主要用于监控 RTP 数据传输的质量。它可以收集和反馈诸如数据包丢失率、延迟抖动、网络拥塞等信息，以便发送端和接收端根据这些信息调整传输策略，从而保证媒体流的传输质量。​
• 传输方式：RTCP 一般也基于 UDP 进行传输，并且通常与 RTP 共享同一个端口对（RTCP使用对应的RTP端口号+1的端口，例如某一视频流RTP端口号31590，该视频流RTCP端口号31591），以便更好地与 RTP 协同工作，及时获取和反馈传输质量信息。​

（注意！！！ 音频和视频流的rtp与rtcp分开发送，假设一场直播中有一个音频流和一个视频流，那么音频RTP发送端口A，音频RTCP发送端口A+1,视频RTP发送端口B，视频RTCP发送端口B+1， A != B）

1.2.4 SDP​

• 作用：SDP（Session Description Protocol，会话描述协议）用于描述媒体会话的相关信息，如媒体类型（音频、视频）、编码格式、传输地址、端口号等。它为通信双方提供了协商媒体会话参数的基础，让接收端能够了解如何正确接收和解析媒体数据。​

• 传输方式：SDP 本身并不负责数据的传输，它通常作为其他协议（ RTSP）消息的一部分进行传输。例如，在 RTSP 的会话建立过程中，服务器会通过 RTSP 消息将包含 SDP 信息的数据发送给客户端，客户端根据 SDP 信息来准备接收和播放媒体流。​

1.3 TCP、UDP 传输区别​

1. 连接方式：TCP 是面向连接的协议，在数据传输之前需要通过三次握手建立连接，数据传输完成后需要通过四次挥手释放连接；而 UDP 是无连接的协议，通信双方在传输数据之前不需要建立连接，可以直接发送数据。​
2. 可靠性：TCP 具有可靠传输的特点，它通过序列号、确认应答、重传机制等确保数据能够准确、完整地到达接收端，并且数据传输的顺序与发送顺序一致；UDP 不提供可靠性保障，它不保证数据的到达，也不保证数据传输的顺序，可能会出现数据包丢失、重复或乱序的情况。​
3. 传输速度：由于 TCP 需要进行连接建立、确认应答、重传等操作，会增加额外的开销，因此传输速度相对较慢；UDP 不需要这些额外的操作，开销较小，传输速度更快，实时性更好。​
4. 适用场景：TCP 适用于对可靠性要求较高的场景，如文件传输、电子邮件、网页浏览等，这些场景中数据的准确性和完整性至关重要；UDP 适用于对实时性要求较高的场景，如音频、视频传输、实时游戏、视频会议等，这些场景中少量的数据丢失对整体效果影响不大，但对传输延迟有较高的要求。

下面对RTP,RTCP,RTSP,SDP分开详解

二、RTP 协议

2.1 RTP 报文头部

RTP 报文的核心设计目标是让实时媒体数据在网络中跑得又快又准。它的结构分为 固定头部（12 字节） 和 媒体数据负载，固定头部字段包括：

 除此之外还有贡献信源(CSRC)标识符（长度可变，所以不属于固定头部）：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP 报⽂有效载荷中的所有贡献信源。

对于Timestamp，SSRC和CSRC，这里详细解释一下：

时间戳（Timestamp）：
想象你在录制一段视频：

• 每按下一次快门（采样），时间戳就增加一个固定值。比如 30fps 的视频，每帧增加3000（90kHz 时钟下的单位），就像每过 33.3ms 给帧打个标记；
• 接收端根据这些标记，就能知道帧该按什么顺序播放，以及如何与音频同步（比如说话的声音和嘴型同时出现）。

 同步源（SSRC）
假设一场多人直播：

• 主播的摄像头（SSRC_A）和嘉宾的摄像头（SSRC_B）是两个独立的视频流；
• 即使它们通过同一个网络传输，接收端也能通过 SSRC_A 和 SSRC_B 把画面分开显示；
• SSRC 是随机生成的，如果两个设备不巧生成了相同的 SSRC，就像两个人进了同一间房，需要重新分配（冲突概率极低）。

贡献源（CSRC）
想象一个在线合唱比赛：

• 每个歌手的麦克风都是独立的 SSRC（SSRC1、SSRC2、SSRC3）；
• 混音器把他们的声音合并成一个流（新的 SSRC_M），并在 CSRC 列表中记录原始的 SSRC1、SSRC2、SSRC3；
• 听众收到这个合并流时，通过查看CSRC就能知道每个声音来自谁。

RTP 之所以要设计这些头部字段就是为了：

• 序列号解决顺序问题（包是否丢失或乱序）；
• 时间戳解决时间问题（媒体数据何时该播放）；
• SSRC解决来源问题（数据是谁发的）；
• CSRC解决混音问题（合并后的数据来自哪里）。

这种设计让 RTP 在 UDP 上实现了低延迟、高可控性的实时传输，即使网络不稳定，也能通过 RTCP 反馈（见下文）动态调整，确保音视频流畅。

2.2 RTP 报文有效载荷

2.2.1 H264裸码流封包解包

（一）H.264 码流的基本结构：NALU

H.264 视频流的核心单元是NALU（Network Abstraction Layer Unit），它像快递包裹一样包含视频数据和元信息。每个 NALU 由两部分组成（不考虑startcode）：

1. NALU 头（1 字节）：
   • F（1 位）：错误标志，通常为 0（正常传输）；
   • NRI（2 位）：重要性等级（00 = 可丢弃，11 = 最高优先级），比如 I 帧的 NRI 通常为 11；
   • Type（5 位）：标识 NALU 类型（如5=IDR帧，7=SPS参数集）。
2. NALU 负载：实际的视频数据（如 I 帧像素、P 帧残差等）。

关于NALU详细可以参考：万字长文详解 H.264 编码原理与 NALU 格式:走进视频压缩世界_h264-CSDN博客

关键问题：

• 一个 NALU 可能非常大（如 1080P 的 I 帧可达 200KB），而 UDP 包最大负载约 1500 字节（MTU限制），必须分片传输；
• 多个小 NALU（如 SPS、PPS、SEI）可以合并成一个 RTP 包，减少传输开销。

（二）RTP 封包策略

RTP 封装 H.264 的核心是将 NALU 适配到网络传输单元，主要有三种模式：

1. 单一 NALU 模式（Single NALU Packet）

• 适用场景：NALU 大小 ≤ 1400 字节（如 P 帧、B 帧、SPS/PPS）。
• 封包结构：

  RTP头（12字节） + NALU头（1字节） + NALU负载  
  

   
  • 示例：SPS（25 字节）直接封装为一个 RTP 包，RTP 头的PT取H.264 负载类型。
• 优势：简单高效，接收端无需重组；
• 局限：无法处理大 NALU（如 I 帧）。

2. 组合包模式（Aggregation Packet）

将多个小 NALU 合并到一个 RTP 包中，分为两种类型：

• STAP-A（单时间聚合包）：
  • 适用场景：同一时间生成的多个小 NALU（如 SPS+PPS+SEI）。
  • 封包结构：

    RTP头 + STAP-A头（1字节） + [NALU长度（2字节） + NALU头 + NALU负载] × N  
    

     
    • STAP-A 头：Type=24，保留 F 和 NRI 与第一个 NALU 一致。
  • 示例：WebRTC 中常将 SPS 和 PPS 封装在一个 STAP-A 包中，减少首帧延迟（WebRTC实际数据流传输也是RTP包）。
• MTAP（多时间聚合包）：
  • 适用场景：不同时间生成的 NALU（如跨帧的 SEI）。
  • 复杂点：需记录每个 NALU 的时间戳偏移（如 MTAP16 用 16 位存储偏移量）。

3. 分片模式（Fragmentation Unit）

将大 NALU 拆分为多个 RTP 包，核心是FU-A 分片单元：

• 适用场景：NALU > 1400 字节（如 1080P 的 I 帧）。
• 封包结构：

  RTP头 + FU指示符（1字节） + FU头（1字节） + NALU分片负载  
  

   
  • FU 指示符：
    • 前 3 位保留 F 和 NRI，与原始 NALU 头一致；
    • Type=28（FU-A 类型）。
  • FU 头：
    • S（1 位）：分片开始标志（仅第一个包为 1）；
    • E（1 位）：分片结束标志（仅最后一个包为 1）；
    • R（1 位）：保留位（0）；
    • Type（5 位）：原始 NALU 的 Type（如5=IDR帧）。
• 分片示例：
  • 一个 200KB 的 IDR 帧被拆分为 145 个 RTP 包，第一个包S=1,E=0，最后一个包S=0,E=1。

这里对FU指示符和FU头展开解释一下：

FU指示符（FU indication）

+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI|   Type  |
+---------------+

+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R|  Type   |
+---------------+

 RTCP（Real-time Transport Control Protocol，实时传输控制协议）是 RTP 的 “孪生兄弟”——RTP 负责 “送货”（传输媒体数据），RTCP 则负责 “监控物流”（反馈质量、同步时钟、管理会话）。RTCP与RTP联合⼯作，RTP实施实际数据的传输，RTCP则负责将控制包送⾄参与中的每个⼈。其主要功能是就RTP正在提供的服务质量做出反馈。

要注意的是，RTCP 不直接描述单个 RTP 包，它描述的是整个发送方或接收方的状态以及一段时间内的统计信息。关联性通过 SSRC 和 时间窗口 来实现。

(一）RTCP 的核心功能

RTCP 的设计目标是为 RTP 传输提供 “双向沟通机制”，核心功能可概括为四类：

1. 质量反馈：接收端通过 RTCP 向发送端报告丢包率、延迟抖动等数据，发送端据此调整码率或重传策略（比如视频会议中卡顿后自动降低清晰度）。
2. 时钟同步：通过 NTP（网络时间协议）时间戳将不同媒体流（如音频、视频）对齐到同一时间轴，解决 “唇音不同步” 问题。
3. 会话管理：标识参与者身份（如用户名、设备 ID），并处理加入 / 离开会话的通知（比如直播中观众退出时发送信号）。
4. 扩展能力：支持自定义消息（如传输额外的元数据），为特殊场景（如 VR 直播的姿态数据）预留扩展空间。

传输特性：RTCP 与 RTP 共用 UDP 端口对，RTCP 端口固定为 “RTP 端口 + 1”（如 RTP 用 5004，则 RTCP 用 5005）。

(二) RTCP 报文类型

RTCP 通过 5 种报文类型实现上述功能，每种报文都有统一的头部格式和专属的 payload 结构：

1. 发送方报告（SR）

SR 由媒体发送端（如摄像头）定期发送，包含自身的发送统计和时钟信息，是同步音视频的关键。

结构解析（共 28 字节起）：

• 固定头部：版本（V=2）、填充位（P）、报告数（RC，最多 31 个）；
• 核心字段：
  • NTP 时间戳（64 位⽆符号整数）：当前（报告发出）的绝对时间（如2024-05-20 12:00:00.123），用于跨设备同步（该时间戳的⾼32 bites以NTP格式表示，从1900年1⽉1⽇开始计数，以秒为单位。低32 bites表示秒后⾯的⼩数。如果需要转化Unix时间到NTP时间，在Unix时间加上2,208,988,800即可。）；
  • RTP 时间戳（32 位）：与 RTP 包中时间戳同源（如视频 90kHz 时钟下的计数）；
  • 时间戳 (NTP Timestamp, RTP Timestamp) 在 SR 中协同工作，提供媒体时钟与挂钟时间的映射关系。
  • 发送统计：表示这个同步源从这个会话开始到现在总发包数、总字节数（用于计算码率）。

实例：某摄像头的 SR 显示 “NTP 时间 = 1629408000.123，RTP 时间 = 12345678，总发包数 = 1000”，接收端可据此计算 “1 个 RTP 时间单位≈多少毫秒”，实现时钟对齐。

2. 接收方报告（RR）

RR 由媒体接收端（如播放器）发送，反馈 RTP 包的接收质量，帮助发送端调整策略。

结构解析（共 24 字节起）：

• 固定头部：与 SR 相同，RC 表示反馈的发送源数量；
• 报告块（每个 32 字节）：
  • 丢包率（8 位）：0~255 表示 0~100%（如 64=25% 丢包）；
  • 累计丢包数（24 位）：从会话开始至今丢失的总包数；
  • 抖动（32 位）：网络延迟波动的统计值（值越大，画面越可能卡顿）；
  • 最后接收的 SR 时间（LSR）：用于计算往返延迟。

实例：播放器发送 RR，丢包率 = 128（50%），抖动 = 100ms，发送端收到后可能降低码率或启用 FEC（前向纠错）。

3. 源描述报告（SDES）

SDES 用于传递会话参与者的元信息，确保多方通信时能识别彼此。

必选字段：

• CNAME（规范名）：唯一且永久的标识（如user123@domain.com），即使设备重启（SSRC 变化）也能关联到同一用户；
• 可选字段：NAME（昵称）、EMAIL（邮箱）、PHONE（电话）等。

实例：视频会议中，SDES 报文携带 “CNAME=alice@company.com，NAME=Alice”，其他参与者能在界面显示 “Alice 正在发言”。

4. 离开通知（BYE）

当设备退出会话（如关闭播放器、断网），BYE 报文会通知其他参与者 “我已离开”，避免资源浪费。

结构：包含退出的 SSRC 列表，可选 “离开原因”（如 “用户主动退出”）。

注意：BYE 可能丢失（如网络中断），接收端需通过 “超时未收到 RTP/RTCP” 判断对方离线。

5. 应用自定义（APP）

APP 允许应用自定义消息格式，用于标准 RTCP 未覆盖的场景（如 VR 直播中的设备姿态同步）。

结构：4 字节 ASCII 标识（如 “VRTP”）+ 自定义数据，接收端不认识的 APP 报文会被忽略。

四、总结一下RTP和RTCP如何协同

（一）RTCP 如何“描述” RTP 数据？

• SSRC (Synchronization Source Identifier) 是核心纽带：

  • 每个 RTP 流（通常来自一个源，如摄像头或麦克风）在 RTP 会话中被分配一个唯一的 32 位 SSRC 标识符。

  • 这个 SSRC 值出现在每个属于该流的 RTP 包的头部。

  • 关键的关联点： RTCP 数据包（特别是 Sender Report - SR 和 Receiver Report - RR）也包含这个 SSRC 标识符。

  • 因此，接收端收到一个 RTCP SR 包时，它看到包里的 SSRC = X，就知道这个报告描述的是所有 SSRC = X 的 RTP 包的发送方状态（在 SR 中）或者接收方对该流的接收状态（在 RR 中）。

• 时间窗口：

  • RTCP 报告（SR/RR）不是为单个 RTP 包生成的。它们周期性地发送（通常每 5 秒左右，或至少占会话带宽的 5%）。

  • SR 报告包含发送方在上一个报告间隔期间发送的所有 RTP 包的累积统计信息（发送的包总数、发送的字节总数）。

  • RR 报告包含接收方在上一个报告间隔期间接收到的来自特定 SSRC（在 RR 块中指定）的所有 RTP 包的累积统计信息（如丢包数、累计丢包数、最高接收序列号、抖动等）。

• 序列号 (sequence number) 的作用：

  • 每个 RTP 包都有一个单调递增的 16 位序列号。

  • RTCP RR 报告中包含 extended highest sequence number received（接收到的最高序列号的扩展形式）和 cumulative number of packets lost（累计丢包数）。

  • 接收端通过比较预期应接收到的序列号范围（基于之前的最高序列号和包间隔）和实际接收到的序列号，可以计算出在报告间隔内的丢包情况。虽然报告是累积的，但结合序列号信息，接收端能知道在哪个大致的序列号范围内发生了丢包。

• 总结关联性： RTCP 通过共享 SSRC 将报告与特定的 RTP 流关联起来。报告提供的是该流在前一个时间窗口内的整体发送或接收性能的统计摘要，而不是针对单个 RTP 包。接收端利用序列号信息可以推断出大致的丢包位置。

（二） RTCP 和 RTP 中的事件戳如何协同控制音视频同步？

建立媒体时间与真实时间的映射关系

音视频同步的本质是：让属于同一时刻采集的音频样本和视频帧，在播放端也于同一时刻播放出来。问题在于：

• 音频和视频是独立的 RTP 流：它们有各自独立的 SSRC、独立的 RTP 序列号、独立的 RTP 时间戳序列（基于各自的采样率）。

• RTP 时间戳是相对的：音频时间戳基于音频采样率（如 48000 Hz，每样本时间戳增量为 1），视频时间戳基于视频时钟频率（如 90000 Hz，每帧时间戳增量取决于帧率）。两者单位不同，无法直接比较。

• 设备时钟不同步：发送端和接收端的系统时钟（挂钟时间）可能不同步，且各自存在漂移。

RTCP SR 包 (NTP Timestamp + RTP Timestamp) 解决了这个问题！ 它为每个独立的媒体流提供了一个将自身媒体时间戳 (RTP Timestamp) 映射到绝对真实世界时间 (NTP Timestamp) 的基准点。

协同控制音视频同步的步骤：

假设有一个视频会议场景，包含一个音频流 (SSRC_A) 和一个视频流 (SSRC_V)。

1. 发送端捕获与标记

   • 当发送端决定为音频流 SSRC_A 发送一个 SR 包时：

     • 原子性操作： 它瞬间同时完成以下动作：

       • 捕获当前 NTP 时间 (NTP_TS_A): 获取精确的挂钟时间（理想情况下与 NTP 服务器同步）。

       • 捕获当前音频 RTP 时间戳 (RTP_TS_A): 读取此刻音频采样时钟计数器的值。这个值代表了捕获设备在 NTP_TS_A 这个绝对时间点正在处理的音频样本的时间戳。

   • 同样，当为视频流 SSRC_V 发送 SR 包时：

     • 原子性操作： 瞬间同时捕获：

       1. 捕获当前 NTP 时间 (NTP_TS_V)。 (注意：NTP_TS_A 和 NTP_TS_V 可能不同，因为 SR 发送时间不同)

       2. 捕获当前视频 RTP 时间戳 (RTP_TS_V)。

2. 发送端打包 SR:

   • 对于音频 SR (SSRC_A): 将 NTP_TS_A 和 RTP_TS_A 打包进 SR 包发送。

   • 对于视频 SR (SSRC_V): 将 NTP_TS_V 和 RTP_TS_V 打包进 SR 包发送。

3. 接收端接收与计算映射关系 

   • 接收端收到音频流的 SR (SSRC_A)：

     • 记录 NTP_TS_A (发送端在发送此 SR 时的绝对时间)。

     • 记录 RTP_TS_A (在 NTP_TS_A 时刻，音频流的媒体时间戳)。

     • 建立音频流映射： RTP_TS_A (音频时间) <==> NTP_TS_A (绝对时间)

   • 接收端收到视频流的 SR (SSRC_V)：

     • 记录 NTP_TS_V。

     • 记录 RTP_TS_V。

     • 建立视频流映射： RTP_TS_V (视频时间) <==> NTP_TS_V (绝对时间)

   • 关键点： 接收端现在知道如何把音频时间戳转换成绝对时间，也知道如何把视频时间戳转换成绝对时间。绝对时间 (NTP Timestamp) 成为了一个公共的、统一的时间轴！

4. 接收端同步播放：

   • 假设接收端要播放一个音频包：

     • 该音频包有自己的 RTP 时间戳 audio_ts。

     • 接收端利用音频流的映射关系 (RTP_TS_A <==> NTP_TS_A)，计算出 audio_ts 对应的绝对时间 target_ntp_audio。计算原理：

       • 计算音频时间差：delta_audio_ts = audio_ts - RTP_TS_A

       • 计算对应的绝对时间差 (基于音频采样率)：delta_ntp = delta_audio_ts / audio_sample_rate (例如 audio_sample_rate = 48000)

       • 目标绝对时间：target_ntp_audio = NTP_TS_A + delta_ntp

   • 假设接收端要播放一个视频帧：

     • 该视频帧有自己的 RTP 时间戳 video_ts。

     • 接收端利用视频流的映射关系 (RTP_TS_V <==> NTP_TS_V)，计算出 video_ts 对应的绝对时间 target_ntp_video。计算原理：

       • 计算视频时间差：delta_video_ts = video_ts - RTP_TS_V

       • 计算对应的绝对时间差 (基于视频时钟频率)：delta_ntp = delta_video_ts / video_clock_rate (例如 video_clock_rate = 90000)

       • 目标绝对时间：target_ntp_video = NTP_TS_V + delta_ntp

   • 同步决策：

     • 播放器有一个统一的播放时间轴，基于接收端本地估算的 NTP 时间 (接收端本地时钟最好也同步到 NTP)。

     • 播放器计算当前本地估算的 NTP 时间 current_ntp_local。

     • 对于即将播放的音频样本和视频帧：

       • 它计算音频样本的目标绝对时间 target_ntp_audio。

       • 它计算视频帧的目标绝对时间 target_ntp_video。

       • 播放准则： 当 current_ntp_local 达到或略晚于 target_ntp_audio 时，播放该音频样本；当 current_ntp_local 达到或略晚于 target_ntp_video 时，播放该视频帧。

     • 效果： 因为 target_ntp_audio 和 target_ntp_video 都是根据发送端同一个物理时刻（分别由各自的 SR 捕获）映射出来的绝对时间，所以原本在发送端同一物理时刻采集的音频和视频，它们的 target_ntp 值会非常接近（理想情况下相等）。播放器在相同的 current_ntp_local 时间播放它们，就实现了音画同步！

想象两个跑步者（音频流和视频流）在不同的跑道上（不同的时间戳序列）。裁判（发送端）在特定时刻（NTP_TS_A/V）分别记录下他们各自跑了多远（RTP_TS_A/V）。在终点（接收端），另一个裁判根据这些记录，可以推算出两个跑步者在裁判记录的那个共同时刻各自的位置。这样，终点裁判就能知道，当第一个跑步者到达某个位置时（某个音频时间戳），第二个跑步者应该在哪里（对应的视频时间戳），从而判断他们是否“齐头并进”（音画同步）。

五、RTSP协议

（一）RTSP 是什么：不止于 “传输” 的控制协议

RTSP 是一种基于文本的应用层协议，语法类似 HTTP，但专为实时媒体控制设计。它的核心作用是：

• 协调会话：让客户端（如播放器）和服务器（如直播服务器）达成共识（如媒体格式、传输方式）；
• 控制流传输：通过 “播放”“暂停”“录制” 等指令管理 RTP 流（音视频数据由 RTP 实际传输）；
• 维护状态：全程跟踪会话进度（如当前播放位置、传输端口），类似打电话时保持通话状态。

一句话总结：RTSP 是 “指挥官”，RTP 是 “运输兵”，前者发号施令，后者运送数据。

（二）RTSP 与 HTTP：看似相似，实则不同

RTSP 常被比作 “HTTP 的亲戚”，但两者在核心机制上有本质区别：

举例：用 RTSP 看直播时，你可以随时发送 “暂停” 指令，服务器会记住当前播放位置；而用 HTTP 下载视频，暂停后需重新请求，服务器不会保留你的进度。

（三）推流流程：如何把视频 “上传” 到服务器？

推流（如主播直播）是将本地音视频通过 RTSP 发送到服务器的过程，核心步骤分六步：

1. 第一步：OPTIONS——“问问服务器支持啥功能”

• 客户端→服务器：发送OPTIONS请求，询问服务器支持哪些操作（如能否录制、能否暂停）。

• 服务器→客户端：回复Public字段，列出支持的方法（如OPTIONS, DESCRIBE, RECORD等）。

• 作用：避免客户端发送服务器不支持的指令，浪费资源。

2. 第二步：ANNOUNCE——“告诉服务器我要发啥”

• 客户端→服务器：发送ANNOUNCE请求，携带 SDP（会话描述协议）信息，说明要推的媒体格式（如视频用 H.264、音频用 AAC）、采样率等。

• 服务器→客户端：回复确认，并返回Session ID（会话标识，后续操作需携带）。

• 作用：让服务器提前准备好接收特定格式的媒体流。

3. 第三步：SETUP——“约定传输通道”

• 客户端→服务器：发送SETUP请求，指定传输方式（如 UDP）和客户端端口（如 RTP 用 31590，RTCP 用 31591）。

• 服务器→客户端：回复确认，告知服务器端口（如 RTP 用 59472），并绑定Session ID。

• 细节：如果推流包含视频和音频，需分别SETUP（各自用独立端口）。
• 作用：打通客户端和服务器的 “数据高速公路”，确保 RTP 流能准确传输。

4. 第四步：RECORD——“推流开始”

• 客户端→服务器：发送RECORD请求，指令服务器开始接收 RTP 流。

• 服务器→客户端：回复确认，开始等待 RTP 数据。

• 作用：正式启动推流，此时客户端会通过 RTP 端口发送音视频数据。

5. 第五步：RTP 传输 ——“数据真正开始流动”

• 客户端通过SETUP约定的 UDP 端口，持续发送 RTP 包（视频用一个端口，音频用另一个）。

• 同时定时发送 RTCP 包反馈传输质量（如丢包率），服务器据此调整策略。

6. 第六步：TEARDOWN——“结束会话”

• 客户端→服务器：发送TEARDOWN请求，告知 “推流结束”。

• 服务器→客户端：回复确认，释放端口和会话资源。

• 作用：优雅关闭连接，避免资源浪费。

总结：

（四）拉流流程：如何从服务器 “拉取” 视频？

拉流（如观众看直播）是客户端从服务器获取媒体流的过程，步骤与推流类似，但部分关键指令不同：

举例：拉流时，DESCRIBE就像观众问 “你这有什么节目？”，服务器用 SDP 回复 “有 H.264 视频和 AAC 音频”；PLAY则像说 “开始播放吧”，服务器随后通过 RTP 发送数据。

（五）总结

1. Session ID：

• 由服务器在ANNOUNCE或SETUP时生成（如ditmIrW4Z20X），后续所有操作必须携带。
• 作用：服务器通过它识别 “哪个客户端在操作哪个流”，避免混淆。

2. Transport 字段：

格式示例：Transport: RTP/AVP/UDP;unicast;client_port=31590-31591;server_port=59472-59473

• RTP/AVP：用 RTP 传输，采用 AVP（音频视频配置文件）；
• unicast：单播（一对一传输）；
• client_port/server_port：客户端和服务器的 RTP/RTCP 端口对（RTP 用前一个，RTCP 用后一个）。
• 作用：明确数据走哪条 “路”，用什么 “规则” 传输。

3. CSeq：

• 每个 RTSP 请求 / 响应都有一个递增的序列号（如CSeq: 1、CSeq: 2）。
• 作用：匹配请求和响应（避免混乱），比如客户端发CSeq:3的请求，服务器必须用CSeq:3回复。

4. SDP协议作用（key-value）：

• 包含媒体类型（视频 / 音频）、编码格式（H.264/AAC）、采样率等关键信息。
• 推流时由客户端通过ANNOUNCE发送，拉流时由服务器通过DESCRIBE返回。
• 作用：让双方对 “要传输的媒体是什么样的” 达成共识。