Http1.1协议详解

“互联网官方协议标准”（STD 1）来了解本协议的标准化状态。本协议不限流传发布。

版权声明

   Copyright （C） The Internet Society （1999）.   All Rights Reserved.

摘要

超文本传输协议（HTTP）是一种为分布式，合作式，超媒体信息系统。它是一种通用的，无状态（stateless）的协议，除了应用于超文本传输外，它也可以应用于诸如名称服务器和分布对象管理系统之类的系统，这可以通过扩展它的请求方法，错误代码和报头[47]来实现。HTTP的一个特点是数据表现形式是可输入的和可协商性的，这就允许系统能被建立而独立于数据传输。

 

HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。本说明书详细阐述了HTTP/1.1 协议，是RFC 2068的修订版[33]。

目录（略）

1 引论
1.1 目的
超文本传输协议（HTTP）是一种为分布式，合作式，多媒体信息系统服务，面向应用层的 协议。在1990年WWW全球信息刚刚起步的时候HTTP就得到了应用。HTTP的第一个版本叫做HTTP/0.9,是一种为互联网原始数据传输服务的简单协议。由RFC 1945[6]定义的HTTP/1.0进一步完善了这个协议。它允许消息以类似MIME的格式传送，包括有关数据传输的维护信息和关于请求/响应的句法修正。但是，HTTP/1.0没有充分考虑到分层代理，缓存的作用以及对稳定连接和虚拟主机的需求。并且随着不完善的应用程序的激增，HTTP/1.0迫切需要一个新的版本,以便使两个通信应用程序能够确定彼此的真实性能。

这里规定的协议叫做擧TTP/1.1".这个协议与HTTP/1.0相比，要求更为严格，以确保各项功能得到可靠实现。

实际的信息系统除了简单的检索外，要求更多的功能性（functionality），包括查找（search），前端更新（front-end update）和注解（annotation）。HTTP允许可扩充的方法集和报头集以指示请求的目的[47]。它是建立在统一资源标识符（URI）[3]提供的地址（URL）[4]和名字（URN）上[20]，以指出方法应用于哪个资源的。消息以类似于一种叫做多用途网络邮件扩展（MIME）[7] 的互联网邮件的格式传送。

HTTP也是用于用户代理之间及代理/网关到其他网络系统的通用通信协议，这样的网络系统可能由SMTP[16],NNTP[13],FTP[18],Gopher[2]和WAIS[10]协议支持。这样，HTTP允许不同的应用程序对资源进行基本的超媒体访问。

1.2 要求
本文的关键词"MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL"将由RFC 2119[34]解释。

一个应用程序如果不能满足协议提供的一个或多个MUST或REQUIRED等级的要求，是不符合要求的。一个应用程序如果满足所有MUST或REQUIRED等级以及所有SHOULD等级的要求，则被称为非条件遵循（unconditionally compliant）的；若满足所有MUST等级的要求但不能满足所有SHOULD等级的要求则被称为条件遵循的（conditionally compliant）。

1.3 术语
本说明用到了若干术语，以表示HTTP通信中各参与者和对象扮演的不同角色。

连接（connection）

为通信而在两个程序间建立的传输层虚拟电路。

消息（message）

HTTP通信中的基本单元。它由一个结构化的八比特字节序列组成，与第4章定义的句法相匹配，并通过连接得到传送。

请求（request）

一种HTTP请求消息，参看第5章的定义。

响应（response）

一种HTTP响应消息，参看第6章的定义。

资源（resource）

一种网络数据对象或服务，可以用第3.2节定义的URI指定。资源可以以多种表现方式（例如多种语言，数据格式，大小和分辨率）或者根据其它方面而而不同的表现形式。

实体（entity）

实体是请求或响应的有效承载信息。一个实体包含元信息和内容，元信息以实体头域（entity-header field）形式表示，内容以消息主体（entity-body）形式表示。在第7节详述。

表现形式 （representation）

一个响应包含的实体是由内容协商（content negotiation）决定的。如第12章所述。有可能存在一个特定的响应状态码对应多个表现形式。

内容协商（content negotiation）

当服务一个请求时选择资源的一种适当的表示形式的机制（mechanism），如第12节所述。任何响应里实体的表现形式都是可协商的（包括出错响应）.

变量（variant）

在任何给定时刻，一个资源对应的表现形式（representation）可以有一个或多个（译注：一个URI请一个资源，但返回的是此资源对应的表现形式，这根据内容协商决定）。每个表现形式（representation）被称作一个变量。使用变量这个术语并不是意味着资源（resource）是必须由内容协商决定的.

