《http协议1.1中文》由会员分享，可在线阅读，更多相关《http协议1.1中文（124页珍藏版）》请在金锄头文库上搜索。
1、HTTP/1.1中文版摘要超文本传输协议（HTTP）是一种为分布式，合作式，多媒体信息系统服务，面向应用层的协议。它是一种通用的，不分状态（stateless)的协议，除了诸如名称服务和分布对象管理系统之类的超文本用途外，还可以通过扩展它的请求方式，错误代码和报头来完成许多任务。HTTP的一个特点是数据表示方式的典型性和可协商性允许独立于传输数据而建立系统。在1990年WWW全球信息刚刚起步的时候HTTP就得到了应用。HTTP的第一个版本叫做HTTP/0.9,是一种为互联网原始数据传输服务的简单协议。由RFC 1945定义的HTTP/1.0进一步完善了这个协议。它允许消息以类似MIME的格式传
2、送，包括有关数据传输的维护信息和关于请求/应答的句法修正。但是，HTTP/1.0没有充分考虑到分层代理，高速缓存的作用以及对稳定连接和虚拟主机的需求。并且随着不完善的进程应用的激增，HTTP/1.0迫切需要一个新的版本,以便使两个通信应用程序能够确定彼此的真实性能。这里规定的协议叫做“HTTP/1.1.这个协议与HTTP/1.0相比，要求更为严格，以确保各项功能得到可靠实现。实际的信息系统除了简单的检索外，要求更多的功能性（functionality)，包括查找(search)，前端更新(front-end update)和注解(annotation)。HTTP允许可扩充的方法集和报头集以指示
3、请求的目的47。它是建立在统一资源标识符（URI）3提供的地址（URL）4和名字（URN）上20，以指出方法应用于哪个资源的。消息以类似于一种叫做多用途网络邮件扩展（MIME）7 的互联网邮件的格式传送。HTTP也是用于用户代理之间及代理/网关到其他网络系统的通用通信协议，这样的网络系统可能由SMTP,NNTP,FTP,Gopher和WAIS协议支持。这样，HTTP允许不同的应用程序对资源进行基本的超媒体访问。1.3 术语本说明用到了若干术语，以表示HTTP通信中各参与者和对象扮演的不同角色。连接（Connection）为通信而在两个程序间建立的传输层虚拟电路。消息(Message)HTTP通
4、信中的基本单元。它由一个结构化的八比特字节序列组成，与第4章定义的句法相匹配，并通过连接得到传送。请求(Request)一种HTTP请求消息，参看第5章的定义。应答(Response)一种HTTP应答消息，参看第6章的定义。资源(Resource)一种网络数据对象或服务，可以用第3.2节定义的URI描述。资源可以以多种表现方式（例如多种语言，数据格式，大小和解决方案）或其他不同的途径获得。实体(Entity)作为请求或应答的有效负荷而传输的信息.一个实体包含报头形式的维护信息和消息体形式的内容,由第7节详述.表示方法(Representation)一个应答包含的实体是由内容协商决定的,如第12
5、章所述.一个特定的应答状态所对应的表示方法可能有多个.内容协商(Content Negotiation)为请求服务时选择适当表示方法的机制（mechanism),如第12节所述.任何应答里实体的表示方法都是可协商的(包括出错应答).变量（Variant)在任何给定时刻,与一个资源对应的表示方法可以有一个或更多.每个表示方法称作一个变量.使用变量这个术语并不必然意味着资源是由内容协商决定的.客户机（Client）为发送请求建立连接的程序.用户代理(User agent)初始化请求的客户端程序.常见的如浏览器,编辑器,蜘蛛(网络穿越机器人),或其他的终端用户工具.服务器(Server)同意连接以便
6、通过发回应答为请求提供服务的应用程序.任何给定的程序都有可以既做客户端又做服务器;我们使用这些术语仅指特定连接中程序完成的任务,而不是指通常意义上程序的性能.同样,任何服务器都可以基于每个请求的性质扮演原服务器,代理,网管,或者隧道等诸角色之一。原服务器（Origin server)给定的资源驻留或创建的地方.代理服务器（ Proxy）一个既做服务器又做客户端的中介程序.,其用途是代表其他客户发送请求.请求在内部得到服务,或者经过一定的翻译转至其他服务器.一个代理服务器必须能同时履行本说明中客户端和服务器要求.“透明代理”（transparent proxy）是一种除了必需的验证和鉴定外不修改
7、请求或相应的代理.“非透明代理”（non-transparent proxy）是一种修改请求或应答以便为用户代理提供附加服务的代理,附加服务包括类注释服务,媒体类型转换,协议简化,或者匿名滤除等.除非经明确指出,HTTP代理要求对两种代理都适用.网关（gateway）为其他服务器充当中介的服务器.与代理服务器不同,网关接收请求,仿佛它就是被请求资源所在的原服务器;提出请求的客户可能觉察不到它正在同网关通信.一个在两个连接之间充当盲目中继（blind relay)的中间程序.一旦有效,隧道便不再被认为是HTTP通信的用户,虽然隧道可能已经被HTTP请求初始化了.当两端的中继连接都关闭的时候,隧道
8、不再存在.高速缓存（Cache）一个程序应答信息的本地存储和控制此信息存储、检索和删除的子系统,一个高速缓冲存储器存储应答为的是减少对将来同样请求的应答时间和网络带宽消耗,任一客户或服务器都可能包含一个高速缓存,但高速缓存不能应用于一个充当隧道的服务器.可缓存（Cacheable） 如果一个高速缓存允许存储应答信息的一份拷贝运用于应答后继请求的拷贝,一个应答就是可缓存的.用来确定HTTP应答的缓存能力（cacheability）的规则在13节中有定义.即使一个资源是可缓存的,也可能对一个高速缓存能否将缓存拷贝用于某特定请求存在附加的约束.直接（first-hand） 如果一个应答直接到来并且没
9、有缘于原服务器,或若干代理服务器的不必要的延时,那么这个应答就是直接的.如果它的有效性已经被原服务器直接认证,那么这个应答也同样是第一手的.明确终止时间（explicit expiration time）原服务器预算一个实体在无需进一步确认的情况下不再被高速缓存返回的时间.探索终止时间（heuristic expiration time）当没有外在的终止时间可利用时, 由高速缓存所指定的终止时间.年龄（Age） 一个应答的年龄是从它被发送,或被原服务器成功确认到现在的时间.保鲜寿命（Freshness lifetime）一个应答生成和过期之间的时间长度.保鲜（Fresh）如果一个应答的年龄还没
10、有超过保鲜寿命,它就是保鲜的.陈旧（Stale） 一个应答的年龄已经超过了它的保鲜寿命,就是陈旧的.语义透明（semantically transparent）当它的使用除了改善性能外既未影响请求客户机也未影响原服务器时, 高速缓存对于某特定的应答就是工作于语义透明方式了.当高速缓存语义透明时,客户恰好收到与原服务器直接处理请求后得到的应答（除了逐段转接的报头部分）完全相同的应答。有效性判别器（Validator） 一个用来查找一个高速缓存记录是否是一个实体的等效拷贝的协议元素(例如,一个实体标记（entity tag）或最终更改时间（Last-Modified time).上游/下游（ups
11、tream/downstream）上游和下游描述了消息的流动:所有消息都从上游流到下游.向内/向外（inbound/outbound）向内和向外指的是消息的请求和应答路径:向内即移向原服务器,向外即移向用户代理.14 总体操作HTTP协议是一种请求/应答协议。 与主机建立连接后，客户以请求方法，URI和协议版本的形式向服务器发送请求，继以类MIME信息，其中包括请求修改，客户信息和可能的正文内容。服务器用包括消息协议版本和成功或错误代码的状态进行应答，继以包括服务器信息，实体维护信息和可能的实体内容的类MIME消息。HTTP和MIME之间的关系如附录19.4节所阐述。大部分的HTTP通信由用户
12、代理引发，由应用到一些原服务器上资源的请求构成。最简单的情形，可以经用户代理（UA）和原服务器（O）之间的单一连接（v）完成。请求链-用户代理(UA)-单一连接（v)-原服务器（O） UA-v-A-v-B-v-C-v-O UA-v-A-v-B-C-O -应答链并不是所有的应答都能有效地缓存，一些请求可能含有修改量，对缓存动作有特殊的要求。缓存动作和缓存应答的HTTP要求将在第13节定义。实际上，目前万维网上有多种结构和配置的高速缓存和代理被实验或使用。这些系统包括节省越洋带宽的全国代理层，广播或多点通信缓存接口， 通过CD-ROM分配子缓存数据的机构，等等。HTTP系统应用在宽频带连接的企业局
13、域网中，通过PDAs的低耗无线连接和断续连接的访问。HTTP1.1的目标是支持各种各样的应用配置，引进协议结构满足那些需要较高可靠性，可以排除故障或至少指示故障的网络应用的要求。HTTP通信在通常发生在TCP/连接上。默认端口是TCP 80,不过其它端口也可以使用。在互联网或其他网络上，这并不妨碍HTTP应用在其他协议的顶端。http仅仅期望可靠的传输；任何提供这种保证的协议都可以使用；协议传输数据单元的HTTP/1.1请求和应答结构的映象已经超出了本说明书的范围。在http/1.0中，大部分的实现为每个请求/应答交换使用了新连接。而http/1.1中，一个连接可以用于一个或更多请求/应答交换，虽然连接可能会因为各种原因中断（见第8.1节）。3.3 日期/时间格式3.3.1 完整日期历史上的HTTP应用一直允许三种不同的表示日期/时间印记的格式:Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, u
