9 Connections (连接)

RTSP 请求可通过多种方式传输:

用于多次请求-响应事务的持久传输连接;
每个请求/响应事务一条连接;
无连接模式。

传输连接类型由 RTSP URI (第 3.2 节) 定义。对 scheme "rtsp", 假定持久连接; scheme "rtspu" 则要求在不建立连接的情况下发送 RTSP 请求。

与 HTTP 不同, RTSP 允许媒体服务器向媒体客户端发送请求。但这仅持久连接支持, 否则媒体服务器没有可靠方式到达客户端。此外, 这也是服务器到客户端的请求较可能穿越防火墙的唯一方式。

9.1 Pipelining (流水线)

支持持久连接或无连接模式的客户端 MAY 对其请求进行 "流水线" 处理 (即发送多个请求而不等待每个响应)。服务器 MUST 按接收请求的顺序发送对这些请求的响应。

9.2 Reliability and Acknowledgements (可靠性与确认)

除非发往组播组, 否则接收方对请求予以确认。若无确认, 发送方可在一个往返时间 (RTT) 超时后重发同一消息。往返时间按 TCP (RFC 1123) [18] 估计, 初始往返值为 500 ms。实现 MAY 将上次 RTT 测量缓存为后续连接的初值。

若使用可靠传输协议承载 RTSP, 请求 MUST NOT 重传; RTSP 应用 MUST 改为依赖底层传输提供可靠性。

若底层可靠传输 (如 TCP) 与 RTSP 应用均重传请求, 则每次丢包可能导致两次重传。接收方通常无法利用应用层重传, 因为

在首次尝试到达接收方之前, 传输栈不会将应用层重传交付给应用。若丢包由拥塞引起, 不同层的多次重传将加剧拥塞。

若在 RTT 较小的局域网上使用 RTSP, 诸如 T/TCP (RFC 1644) [22] 中所用的优化初始 TCP 往返估计的标准做法可能有益。

Timestamp 头部 (第 12.38 节) 用于避免重传歧义问题 [23, p. 301], 并省去对 Karn 算法的需求。

每个请求在 CSeq 头部 (第 12.17 节) 中带序列号, 每发送一个不同请求递增一。若因未收到确认而重复请求, 请求 MUST 携带原序列号 (即序列号不递增)。

实现 RTSP 的系统 MUST 支持通过 TCP 承载 RTSP, 并 MAY 支持 UDP。RTSP 服务器对 UDP 与 TCP 的默认端口均为 554。

发往同一控制端点的多个 RTSP 数据包可封装进单个下层 PDU 或封装入 TCP 流。RTSP 数据 MAY 与 RTP 与 RTCP 包交错。与 HTTP 不同, 每当消息含有效载荷时 RTSP 消息 MUST 包含 Content-Length 头部。否则, RTSP 包在最后一个消息头部后的空行处终止。