【网络通信 -- 直播】网络通信协议简介 -- RTSP

【网络通信 -- 直播】网络通信协议简介 -- RTSP

【0】简介

实时流传输协议(RTSP，Real Time Streaming Protocol) 是 TCP/IP 协议体系中的一个应用层协议，由哥伦比亚大学、网景和 RealNetworks 公司提交的 IETF RFC 标准；该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据，RTSP 在体系结构上位于 RTP 和 RTCP 之上，使用 TCP 或 UDP 完成数据传输；

RTSP 是用于控制音视频多媒体串流的协议，允许同时对多个串流进行控制，以降低服务器端的网络用量，支持多方视讯会议，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用 TCP 或 UDP 来传送串流内容，其语法和运作类似 HTTP 1.1，但并不特别强调时间同步，因此比较能容忍网络延迟；同时，具备代理服务器 (Proxy) 的缓存功能 (Cache)；具备重定向功能，从而可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟；

RTSP 是基于文本的协议，采用 ISO10646 字符集，使用 UTF-8 编码方案；每一行以 CRLF 中断（\r\n:10,13:0x0A,0x0D），包括消息类型、消息头、消息体和消息长；接收者可将 CR 和 LF 解释成行终止符；基于文本的协议使其更易于增加可选参数，接口中采用 SDP 作为描述语言；RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能；

RTSP 协议特点

• 可扩展性，新方法和参数很容易加入 RTSP；
• 易解析，RTSP 可由标准 HTTP 或 MIME 解析器解析；
• 安全，RTSP 使用网页安全机制；
• 独立于传输，RTSP 可使用不可靠数据报协议（EDP）、可靠数据报协议（RDP）；可使用可靠流协议实现应用级可靠；
• 多服务器支持，每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行；
• 记录设备控制，协议可控制记录和回放设备；
• 流控与会议开始分离，仅要求会议初始化协议提供，或可用来创建惟一会议标识号；特殊情况下，可用 SIP 或 H.323 来邀请服务器入会；
• 适合专业应用，通过相对时间戳(SMPTE，SMPTE Relative Timestamps)，RTSP 支持帧级精度，允许远程数字编辑；
• 演示描述中立，协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个 RTSP URL；
• 代理与防火墙友好，协议可由应用和传输层防火墙处理，防火墙需要理解 SETUP 方法，为 UDP 媒体流打开一个“缺口”；
• HTTP 友好，RTSP 明智地采用 HTTP 观念，使现在结构都可重用；
• 适当的服务器控制，如用户可以启动一个流，也可以停止一个流；
• 传输协调，实际处理连续媒体流前，用户可协调传输方法；
• 性能协调，若基本特征无效，必须有一些清理机制让用户决定哪种方法无效；

RTSP 协议与 HTTP 协议区别

• 1. RTSP 引入了几种新的方法，如 DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP 为 rtsp 1.0，HTTP 为 http 1.1；
• 2. HTTP 是无状态的协议，RTSP 会为每个会话保持状态；
• 3. RTSP 协议的客户端和服务器端都可以发送 Request 请求，而在 HTTP 协议中，只有客户端能发送 Request 请求；
• 4. 在 RTSP 协议中，载荷数据一般是通过带外方式来传送的(除了内嵌的情况)，及通过 RTP 协议在不同的通道中来传送载荷数据；HTTP 协议的载荷数据都是通过内嵌方式传送的，比如请求的网页数据是在回应的消息体中携带的；
• 5. 使用 ISO10646(UTF-8) 而不是 ISO 8859-1 以配合当前 HTML 的国际化；
• 6. RTSP 使用 URI 请求时包含绝对 URI；HTTP/1.1 只在请求中包含绝对路径，把主机名放入单独的标题域中；

RTSP 与 RTP / RTCP 区别

