RFC1945(HTTP)中文版(6)

HTTP是应用级协议,它适应了分布式超媒体协作系统对灵活性及速度的要求。它是一个一般的、无状态的、基于对象的协议,通过对其请求方法(request methods)进行扩展,可以被用于多种用途,比如命名服务器(name server)及分布式对象管理系统。 HTTP 的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。 HTTP 自从 1990 年就在 WWW 上被广泛使用。该规范反映了“HTTP/1.0”的普通用

1.3 概述（Overall Operation）

HTTP协议是基于请求/回应机制的。客户端与服务器端建立连接后，以请求方法、URI、协议版本等方式向服务器端发出请求，该请求可跟随包含请求修饰符、客户信息、及可能的请求体（body）内容的MIME类型消息。

服务器端通过状态队列（status line）来回应，内容包括消息的协议版本、成功或错误代码，也跟随着包含服务器信息、实体元信息及实体内容的MIME类型消息。

绝大多数HTTP通讯由用户代理进行初始化，并通过它来组装请求以获取存储在一些原始服务器上的资源。在最简单的情况下，通过用户代理（UA）与原始服务器（O）之间一个简单的连接（v）就可以完成。

request chain ------------------------>

UA -------------------v------------------- O

<----------------------- response chain

更复杂的情况是当请求/回应链之间存在一个或更多中间环节。总体看来，有三种中间环节：代理（proxy）、网关（gateway）、隧道（tunnel）。代理（proxy）是向前推送的代理人（agent），它以绝对形式接收URI请求，重写全部或部分消息，并将经过改写的请求继续向URI中指定的服务器处推送。网关是接收代理，它处于服务器层之上，在必要时候，它用服务器可识别的协议来传递请求。隧道不改变消息，它只是连接两端的中继点。在有中间层（如防火墙）或中间层无法解析消息内容的情况下，需要靠隧道技术来帮助通讯穿越中间层。 request chain -------------------------------------->

UA -----v----- A -----v----- B -----v----- C -----v----- O

<------------------------------------- response chain

上面的图形表示在用户代理和原始服务器之间有三个中间层（A，B和C）。由图可见，请求或回应消息在整个信息链上运行需要通过四个单独的连接，它与在此之前介绍的简单情况是有区别的，而且此区别是十分重要的。因为HTTP通讯选项可以设置成几种情况，如只与最近的非隧道邻居连接、只与信息链末端连接、或者可与链中全部环节连接等等。虽然上面的图是线性的，而实际上每个参与环节都在同时与多方进行通讯活动。例如，B在接受除A之外其它客户端请求的同时，向除C之外的其它服务器推送请求，在这个时刻，它可能接受到A的请求，并给予处理。

参与通讯的任何一方如果没有以隧道方式进行工作，必须要借助内部缓存机制来处理请求，如果链上某个参与方碰巧缓存了某个请求的回应，那就相应于缩短了请求/回应链。下面的图例演示了当B缓存了从O经由C过来的回应信息，而UA和A没缓存的情况： request chain ---------->

UA -----v----- A -----v----- B - - - - - - C - - - - - - O

<--------- response chain

并非所有的回应都可以被缓存，某些请求所包含的修饰符中可能对缓存行为进行了特别指明。一些基于HTTP/1.0的应用使用了启发式的方法来描述哪些回应可被缓存，而哪些则不可以，但遗憾的是，这些规则并没有形成标准。

在Internet上，HTTP通讯往往基于TCP/IP的连接方式。缺省的端口是TCP 80[15]口，但也可以使用其它端口。并不排除基于Ineternet上的其它协议或网络协议的HTTP实现方式，HTTP只是假定传输是可靠的，因而任何能提供这种保证的协议都可以被使用。至于HTTP/1.0请求和回应在数据传输过程中的数据结构问题，不在本文讨论范围之内。

实验室应用除外，当前的做法是客户端在每次请求之前建立连接，而服务器端在发送回