精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
锐英源精品开源心得，转载请注明：“锐英源www.wisestudy.cn，孙老师作品，电话13803810136。”需要全文内容也请联系孙老师。
QuickTime 4.1 adds HTTP to its’ Streaming Transport capabilities. The addition of HTTP streaming allows QuickTime to utilize HTTP (RFC 1945 Hypertext Transfer Protocol 1.0 and RFC 2068 1945 Hypertext Transfer Protocol 1.1) proxies so viewers behind a firewall can access QuickTime presentations.
QuickTime 4.1增加了HTTP的流媒体传输能力。添加HTTP流允许QuickTime使用RFC 1945 HTTP(超文本传输协议1.0和RFC 2068 1945 1.1超文本传输协议)代理，所以浏览器在防火墙后面可以访问QuickTime演示。
The HTTP transport is built from two separate HTTP GET and POST requests initiated by the client. The server then binds the connections to form a virtual full-duplex connection. HTTP传输由客户端发起的两个单独的HTTP GET和POST请求建立。然后，服务器结合的连接，以形成一个虚拟全双工连接。
This paper documents the protocol used forming this type of connection, and notes implementation details associated with its use. 本文记录了协议，用于形成这种类型的连接，并指出与其使用相关的实施细则。
Using standard RTSP/RTP it is possible to stream a presentation to a user via a single TCP connection. (See RFC 2036 “Real Time Streaming Protocol (RTSP)”, section 10.12) 使用标准的RTSP和RTP可能是通过单一TCP连接向用户演示。RFC 2036(请参见“实时流协议(RTSP)”,10.12节)
Unfortunately, that is not sufficient to reach a significant population of Internet users.These users are typically on private IP networks where the client machines have indirectaccess to the public Internet via email and HTTP Proxies. 不幸的是,这并不足以达到一个重要的互联网用户的人口的要求。这些用户通常是私有IP网络环境中，客户端计算机已通过电子邮件和HTTP代理服务器直接接入公共互联网。
The QuickTime HTTP transport exploits the capability of HTTP GET and POST methods to carry an indefinite amount of data in their reply, and message body
respectively. In the most simple case, the client makes a HTTP GET request to the streaming server to open the server to client channel. Then the client makes a POST
request to the server to open the client to server channel.
QuickTime HTTP传输利用HTTP GET和POST的能力方法，在他们的回复中传递无限的数据量,并且和消息体分别。在最简单的情况下，客户端发出HTTP GET请求流媒体服务器打开服务器到客户端的通道。然后，客户端发出一个POST 请求发送到服务器以打开客户机到服务器的频道。
(HTTP GET)
|----<<<< data <<<<< ----| | - - - - - < < < < < < < < < - - - - - |数据
client -----| |---- server 客户端- - - - - - | | - - - - -服务器
|-- >>>> data >>>>-------| | - - - > > > > > > > >数据- - - - - - - |
(HTTP POST)
The virtual connection makes it possible to use unmodified RTSP over the connection. 虚拟连接使得能够通过该连接使用未修改的RTSP。
Version – All requests are made using HTTP version 1.0. Binding the Channels – Each client HTTP request must include a “x-sessioncookie” header with a Globally Unique Identifier (GUID) as it’s value. This makes it possible for the server to unambiguously bind the 2 channels. This protocol uses the value as a simple opaque token passed to the Clib 'strcmp' function.
版本—所有的请求都是使用HTTP 1.0版。渠道——每个客户端的HTTP请求必须包含一个“x-会话cookie”头有一个全局唯一标识符（GUID）作为它的值。这可能使服务器明确绑定2通道。这协议使用值作为一个简单的不透明的令牌传递给Clib'strcmp'函数。
Caching - Server replies include "Cache-Control: no-store", and client requests include the "Pragma: no-cache" as directives in the headers. These are not required by the protocol. It is recommended that implementations x-server-ip-address Header - The server may optionally include a "x-server-ip-address" followed by an IP address in dotted quad format in it's reply to the client's initial GET request. When this header is present, the client must direct its’ POST request to the stated IP address, regardless of the IP address returned via DNS lookup.
缓存——服务器回复包括“cache - control:no-store”,和客户端请求包括“Pragma:no - cache”开头指令。这些都不是所要求的协议。建议实现x-server-ip-address——服务器可以选择包括一个“x-server-ip-address”后跟一个IP地址在虚线四格式回复客户的最初GET请求。这个开头存在时,客户端必须直接“POST请求的IP地址,不用管DNS查询返回的IP地址。
This insures that both requests will connect to the same server among potentially several servers in a server farm. Many times these server clusters will be allocated connections via a round robin DNS or other load balancing algorithms. 这确保请求将连接到相同的服务器中潜在的多个服务器之间的服务器群。很多时候这些服务器群将通过一个循环DNS或其它负载平衡算法分配连接。
Meaning of HTTP errors in replies - HTTP errors reflect the unwillingness or inability of the server to form the virtual full duplex connection. They do not imply RTSP errors. In general, the server will always reply with “200 OK”, and simply close the connection if problems occur. The POST request is never replied to by the server Request Identification QuickTime Streaming uses the 'application/x-rtsp-tunnelled' MIME type in both the Content-Type and Accept headers. This reflects the data type that is expected and delivered by the client and server.
HTTP错误回复- HTTP错误反映服务器不愿或不能形成虚拟全双工连接。他们并不意味着RTSP错误。在一般情况下，服务器将总是用“200 OK”答复，并在发生问题时简单地关闭连接。POST请求永远不会被请求鉴定QuickTime Streaming服务器答复，这类POST请求使用'application/x-rtsp-tunnelled“MIME类型，在两个Content-Type和Accept标头成员里都用了此类型。这反映了预期,由客户端和服务器下发的数据类型。
The RTSP requests made by the client on the POST channel must be encoded using the base64 method. (See RFC 2045 “Internet Message Bodies”, section 6.8 Base64 Content-Transfer-Encoding; and RFC 1421 “Privacy Enhancement for Electronic Mail,” section 4.3.2.4, Printable Encoding) 在POST通道上的RTSP客户请求必须使用base64编码的方法。RFC 2045(请参阅“互联网消息体”,6.8节内容——Base64传输编码,RFC 1421“隐私增强电子邮件,”部分4.3.2.4打印编码)
The base64 encoding prevents HTTP proxies from mistaking the embodied RTSP requests as malformed HTTP requests. Our testing revealed that some HTTP proxies did in fact fail to pass the raw RTSP data properly. base64编码可以防止HTTP代理把RTSP请求体现为畸形的HTTP请求。我们的测试显示，一些HTTP代理在事实上无法正常通过原始数据RTSP。
There is no reponse from the server! The client will continue to send RTSP as the message body of this POST request. The chosen Content-Length of 32767 is an arbitrarily large value. All POST requests are required to have a contentlength header by HTTP. In practice the actual value seems to be ignored by proxy servers, so it is possible to send more than this amount of data in the form of RTSP requests. The QuickTime Server ignores the content-length header.
服务器没有响应!客户机将POST作为一个消息体继续发送RTSP请求。所选的内容长度为32767，一个无限大的值。所有POST请求都必须通过HTTP有一个内容长度。在实践中似乎忽视了实际的代理服务器价值,所以它可以发送比RTSP的请求更多数量的数据形式。QuickTime服务器忽略了内容长度。
The client may at its’ option close the POST connection at any given time. Doing so frees socket and memory resources at the server that might otherwise be unused for a long time. In QuickTime Streaming the best time for this usually occurs after the PLAY request.
客户端可以在其“选项关闭在任何给定时间内的POST连接。闲置很长一段时间后，服务器可以释放插座和内存资源。这通常在QuickTime播放请求后最佳的时间发生,。
This section covers details that are not required by the protocol, but communicate important information to proxies so that they handle the streams better. 本节讨论协议不需要的细节,但传达给代理的重要信息，以便他们更好地处理流。
Date Header – In QuickTime streaming, the GET reply includes a “Date” headers with a value at an arbitrary point in the past. This keeps proxies from caching the transaction. 日期标题——在QuickTime播放,GET回复包括在过去的任意点的值的“日期”的标题。这可以防止代理缓存事务。
Expires Header – Same as the Date header. Expires标题,—同日期标题。
Pragma “No cache” - Tells many HTTP 1.0 proxies not to cache. 编译“不缓存” - 告诉很多HTTP 1.0代理服务器不缓存。
Cache-Control “no-cache” – Tells HTTP 1.1 proxies not to cache. 告诉HTTP 1.1代理不要缓存。
Support for HTTP features not documented here is not required for RTSP tunneling. HTTP tunnel should mimic a normal TCP connection as closely as possible without adding unnecessary features.
不需要RTSP对此处未记录的HTTP功能的支持。 HTTP应尽可能地模仿正常的TCP连接而不会增加不必要的功能。