• RTSP 是一种双向实时数据传输协议，其允许客户端向服务器端发送请求，如回放、快进、倒退等操作；RTSP 可基于 RTP 来传送数据，还可以选择 TCP、UDP、组播 UDP 等通道来发送数据，具有很好的扩展性，是一种类似于 http 协议的网络应用层协议；
• RTCP 控制协议需要与 RTP 数据协议一起配合使用，当应用程序启动一个 RTP 会话时将同时占用两个端口，分别供 RTP 和 RTCP 使用；RTP 本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由 RTCP 来负责完成；通常 RTCP 会采用与 RTP 相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断；
• RTP 是实时传输协议，一般不作为单独应用层协议处理；RTP 数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个 RTP 数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前 12 个字节的含义是固定的，而负载则可以是音频或者视频数据；RTP 用到的地方就是 PLAY，服务器往客户端传输数据用 UDP 协议，RTP 是在传输数据的前面加了个 12 字节的头(描述信息)；
• RTP，RTCP 和 RTSP 共享 TCP 通道，因此必须有一个标识来区别三种数据，RTP 和 RTCP 数据会以 $ 符号 + 1 个字节的通道编号 + 4 个字节的数据长度，共 6 个字节的前缀开始，RTSP 数据是没有前缀数据的；RTP 数据和 RTCP 数据的区别在于第二个字节的通道编号，RTP 通道编号是偶数，RTCP 通道编号是奇数；

RTP over UDP，RTP over TCP 和 RTP over RTSP 的区别

• RTP over UDP 是 RTP 下层使用 udp 传输，RTP over RTSP 是指用 rtsp 协议建立会话，然后使用 RTP 协议传输数据；
• RTP over RTSP 是指用 rtsp 协议建立会话，然后使用 RTP 协议传输数据，传输层协议是不确定的；

【1】RTSP 中的术语

• 1. 集合控制(Aggregatecontrol)，对多个流的同时控制；客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流；
• 2. 实体(Entity)，作为请求或者回应的有效负荷传输的信息；由以实体标题域(entity-header field)形式存在的元信息和以实体主体(entity body)形式存在的内容组成；
• 3. 容器文件(Containerfile)，可以容纳多个媒体流的文件；RTSP 服务器可以为这些容器文件提供集合控制；
• 4. RTSP 会话(RTSP session)，RTSP 交互的全过程；对于一个视频的播放过程，会话(session)包括由客户端建立媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流；
• 5. 消息(Message)，RTSP 通信的基本单元，由特定语法结构，序列化的八位字节流组成；

【2】RTSP 消息格式

【2.1】RTSP 请求消息格式

• 方法包括 OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN 等；
• URL 是接接收方的地址；
• RTSP 版本一般为 RTSP/1.0；
• CRLF 表示回车换行(位于每行的末尾)，需要接收端进行相应的解析；
• 最后一个消息头需要有两个 CRLF；
• 消息体是可选的，有的请求消息并不带消息体；

【2.2】RTSP 响应消息格式

• RTSP 版本一般为 RTSP/1.0；
• 状态码是一个数值，用于表示请求消息的执行结果；
• 短语是与状态码对应的文本解释；
• CRLF 表示回车换行(位于每行的末尾)，需要接收端进行相应的解析；
• 最后一个消息头需要有两个 CRLF；
• 消息体是可选的，有的请求消息并不带消息体；

【3】RTSP 交互流程

【3.1】RTSP 交互流程图示

【3.2】RTSP 方法描述

