RTSP协议抓包及讲解

文章目录

前言
一、RTSP 亲手搭建直播点播
- 1、数据源为视频文件
- 2、数据源为摄像头
- - ①、搭建 RTSP 流媒体服务器
  - ②、客户端拉流
二、RTSP 协议简介
三、手撕 RTSP 协议
- 1、Wireshark 抓包
- - ①、搭建环境
  - ②、wireshark 抓包
- 2、RTSP 交互流程
- - ①、OPTIONS
  - ②、DESCRIBE
  - ③、SETUP
  - ④、PLAY
  - ⑤、TEARDOWN
- 3、协议格式
- - ①、请求消息
  - ②、应答消息
- 4、方法定义
- 5、状态
四、RTSP 与 HTTP

前言

本节主要讲解 RTSP 协议，通过 wireshark 抓包的方式对协议进行分析。

一、RTSP 亲手搭建直播点播

测试工具：VLC
数据源：文件或本地摄像头
测试功能：RTSP 直播点播

播放地址： rtsp://127.0.0.1:554/test
服务端：推流
客户端：拉流

1、数据源为视频文件

参考我之前的博客 “音视频开发常用工具” 下图部分
在这里插入图片描述

2、数据源为摄像头

①、搭建 RTSP 流媒体服务器

<1>、点击媒体 -> 流
在这里插入图片描述
<2>、选择捕获设备，视频设备我们选择笔记本电脑内置摄像头，电击串流

<3>、点击下一个

<4>、新目标选择 RTSP，点击添加

<5>、修改路径，并点击下一个

<6>、配置文件选择 Video - H.264 + MP3 (TS)，点击下一个
在这里插入图片描述
<7>、点击流

<8>、可以看到进度条开始动了，这样一个 RTSP 流媒体服务器就搭建好了，目前正在进行推流

②、客户端拉流

<1>、再打开一个 VLC media player，选择媒体 -> 打开网络串流
在这里插入图片描述
<2>、网络 URL 修改为：rtsp://:8554/test2，点击播放

<3>、下图左边是服务端在推流，右边是客户端在拉流

上面两个例子实现了数据源分别是文件和摄像头时，搭建了 RTSP 直播点播功能

二、RTSP 协议简介

RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议，是 TCP/IP 协议体系中的一个应用层协议，由哥伦比亚大学、网景和 RealNetworks 公司提交的 IETF RFC 标准。该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。RTSP 是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制。

RTSP 在体系结构上位于 RTP 和 RTCP 之上，它使用 TCP 或 UDP 完成数据传输。

HTTP 与 RTSP 相比，HTTP 请求由客户机发出，服务器作出响应；使用 RTSP 时，客户机和服务器都可以发出请求，即 RTSP 可以是双向的。

实时流媒体会话协议

SDP（会话描述协议）Session Description Protocol
RTP（实时传输协议）Realtime Transfer Protocol：音视频流

在这里插入图片描述
RTSP 是基于文本的协议，采用 ISO10646 字符集，使用 UTF-8 编码方案

行以 CRLF 中断（ \r\n:10,13:0x0A,0x0D），包括消息类型、消息头、消息体和消息长。但接收者本身可将 CR 和 LF 解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用 SDP 作为描述语言。

RTSP 是应用级协议，控制实时数据的发送。

RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如 UDP、组播 UDP 与 TCP 提供途径，并为选择基于 RTP 上发送机制提供方法。
在这里插入图片描述
RTSP 协议支持：

从媒体服务器上检索媒体
媒体服务器邀请进入会议
将媒体加到现成讲座中

三、手撕 RTSP 协议

既然要分析 RTSP 协议，那么我们先抓取相应的报文，然后根据报文去分析 RTSP 协议。

1、Wireshark 抓包

①、搭建环境

虚拟机（192.168.137.128）：使用 VLC 推流
在这里插入图片描述
windows 主机（192.168.167.176）：使用 VLC 拉流

②、wireshark 抓包

选择虚拟机的网卡
在这里插入图片描述
可以看到抓到的部分报文如下

2、RTSP 交互流程

假设我们现在要向一个 RTSP 的 sever 发送请求获取数据，基本流程如下：
在这里插入图片描述

①、OPTIONS