客户端（client）

为发送请求建立连接的程序.

用户代理（user agent）

初始化请求的客户端程序。常见的如浏览器,编辑器,蜘蛛（网络穿越机器人）,或其他的终端用户工具.

服务器（Server）

服务器是这样一个应用程序，它同意请求端的连接，并发送响应（response）。任何给定的程序都有可能既做客户端又做服务器；我们使用这些术语是为了说明特定连接中应用程序所担当的角色，而不是指通常意义上应用程序的能力。同样，任何服务器都可以基于每个请求的性质扮演源服务器，代理，网关，或者隧道等角色之一。

源服务器（Origin server）

存在资源或者资源在其上被创建的服务器（server）被成为源服务器（origin server）。 

代理（ Proxy）

代理是一个中间程序，它既担当客户端的角色也担当服务器的角色。代理代表客户端向服务器发送请求。客户端的请求经过代理，会在代理内部得到服务或者经过一定的转换转至其他服务器。一个代理必须能同时实现本规范中对客户端和服务器所作的要求。透明代理（transparent proxy）需要代理授权和代理识别，但不修改请求或响应。非透明代理（non-transparent  proxy）需修改请求或响应，以便为用户代理（user agent）提供附加服务，附加服务包括组注释服务，媒体类型转换，协议简化，或者匿名过滤等。除非透明行为或非透明行为经明确指出，否则，HTTP代理既是透明代理也是非透明代理。

网关（gateway）

网关其实是一个服务器，扮演着代表其它服务器为客户端提供服务的中间者。与代理（proxy）不同，网关接收请求，仿佛它就是请求资源的源服务器。请求的客户端可能觉察不到它正在同网关通信。

隧道（tunnel）

隧道也是一个中间程序，它一个在两个连接之间充当盲目中继（blind relay）的中间程序。一旦隧道处于活动状态，它不能被认为是这次HTTP通信的参与者，虽然HTTP请求可能已经把它初始化了。当两端的中继连接都关闭的时候，隧道不再存在。

缓存（cache）

缓存是程序响应消息的本地存储。缓存是一个子系统，控制消息的存储、取回和删除。缓存里存放可缓存响应（cacheable response）为的是减少对将来同样请求的响应时间和网络带宽消耗。任一客户端或服务器都可能含有缓存，但高速缓存不能被一个充当隧道（tunnel）的服务器使用。

可缓存（cacheable）

我们可以说响应（response）是可缓存的，如果一个缓存（cache）为了响应后继请求而被允许存储响应消息（response message）的副本。确定HTTP响应的缓存能力（cacheability）在13节中有介绍。即使一个资源（resourse）是可缓存的，也可能存在缓存是否能利用缓存副本的约束。

第一手的（first-hand）

如果一个响应直接从源服务器或经过若干代理（proxy），并且没有不必要的延时，最后到达客户端，那么这个响应就是第一手的（first-hand）。

如果响应被源服务器（origin server）验证是有效性（validity）的，那么这个响应也同样是第一手的。

明确过期时间（explicit expiration time）     

是源服务器希望实体（entity）如果没有被进一步验证（validation）就不要再被缓存（cache）返回的时间。

启发式过期时间（heuristic expiration time）      

当没有明确终止时间（explicit expiration time）可利用时，由缓存所指定的终止时间.

年龄（age）

一个响应的年龄是从被源服务器发送或被源服务器成功确认的时间点到现在的时间。

保鲜寿命（freshness lifetime）

一个响应产生的时间点到过期时间点之间的长度。

保鲜（Fresh）    

如果一个响应的年龄还没有超过保鲜寿命（freshness lifetime），它就是保鲜的.

陈旧（Stale）

一个响应的年龄已经超过了它的保鲜寿命（freshness lifetime），就是陈旧的.

语义透明（semantically transparent）

缓存（cache）可能会以一种语意透明（semantically transparent）的方式工作。这时，对于一个特定的响应，使用缓存既不会对请求客户端产生影响也不会对源服务器产生影响，缓存的使用只是为了提高性能。当缓存（cache）具有语意透明性时，客户端从缓存接收的响应跟直接从源服务器接收的响应完全一致（除了使用hop-by-hop头域）。

验证器（Validator）

验证器其实是协议元素（例如：实体头（entity tag）或最后更改时间（last-modified time）等），这些协议元素被用于识别缓存里保存的数据（即缓存项）是否是源服务器的实体的副本。