方法	方向	对象	要求	含义
DESCRIBE	C->S	P，S	推荐	检查演示或媒体对象的描述，也允许使用接收头指定用户理解的描述格式；DESCRIBE 的答复-响应组成媒体 RTSP 初始阶段
ANNOUNCE	C->S、S->C	P，S	可选	当从用户发往服务器时，ANNOUNCE 将请求 URL 识别的演示或媒体对象描述发送给服务器；当从服务器发往客户端时，ANNOUNCE 实时更新连接描述；如新媒体流加入演示，整个演示描述再次发送，而不仅仅是附加组件，使组件能被删除
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	可选	重定向请求，用于服务器通知客户端新的服务地址，客户端需要向这个新地址重新发起请求；重定向请求中可能包含 Range 参数，指明重定向生效的时间；客户端若需向新服务地址发起请求，必须先 teardown 当前会话，再向指定的新主机 setup 一个新的会话；
SETUP	C->S	S	要求	对 URL 的 SETUP 请求指定用于流媒体的传输机制；客户端对正播放的流发布一个 SETUP 请求，以改变服务器允许的传输参数；若不允许此操作，则响应错误为 "455 Method Not Valid In This State”；为了穿透防火墙，客户端必须指明传输参数；
SET_PARAMETER	C->S、S->C	P，S	可选	用于设置指定媒体流的参数；
GET_PARAMETER	C->S、S->C	P，S	可选	GET_PARAMETER 请求检查 URL 指定的演示与媒体的参数值；若没有实体体时，GET_PARAMETER 也能用来测试用户与服务器的连通情况
TEARDOWN	C->S	P，S	要求	TEARDOWN 请求停止给定 URL 流发送，释放相关资源；

其中，P : 演示(presentation)，S : 流(stream)，C : 客户端(client)，S : 服务端(server)；

嵌入二进制数据

由于某些防火墙设计与其他环境，可能要求服务器内嵌 RTSP 方法和流数据；由于内嵌将使客户端和服务器操作变得复杂，并增加额外的开销，因此除非有必要，否则应避免该操作；注意，内嵌二进制数据仅在 RTSP 通过 TCP 传输时才可使用；
流数据( 如 RTP 包) 用  ASCII 字符 $ 封装，其后跟一个一字节的通道标识，其后跟两字节整数表示封装二进制数据的长度，其后是流数据，没有 CRLF，但包括高层协议头；每个 $ 块包含一个高层协议数据单元；
当传输选择为 RTP 时，RTCP 信息也被服务器通过 TCP 连接内嵌；缺省情况下，RTCP 包在高于 RTP 通道的第一个可用通道上发送；客户端可能在另一通道显式请求 RTCP 包，此时可以通过在传输头的插入参数中指定两个通道来实现；当嵌入两个或更多流时，为取得同步，需要使用 RTCP；而且，嵌入二进制数据为当网络设置需要通过 TCP 控制连接打洞 RTP/RTCP 提供了一条方便的途径，可能时可以在 UDP 上进行传输；

【3.3】RTSP 关键方法描述

【3.4】RTSP 消息实例

OPTIONS
OPTIONS 请求是客户端向服务器询问可用的方法；

DESCRIBE
客户端向服务器请求媒体资源描述，服务器端通过 SDP(Session Description Protocol) 格式回应客户端的请求；资源描述中会列出所请求媒体的媒体流及其相关信息，典型情况下，音频和视频分别作为一个媒体流传输；

ANNOUNCE
C->S，ANNOUNCE 将由请求 URL 标识的表示或媒体对象的描述发布到服务器；
S->C，ANNOUNCE 实时更新会话描述；

SETUP
SETUP 请求用于确定具体的媒体流的传输方式，该请求必须在 PLAY 请求之前发送；SETUP 请求包含媒体流的 URL 和客户端用于接收 RTP 数据(audio or video)的端口以及接收 RTCP 数据(meta information)的端口；服务器端的回复通常包含客户端请求参数的确认，并会补充缺失的部分，每一个媒体流在发送 PLAY 请求之前，都要首先通过 SETUP 请求来进行相应的配置；

PLAY
客户端通过 PLAY 请求来播放一个或全部媒体流，PLAY 请求可以发送一次或多次；发送一次时，URL 为包含所有媒体流的地址，发送多次时，每一次请求携带的 URL 只包含一个相应的媒体流；PLAY 请求中可指定播放的范围，若未指定则从媒体流的开始播放到结束，如果媒体流在播放过程中被暂停则可在暂停处重新启动流的播放；

服务端播放 10 - 15，20 - 25，30 - end；

服务端从 0:10:20 开始播放整个演示直到演示结束，并在 15:36 on 23 Jan 1997 开始重播；

使用时钟单位描述一个直播演示的重播；

