Live555源码解析(2) - RTSP协议概述

上一篇Live555源码解析(1) - Main 寻根问祖，留其筋骨将main()函数脉络做了整体分析，理论上本篇将从服务器的创建开始讲起，但众所周知，Live555媒体服务器是RTSP服务器的实现，因此继续追踪源码前，先整体介绍下RTSP协议及相关协议内容。如读者已掌握RTSP内容，则可跳过本篇，继续下一篇Live555源码解析(3) - 服务开启，愿者上钩的阅读。

编写本篇前，尽可能详细地翻译了RTSP Sepc，如有兴趣，可同时阅读[RTSP Spec中文版](http://www.jianshu.com/p/b0474f65e729)。

1. RTSP简史

RTSP出现以前，最热的大概就是HTTP协议。想象一下，当你需要欣赏网络中的某一段视频，通过HTTP协议访问其URL，开始下载，下载完成后播放。对于很久以前的视频采集设备、网络带宽或是负责播放的显示器而言，似乎多给予一点耐心、多重连几次断开的HTTP连接、甚至多校验几次下载后文件的完整性，体验上也还能过得去，毕竟那时候的分辨率、帧率、带宽限制了互联网途径传播媒体文件的大小，也因此各种硬盘、U盘、光盘才在大文件传输的路上独领风骚。

但时代在发展，采集设备分辨率在提升，显示器支持了更高的帧率，网络带宽也指数增长，我们不再需要像以前一样拥有良好的性格，才能静下心来观赏下载了半天的几分钟低清视频。当然下载后观看的场景HTTP依然是够用的，但伴随着网络资源的日益丰富，用户时间的稀缺性日益凸显，我们希望能够以在线的方式快速浏览、暂停、或是跳过某些对于个体信息量低的片段（如片头、片尾），此时，HTTP不再能够满足需求，也因此，RTSP站在其肩膀上，直面痛点，脱颖而出。

RTSP全称实时流协议（Real Time Streaming Protocol），它是一个网络控制协议，设计用于娱乐、会议系统中控制流媒体服务器。RTSP用于在希望通讯的两端建立并控制媒体会话，客户端通过发出VCR-style命令如play、record和pause等来实时控制媒体流。

RTSP处理流时会根据端点间可用带宽大小，将大数据切割成小分组，以使得客户端可以在播放一个分组的同时，可以解压第二个甚至同时下载第三个分组。这样一来，用户将不会感觉到数据间存在停顿。至于RTSP的特性，则主要体现在如下方面：

1. 多服务器兼容 ：媒体流可来自不同服务器
2. 可协商 ：客户端和服务器可协商feature支持程度
3. HTTP亲和性 ：尽可能重用HTTP概念，包括认证、状态码、解析等
4. 易解析 ：HTML或MIME解析器均可在RTSP中适用
5. 易扩展 ：新的方法或参数甚至协议本身均可添加或定制
6. 防火墙亲和性 ：传输层或应用层防火墙均可被协议较好处理
7. 服务器控制 ：控制概念易于理解，服务器不允许向客户端传输不能被客户端关闭的流
8. 多场景适用 ：RTSP提供帧级别精度，适用于更多媒体应用场景

1.1 相关协议介绍

RTSP组合使用了可靠传输协议TCP（控制）和高效传输协议UDP（内容）来串流内容给用户，即文件开始传输而客户端不用等待整个文件内容抵达就开始播放。其实不仅仅是点播服务，RTSP还支持传输不能以传统方式下载后播放的直播内容。

RTSP也并不负责数据传输，通常（非必须）是通过RTP（Real-time Transport Protocol）来完成，而RTP中，又通过RTCP负责完成同步、QOS管理等功能。具体应用中，它们三者的关系如下图所示：

2. RTSP方法

RTSP中并没有连接的概念，而是通过会话（Session）进行管理。每个会话有对应的会话ID，会话中可能可能涉及一至多个流，会话生命周期中，客户端也可能切换连接（如TCP）来传递RTSP请求（request）。

method	direction	object	requirement
DESCRIBE	C->S	P,S	recommended
ANNOUNCE	C->S, S->C	P,S	optional
GET_PARAMETER	C->S, S->C	P,S	optiona