在HTTP之上建立RTSP和RTP的通道

使用标准的RTSP/RTP可以通过一个TCP连接将QuickTime表示以流媒体的形式发布给用户。然而这样的一个连接不足以到达处于防火墙里面，通过HTTP代理服务器间接访问英特网的私有IP网络用户。为了使流媒体到达这样的客户，QuickTime 4.1 支持将RTSP和RTP数据放置到HTTP请求和应答中进行传输，使处于防火墙里面的观众可以通过HTTP代理服务器访问QuickTime的多媒体表示。

QuickTime的HTTP传输是基于由客户端发起的HTTP GET和POST这两个不同的方法构建而成的。服务器在这个基础上绑定连接，以建立一个虚拟的全双工连接。建立这种类型的连接的协议必须满足下面的要求：

• 可以和不经修改的RTSP/RTP数据包协同工作
• 可以为HTTP代理服务器所接受
• 可以告诉代理服务器请求和回应信息并没有被缓存
• 可以在所有的请求都是由客户端发起的环境下进行工作
• 提供一种用于唯一标识请求对的方法，使得这些请求对可以被绑定在一起，从而建立全双工的连接
• 确保相关的请求可以连接到同一个RTSP服务器，无论采取何种负载均衡算法，如round-robin DNS服务器算法
• 认为所有的请求都最终会成为传递RTSP会话和RTP数据信息的通道

QuickTime的HTTP传输利用了HTTP GET和POST方法的能力，分别使这两个方法的应答和信息体中携带数量不受限制的数据。举个最简单的应用实例中，客户向服务器发送一个HTTP GET信息，请求服务器打开一个从服务器到客户端的连接；然后客户端再发送一个HTTP POST信息，请求服务器打开一个客户端到服务器端的连接。结果得到了一个虚拟全双工连接，这使得基于这个连接发送不经修改的RTSP和RTP数据成为可能。

图 1-14 建立通道必需的连接

本部分包括如下内容：

HTTP客户端请求的规定

HTTP服务器端应答的规定

RTSP请求的编码

连接的维护

对其它HTTP特性的支持

HTTP客户端请求的规定

为了和QuickTime的HTTP传输协议协同工作，客户端的HTTP请求必须：

• 基于HTTP 1.0
• 在报头中包含一个x-sessioncookie指示符，该指示符的值是一个全球唯一标识（GUID）。服务器可以将这个GUID作为一个不透明的标志传递给C连接库中的strcmp函数，从而使明确地绑定两个连接成为可能。
• 在POST请求中，必须指定Content-Type和Accept指示符的application/x-rtsp-tunneled MIME类型；这个MIME类型客户端期望和和服务器端发送的数据类型。
• 如果服务器对初始的GET请求的响应中包含x-server-ip-address指示符和IP地址，则直接将POST请求发送到指定的IP地址。

处理这些规定以外，客户端的HTTP POST请求报头可以包含其它的指示符，以帮助HTTP代理服务器处理优化处理RTSP流。

客户GET请求实例

下面是一个客户端GET请求的实例：

GET /sw.mov HTTP/1.0
    User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac8.6)
    x-sessioncookie: tD9hKgAAfB8ABCftAAAAAw 

客户POST请求实例

下面是一个客户端POST请求的实例：

POST /sw.mov HTTP/1.0
    User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac8.6)
    Content-Type: application/x-rtsp-tunnelled
    Pragma: no-cache
    Cache-Control: no-cache
    Content-Length: 32767
    Expires: Sun, 9 Jan 1972 00:00:00 GMT 

请注意：服务器端并不响应客户端的POST 请求，客户端会接着将RTSP数据作为当前POST请求的信息体发送出来。
这个客户POST请求的实例中包含三个可选的报头指示符，用于控制HTTP代理服务器的行为，使之进行恰当的处理：

• Pragma: no-cache 指示符告诉很多HTTP 1.0版本的代理服务器不要对事务进行缓存。
• Cache-Control: no-cache 指示符也是告诉很多HTTP 1.1版本的代理服务器不要缓存事务。
• Expires 指示符指定了任意一个已经过去的时间，其主要目的也是防止代理服务器对事务进行缓存。

