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数据包将在最后一个消息头之后立即以空行终止。