RTSP协议（11）——连接（RFC2326）

RTSP协议（11）——连接

原文第九章

RTSP请求可以几种不同的方式传输：

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

传输连接的类型由rtspuri定义（第3.2节）。对于方案“rtsp”，假定存在持久连接，而方案“rtspu”则调用发送rtsp请求，而不设置连接。

与HTTP不同，RTSP允许媒体服务器向媒体客户端发送请求。但是，这只支持持久连接，因为媒体服务器没有可靠的方式到达客户端。而且，这是从媒体服务器到客户端的请求可能穿越防火墙的唯一方法。

1.流水线

支持持久连接或无连接模式的客户端可以“管道化”其请求（即，在不等待每个响应的情况下发送多个请求）。服务器必须以接收请求的相同顺序发送对这些请求的响应。

2.可靠性和确认

除非请求被发送到多播组，否则请求将由接收方确认。如果没有确认，发送方可以在一个往返时间（RTT）超时后重新发送相同的消息。在TCP（RFC 1123）[18]中估计往返时间，初始往返值为500ms。实现可以缓存最后的RTT测量值作为未来连接的初始值。

如果使用可靠的传输协议来承载RTSP，则请求不能被重传；RTSP应用程序必须依赖底层传输来提供可靠性。

如果底层可靠传输（如TCP）和RTSP应用程序都请求重新传输，则每个数据包丢失都可能导致两次重新传输。接收器通常不能利用应用层重传，因为传输堆栈在第一次尝试到达接收器之前不会传递应用层重传。如果分组丢失是由拥塞引起的，那么在不同的层上多次重传会加剧拥塞。

如果在小型RTT LAN上使用RTSP，则优化初始TCP往返估计的标准程序（如T/TCP（RFC 1644）[22]中使用的程序）可能是有益的。

时间戳报头（第12.38节）用于避免重传模糊问题[23，p。而且不需要卡恩的算法。

每个请求在CSeq报头中携带一个序列号（第12.17节），对于每个传输的不同请求，该序列号递增1。如果由于缺少确认而重复请求，则请求必须携带原始序列号（即序列号不递增）。

实现RTSP的系统必须支持通过TCP传输RTSP，并且可以支持UDP。对于UDP和TCP，RTSP服务器的默认端口都是554。

发往同一控制端点的多个RTSP分组可以打包到单个较低层PDU中或封装到TCP流中。RTSP数据可以与RTP和RTCP分组交织。与HTTP不同，RTSP消息必须包含Content-Length头，只要该消息包含有效负载。否则，RTSP数据包将在最后一个消息头之后立即以空行终止。