HTTP要求所有的POST请求都需要有一个content-length报头。在上面的客户POST请求实例中，内容长度为32767，是随意给出的一个值。在实际情况中，这个值好像常常被代理服务器忽略，所以以RTSP请求的形式发送数据时，长度可能会大于这个指示符指定的值。QuickTime服务器忽略content-length报头。

HTTP服务器的中继要求

当服务器接收到来自客户端的HTTP GET请求时，必须进行应答，并在应答的报头中为Content-Type和Accept这两个指示符指定application/x-rtsp-tunneled的MIME t类型。

请注意：服务器必须对所有来自客户端的HTTP GET 请求进行应答，但是永远不要对客户端的HTTP POST请求进行应答。

服务器的应答报头中可以可选地包含Cache-Control: no-store和Pragma: no-cache这两个指示符，以防止HTTP代理服务器对事务进行缓存。业界推荐各种服务器的具体实现碰到这些报头时遵循它们的设定。

服务器集群经常通过round-robin DNS或者其它负载平衡的算法来分配连接。为了确保客户端请求能够被定向到服务器农场中的某个特定的服务器，服务器可以可选地在其对客户端初始的GET请求的应答报头中包含一个x-server-ip-address指示符，并在其后紧跟着由带点的十进制数组成的IP地址。当这个指示符存在时，客户端必须将其POST请求直接发到指定的IP地址，而不考虑DNS查找返回的IP地址是什么。

如果没有发生HTTP错误，则服务器发送包含“200 OK”的应答报头。服务器应答中的HTTP错误表示服务器无法建立虚拟的全双工连接；HTTP错误并不意味着RTSP错误。在发生HTTP错误时，服务器只是简单地关闭连接。

服务器对GET请求大应答实例

下面是一个服务器对GET请求的应答实例：

HTTP/1.0 200 OK
    Server: QTSS/2.0 [v101] MacOSX
    Connection: close
    Date: Thu, 19 Aug 1982 18:30:00 GMT
    Cache-Control: no-store
    Pragma: no-cache
    Content-Type: application/x-rtsp-tunnelled 

在应答中包含下面的这些报头指示符不是必须的，但是是推荐的，因为这些指示符告诉服务器以什么方式工作才能较好地处理处理RTSP流：

• Date指示符指定任意一个已经过去的时间，这可以防止代理服务器对事务进行缓存。
• Cache-Control: no-cache 指示符告诉很多HTTP 1.1的代理服务器不要进行事务的缓存。
• Pragma: no-cache 指示符告诉很多HTTP 1.0代理服务器不要进行事务的缓存。

RTSP请求的编码

由客户端在POST连接上发出的RTSP请求必须使用base64方法进行编码（参见RFC 2045 “英特网信息主体”，6.8部分，Base64 Content-Transfer-Encoding，以及RFC 1421 “电子邮件的隐私增强” 4.3.2.4部分，可打印的编码）。base64编码防止HTTP代理服务器将embodied RTSP请求确定为不合法的HTTP请求。

下面是一个编码前的RTSP请求实例：

DESCRIBE rtsp://tuckru.apple.com/sw.movRTSP/1.0
    CSeq: 1
    Accept: application/sdp
    Bandwidth: 1500000
    Accept-Language: en-US
    User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac8.6) 

下面是编码之后的同一个RTSP请求：

REVTQ1JJQkUgcnRzcDovL3R1Y2tydS5hcHBsZS5jb20vc3cubW92IFJUU1AvMS4w
    DQpDU2VxOiAxDQpBY2N1cHQ6IGFwcGxpY2F0aW9uL3NkcA0KQmFuZHdpZHRo0iAx
    NTAwMDAwDQpBY2N1cHQtTGFuZ3VhZ2U6IGVuLVVTDQpVc2VyLUFnZW50OiBRVFMg
    KHF0dmVyPTQuMTtjcHU9UFBDO29zPU1hYyA4LjYpDQoNCg== 

连接的维护

客户端可能在任何时候关闭POST连接。这样做可以释放服务器端的套接口和内存资源，否则这些资源可能会长时间地被使用。在QuickTime HTTP流媒体中，关闭POST连接的最好时机通常是发生在PLAY请求之后。

对其它HTTP特性的支持

对于实现HTTP之上的QuickTime RTSP和RTP通道来说，对这里没有描述的HTTP特性的支持并不是必须的。该通道应该尽可能真实地模拟正常的TCP连接，而不要添加不必要的特性。