C -> S：客户端向服务器端发送 OPTIONS，请求可用的方法。
S -> C：服务器端回复客户端，消息中包含当前可用的方法。

②、DESCRIBE

C -> S：客户端向服务器请求媒体描述文件。
S -> C：服务器回复客户端 sdp 文件，该文件告诉客户端服务器有哪些音视频流，有什么属性，如编解码器信息，帧率等。

这里对 SDP 文本进行一个简要的分析，完整信息如下图：
(v)：0 //指示协议的版本
(o)：- 16771609170375560276 16771609170375560276 IN IP4 lpvm //与会话所有者有关的六个参数
- 第一个参数：表明会话发起者的名称，该参数可不填写，如填写和 SIP 消息中，from 消息头的内容一致
- 第二个参数：主叫方的会话标识符
- 第三个参数：主叫方会话的版本，会话数据有改变时，版本号递增
- 第四个参数：定义了网络类型，IN 表示 Internet 网络类型，目前仅定义该网络类型
- 第五个参数：地址类型，目前支持 IPV4 和 IPV6 两种地址类型
- 第六个参数：地址：表明会话发起者的 IP 地址，该地址为信令面的 IP 地址，信令 PDP 激活时为手机分配
(s)：Unnamed //表明本次会话的标题，或会话的名称
(i)：N/A //会话的描述
(c)：IN IP4 0.0.0.0 //c 行包含为多媒体会话而建立的连接的信息，其中指出了真正的媒体流使用的 IP 地址。
- 第一个参数为网络类型，目前仅定义 INTERNET 网络类型。用 “IN” 表示
- 第二个参数为地址类型，目前支持两种地址类型：IPV4 和 IPV6
- 第三个参数为地址，该地址为多媒体流使用的 IP 地址
(t)：0 0 //表示会话的开始时间和结束时间
(m)：audio 0 RTP/AVP 14 //m 行又称媒体行，描述了发送方所支持的媒体类型等信息
- 第一个参数为媒体名称：表明支持音频类型。
- 第二个参数为端口号，表明 UE 在本地端口为 0 上发送音频流。
- 第三个参数为传输协议，一般为 RTP/AVP 协议。
- 四-七参数为所支持的四种净荷类型编号
(a)：rtpmap:14 MPA/90000/2 //a 行为媒体的属性行，以属性的名称：属性值的方式表示。
- 格式为：a=rtpmap:<净荷类型><编码名称>

③、SETUP

为音视频数据的传输准备通道

C -> S：客户端向服务器端发起建立连接请求，请求建立会话连接，准备开始接收音视频数据，请求信息描述了期望音视频数据包基于 UDP 还是 TCP 传输，指定了 RTP，RTCP 端口，以及是单播还是组播等信息！
S -> C：服务器端收到客户端请求后，根据客户端请求的端口号确定发送控制数据的端口以及音视频数据的端口！

④、PLAY

C -> S：客户端向服务端请求播放媒体。
S -> C：服务器回复客户端 200 OK！之后开始通过 SETUP 中指定的端口开始发送数据！

⑤、TEARDOWN

C -> S：结束播放的时候，客户端向服务器端发起结束请求
S -> C：服务端收到消息后，向客户端发送 200 OK，之后断开连接

其中第 ③ 步和第 ④ 步是必需的！第 ① 步，只要服务器客户端约定好，有哪些方法可用，则 option 请求可以不要。第 ② 步，如果我们有其他途径得到媒体初始化描述信息（比如 http 请求等等），则我们也不需要通过 rtsp 中的describe 请求来完成。
上述的流程基本涵盖了 RTSP 的流程，当然，RTSP 除此之外，还有 PAUSE，SCALE，GET_PARAMETER，SET_PARAMETER 等参数。

3、协议格式

RTSP 中所有的操作都是通过服务器和客户端的消息应答机制完成的，其中消息包括请求和应答两种，RTSP 是对称的协议，客户机和服务器都可以发送和回应请求。

RTSP 是一个基于文本的协议，它使用 UTF-8 编码（RFC2279）和 ISO10646 字符序列，采用 RFC882 定义的通用消息格式，每个语句行由 CRLF 结束(\r\n)。RTSP 的消息包括请求和应答两类。

①、请求消息

请求消息由请求行、标题行中的各种标题域和主体实体组成。请求消息的格式如下图：
在这里插入图片描述