上游/下游（upstream/downstream）

上游和下游描述了消息的流动:所有消息都从上游流到下游.

向内/向外（inbound/outbound）

向内和向外指的是消息的请求和响应路径:"向内"即"移向源服务器","向外"即"移向用户代理（user agent）".

1.4 总体操作
HTTP协议是一种请求/响应协议。 与服务器建立连接后，客户端以请求方法，URI和协议版本号，然后紧接着跟随一个类MIME（MIME-like）消息，这个类MIME消息包括请求修饰符，客户信息和可能的消息主体。服务器以一个状态行并跟随一个类MIME（MIME-like）消息响应，状态行包含消息的协议版本和成功出错的状态码，类MIME消息包含服务器信息，实体元信息，和可能的实体。HTTP和MIME之间的关系如附录19.4节所阐述。

大部分的HTTP通信是由用户代理（user agent）开始的，由应用到一个需要源服务器资源的请求构成。最简单的情形，可以经用户代理（UA）和源服务器（O）之间的单一连接（v）完成。

请求链（Request chain）--------------------- ----------à

用户代理（UA）----------------单一连接（v）--------------源服务器（O）

<---------------------------------------响应链（response chain）

当一个或多个中间者在请求/响应链中出现的时候，会出现更复杂的情形。常见的中间者有三种：代理（proxy），网关（gateway）和隧道（tunnel）。代理（proxy）是一种转发代理（a  forwarding  agent），它接收绝对URI（absoulute url，相对于相对url）请求，重写全部或部分消息，然后把格式化后的请求发送到URI指定的服务器上。网关是一种接收代理（receiving agent），它充当一个层（layer），这个层在服务器之上，必要时它会把请求翻译成为下层服务器的协议。隧道不改变消息而充当两个连接之间的中继点；它用于通信需要穿过中间者（如防火墙）甚至当中间者不能理解消息内容的时候。

请求链（request chain）----------------------------------------à

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

 <----------------------------------------响应链（response chain）

上图显示了用户代理（user agent）和源服务器之间的三个中间者（A，B和C）。整条链的请求或响应将会通过四个单独的连接。这个特性很重要，因为某些HTTP通信选项可能只能应用于与最近的非隧道邻接点的连接，只能应用于链的端点（end-point）的连接，或者能应用于此链的所有连接。图表尽管是线性的，每个参与者可能忙于多路同时通信。例如，B可以接收来自不同于A的许多客户的请求，并且／或者可以把请求转到不同于C的服务器，与此同时，它还在处理A的请求。

任何非隧道的通信成员都可能会采用一个内部缓存（cache）来处理请求。如果沿着链的通信成员对请求采用了缓存响应，请求/响应链就会大大缩短。下图阐明了一个最终请求响应链，这是在假定B拥有一个来自O（通过C）的以前请求的响应副本，但此响应尚未被UA或A缓存。

请求链（request chain）---------->

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

<---------响应链 （response chain）

并不是所有的响应都能有效地缓存，一些请求可能含有修饰符，这些修饰符对缓存动作有特殊的要求。缓存动作和缓存响应的HTTP行为要求将在第13节定义。

实际上，目前万维网上有多种结构和配置的缓存（cache）和代理（proxy）正在被使用。这些系统包括节省带宽的缓存代理（proxy cache），可以广播或多点传送缓存数据的系统，通过CD-ROM分配缓存数据子集的机构，等等。HTTP系统（http system）会被应用于宽带连接的企业局域网中的协作，并且可以通过PDA进行低耗无线的，断续连接的访问。HTTP1.1的宗旨是为了支持各种各样的已经部署的配置，同时引进一种协议结构，让它满足那些需要较高可靠性，即使不能达到较高可靠性的要求，也要也让它至少可以指示故障的网络应用的要求。

HTTP通信通常发生在TCP/IP连接上。默认端口是TCP 80，不过其它端口也可以使用。这并不妨碍HTTP的实现被应用于互联网（internt）或其它网的协议之上。Http仅仅期望的是一个可靠的传输（译注：HTTP一般建立在传输层协议之上）；任何提供这种保证的协议都可以被使用；协议传输数据单元（transport data unit）与HTTP/1.1请求和响应的消息结构之间的映象已经超出了本说明书的范围。

大部分HTTP/1.0的实现都是针对每个请求/响应交换产生一个新的连接。而http/1.1中，一个连接可以被用于一个或更多请求/响应交换，虽然连接可能会因为各种原因中断（见第8.1节）。

 

完整下载见附件