rtsp协议 编码_udp协议_视频编码协议(17)

视为实体域。

8 实体

如不受请求方法或回应状态编码限制，请求和回应消息可传输实体，实体由实体标题域和实体主体组成，有些回应仅包括实体头。

在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。

8.1 实体标题域

实体标题定义实体主体可选元信息，如没有实体主体，指请求标识的资源。

entity-header = Allow ; Section 12.4

| 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]

与RTSP请求或回应一起发送的实体主体的式和编码信息都在实体标题域

（Entity-Header）中定义。

Entity-Body = *OCTET

实体主体只在请求方法有要求时才会被放在请求消息中。请求消息标题域处的内容长度

标题域（Content-Length header field）的标志将指明请求中的实体主体是否存在。包含实体

主体的RTSP/1.0请求必须包含合法的内容长度标题域。

对回应消息来说，消息中是否包含实体主体取决于请求方法和回应代码。所有的HEAD

请求方法的回应都不应包括主体，即便是实体标题域中指明有主体也一样。在主体中不应包

括这些回应信息，全部1xx（信息）、204（无内容）和304（未修改）。而其它的回应必须包

括实体主体或其内容长度标题（Content-Length header）域的定义为0。

9 连接

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

1、持久传输连接，用于多个请求/回应传输。

2、每个请求/回应传输一个连接。

3、无连接模式。

传输连接类型由RTSP URI来定义。对 /"rtsp/" 方案，需要持续连接；而/"rtspu/"方案，调用RTSP 请求发送，而不用建立连接。

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

9.1 流水线操作

支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出回应。

9.2 可靠性及确认

如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。 RTT在TCP中估计，初始为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始。

如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。

如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。

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