方法：包括 OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN 等
URL ：接收方的地址，例如：rtsp://192.168.137.128:8554/test
RTSP 版本：一般都是 RTSP/1.0
CRLF：每行后面的 CRLF 表示回车换行，需要接收端有相应的解析，最后一个消息头需要有两个 CRLF。
实体主体：消息体是可选的，有的请求消息并不带消息体。

②、应答消息

响应报文的开始行是状态行，RTSP 应答消息的格式如下图：
在这里插入图片描述

状态码：是一个数值，用于表示请求消息的执行结果，比如 200 表示成功。
短语：与状态码对应的文本解释

4、方法定义

注： P----演示， S----流， C----用户端， S----服务器端

方法	方向	对象	要求	含义
DESCRIBE	C -> S	P，S	推荐	检查演示或媒体对象的描述，也允许使用接收头指定用户理解的描述格式。DESCRIBE 的答复-响应组成媒体 RTSP 初始阶段
ANNOUNCE	C -> S S->C	P，S	可选	当从用户发往服务器时，ANNOUNCE 将请求 URL 识别的演示或媒体对象描述发送给服务器；反之，ANNOUNCE 实时更新连接描述。如新媒体流加入演示，整个演示描述再次发送，而不仅仅是附加组件，使组件能被删除
GET_PARAMETER	C -> S S->C	P，S	可选	GET_PARAMETER 请求检查 URL 指定的演示与媒体的参数值。没有实体时，GET_PARAMETER 也许能用来测试用户与服务器的连通情况
OPTIONS	C -> S S -> C	P，S	要求	可在任意时刻发出 OPTIONS 请求，如用户打算尝试非标准请求，并不影响服务器状态
PAUSE	C -> S	P，S	推荐	PAUSE 请求引起流发送临时中断。如请求 URL 命名一个流，仅回放和记录被停止；如请求 URL 命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。在 SETUP 消息中连接头超时参数所指定时段期间被暂停后，尽管服务器可能关闭连接并释放资源，但服务器资源会被预订
PLAY	C -> S	P，S	要求	PLAY 告诉服务器以 SETUP 指定的机制开始发送数据；直到一些 SETUP请求被成功响应，客户端才可发布 PLAY 请求。PLAY 请求将正常播放时间设置在所指定范围的起始处，发送流数据直到范围的结束处。PLAY 请求可排成队列，服务器将 PLAY 请求排成队列，顺序执行
RECORD	C -> S	P，S	可选	该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求 URL 或其他 URL 决定是否存储记录的数据；如服务器没有使用 URL 请求，响应应为 201（创建），并包含描述请求状态和参考新资源的实体与位置头。支持现场演示记录的媒体服务器必须支持时钟范围格式，smpte 格式没有意义
REDIRECT	S -> C	P，S	可选	重定向请求通知客户端连接到另一服务器地址。它包含强制头地址，指示客户端发布 URL 请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收 URL 媒体，客户端必须对当前连接发送 TEARDOWN 请求，而对指定主执新连接发送 SETUP 请求
SETUP	C -> S	P，S	可选	对 URL 的 SETUP 请求指定用于流媒体的传输机制。客户端对正播放的流发布一个 SETUP 请求，以改变服务器允许的传输参数。如不允许这样做，响应错误为"455 Method Not Valid In This State”。为了透过防火墙，客户端必须指明传输参数，即使对这些参数没有影响
SET_PARAMETER	C -> S S -> C	P，S	要求	这个方法请求设置演示或 URL 指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用 SETUP 命令设置。将设置传输参数限制为 SETUP 有利于防火墙。将参数划分成规则排列形式，结果有更多有意义的错误指示
TEARDOWN	C -> S	P，S	要求	TEARDOWN 请求停止给定 URL 流发送，释放相关资源。如 URL 是此演示 URL，任何 RTSP 连接标识不再有效。除非全部传输参数是连接描述定义的，SETUP 请求必须在连接可再次播放前发布

5、状态

RTSP 状态机
RTSP 控制通过单独协议发送的数据流，与控制通道无关。例如，RTSP 控制可通过 TCP 连接，而数据流通过 UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同 TCP 连接顺序发出请求来控制。所以，服务器需要维持能与 RTSP 请求的连接状态联系流。 RTSP 中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：