rtsp协议 编码_海康rtsp协议_http 协议(17)

| Content-Base ;Section 12.11

| Content-Encoding ; Section 12.12

| Content-Language ; Section 12.13

|Content-Length ; Section 12.14

| Content-Location ; Section 12.15

| Content-Type ;Section 12.16

|Expires; Section 12.19

|Last-Modified ; Section 12.24

| extension-header

extension-header= message-header

扩展头部机制允许定义附加实体头部域，而不用改变协议，但并不能假定接收者能识别这些附加域。不被识别的头部域应被接收者忽略，而让代理发送。

8.2 实体主体

见[H7.2]及其全部子章节

9 连接

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

*1、持久传输连接，用于多个请求-响应传输。

*2、每个请求-响应传输对应一个连接。

*3、无连接模式。

传输连接类型由RTSPURI（见3.2节）来定义。"rtsp" 方案说明需要持续连接；而"rtspu"方案，则要求不建立连接就直接发送RTSP请求。

和HTTP不同的是，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接模式中才支持，否则媒体服务器没有可靠途径到达用户。这也是通过防火墙从媒体服务器传送请求到用户的唯一办法。

9.1 管道

支持持久连接或无连接的客户端可能会使用"管道方式"传送请求（即是说：发送多个请求而不需等待单个的响应）。服务器必须以和收到的请求同样的顺序发出响应。

9.2 可靠性及确认

接受方需要确认请求，除非请求是发给多播组。如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。RTT在TCP中估计，初始为500 ms。一个实现可能会缓存最后所测量的RTT，作为将来连接的初始。

如使用可靠传输协议来承载RTSP，则请求不允许重发，RTSP应用程序必须依赖低层传输协议来保证可靠性。

如低层可靠传输协议（如TCP）和RTSP应用程序都重发请求，有可能每次丢包都导致两次重传。由于传输栈在第一次尝试到达接收者以前不会发送应用层重传，所以接收者并不能充分利用应用层重传。若丢包由网络阻塞引起，多个层上的的共同重发将使阻塞进一步恶化。

如果RTSP被用在小RTT网络，使用标准的初始TCP RTT时间测量优化过程，像T/TCP (RFC 1644) [22]那样，将是有益的。

时间戳头部（见章节12.38）被用来避免重传后乱序的问题[23, p. 301]，以及回避对Karn算法的依赖。

每个请求都带有一个序列号，位于CSeq头部（见章节12.17），每发出一个单独的请求，这个序列号就加一。如果由于缺少确认而重发一个请求，该请求必须携带原来的序列号（即是说，序列号不增加）。

支持RTSP的系统必须支持通过TCP承载RTSP，然后也可以支持通过UDP承载。UDP和TCP的默认RTSP端口都是554.

一定数量的发往同一个控制末端的包可以放进一个低层PDU或者封装进一个TCP流里。RTSP数据中间可以交叉插入RTP和RTCP包。和HTTP不同，一条RTSP消息只要包含载荷（payload），就必须包含内容长度头部。否则，一个RTSP包通过最后一个消息头部后的第一个空行马上截止。

10 方法定义

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-47669-17.html