PAUSE
PAUSE 请求会暂停一个或所有媒体流，后续可通过 PLAY 请求恢复播放；PAUSE 请求中携带所请求媒体流的 URL，若参数 range 存在，则指明在何处暂停，若该参数不存在，则暂停立即生效，且暂停时长不确定；

TEARDOWN
结束会话请求，该请求会停止所有媒体流，并释放服务器上的相关会话数据；

GET_PARAMETER
检索指定 URI 数据中的参数值，不携带消息体的 GET_PARAMETER 可用来测试服务器端或客户端是否可通(类似 ping 的功能)；

SET_PARAMETER
用于设置指定媒体流的参数；

REDIRECT
重定向请求，用于服务器通知客户端新的服务地址，客户端需要向这个新地址重新发起请求；重定向请求中可能包含 Range 参数，指明重定向生效的时间；客户端若需向新服务地址发起请求，必须先 teardown 当前会话，再向指定的新主机 setup 一个新的会话；

RECORD
请求录制指定范围的媒体数据，请求中可指定录制的起止时间戳；若未指定时间范围，则使用 presentation description 中的开始和结束时间，该情况下，若会话已开始则立即启动录制操作；

【4】RTSP 拉流/推流流程总结

【4.1】推流过程

• Option 查询服务器端可用方法
  • 1. C->S:OPTION request  //询问 Server 有哪些⽅法可⽤
  • 2. S->C:OPTION response //Server 回应信息的 public 头字段中包括提供的所有可⽤⽅法
• Announce 发送媒体描述信息
  • 1. C->S:ANNOUNCE request    //客户端发送媒体描述信息给服务器
  • 2. S->C:ANNOUNCE response   //Server 回应媒体描述信息并返回 Session ID
• Setup 建立 RTSP 会话
  • 1. C->S:SETUP request   //通过 Transport 头字段列出可接受的传输选项，请求 Server 建⽴会话
  • 2. S->C:SETUP response  //Sever 建⽴会话，通过 Transport 头字段返回选择的具体转输选项，并返回建⽴的 Session ID
• Record 请求传送数据
  • 1. C->S:RECORD request  //Client 向 Server 请求发送数据
  • 2. S->C:RECORD response //Server 回应该允许的信息
• RTP 数据推送
  • 1. C->S:发送流媒体数据  //通过RTP协议传送数据
• Teardown 关闭会话，推出
  • 1. C->S:TEARDOWN request    //C请求关闭会话
  • 2. S->C:TEARDOWN response   //S回应该请求

【4.2】拉流过程

• Option 查询服务器端可用方法
  • 1. C->S:OPTION request  //询问 Server 有哪些⽅法可⽤
  • 2. S->C:OPTION response //Server 回应信息的 public 头字段中包括提供的所有可⽤⽅法
• Describe 得到媒体描述信息
  • 1. C->S:DESCRIBE request    //要求得到 Server 提供的媒体描述信息
  • 2. S->C:DESCRIBE response   //Server 回应媒体描述信息，⼀般是 sdp 信息
• Setup 建立 RTSP 会话
  • 1. C->S:SETUP request   //通过 Transport 头字段列出可接受的传输选项，请求 Server 建⽴会话
  • 2. S->C:SETUP response  //Sever 建⽴会话，通过 Transport 头字段返回选择的具体转输选项，并返回建⽴的 Session ID
• Play 请求开始传输数据
  • 1. C->S:PLAY request    //Client 请求 Server 开始发送数据
  • 2. S->C:PLAYresponse    //Server 回应该请求的信息
• RTP 数据拉取
  • 1. S->C:发送流媒体数据  //通过 RTP 协议传送数据
• Teardown 关闭会话，推出
  • 1. C->S:TEARDOWN request    //C请求关闭会话
  • 2. S->C:TEARDOWN response   //S回应该请求

参考致谢
本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。

【1】RTSP_rfc2326

【2】网络流媒体协议之——RTSP协议

【3】实时流协议(RTSP)简介

【4】RTSP Spec中文版

【5】RTSP协议分析