HTTP协议(RFC2616)中文版.pdf资源-CSDN文库

http

pdf

5星 · 超过95%的资源需积分: 9 116 浏览量 2014-10-12 16:16:54 上传评论 1 收藏 1.02MB PDF 举报

资源推荐

资源详情

资源评论

超文本传输协议-HTTP/1.1（修订版）

---译者：孙超进

---email：sunchaojin@163.com

说明

本文档规定了互联网社区的标准组协议，并需要讨论和建议以便更加完善。请参考

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

摘要

超文本传输协议（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 应用程序的激增，这就迫切需要一个新的版本，

以便能使两个通信程序能够确定彼此的真实能力。

此规范定义的协议叫做“HTTP/1.1”，.这个协议与 HTTP/1.0 相比，此规范更为严格，以确保

各个协议的特征得到可靠实现。

实际的信息系统除了简单的获取信息之外，还要求更多的功能，包括查找（search），终端更

新（front-end update）和注解（annotation）。HTTP 为请求提供可扩充方法集和消息头集

[47]。HTTP 是建立在统一资源标识符（URI）[3]的约束上的，作为一个地址（URL）[4]或名称

（URN）[20]，以指定被一个方法使用的资源。消息以一种类似于互联网邮件[9]消息格式来传

输的，互联网消息格式定义于多目的互联网邮件扩展（MIME）[7]里。

HTTP 也是用于用户代理（user agents）和其它互联网系统的代理/网关之间通信的通信协议，

这些互联网系统可能由 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）保存其副本，为的

是能响应后续请求。确定 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 协议是一种请求/响应型的协议。客户端给服务器发送请求的格式是一个请求方法

（request method），URI，协议版本号，然后紧接着一个包含请求修饰符（modifiers），客

户端信息，和可能的消息主体的类 MIME（MIME-like）消息。服务器对请求端发送响应的格式

是以一个状态行（status line），其后跟随一个包含服务器信息、实体元信息和可能的实体主体

内容的类 MIME（MIME-like）的消息。其中状态行（status line）包含消息的协议版本号和一

个成功或错误码。HTTP 和 MIME 之间的关系如附录 19.4 节所阐述。

大部分的 HTTP 通信是由用户代理（user agent）发起的，由应用于一个源服务器资源的请求

构成。最简单的情形，这可以通过用户代理（UA）和源服务器（O）之间的单一连接（v）来实

现。

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

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

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

有可能在请求/响应链中出现一个或多个中间者（intermediares），这是比较复杂的情形。常见

的中间者（intermediares）有三种：代理（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 的服务器，与此同

时 C 正在处理 A 的请求。

通信中任何非隧道成员都可能会采用一个内部缓存（internal cache）来处理请求。如果沿着链

的成员有请求已缓存的响应，请求/响应链就会大大缩短。下图阐明了一个最终请求响应链，假

定 B 拥有一个来自于 O（通过 C）的以前请求响应的缓存副本，并且此请求的响应并未被 UA

或 A 缓存。

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

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

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

并不是所有的响应都能有效地缓存，一些请求可能含有修饰符（modifiers），这些修饰符对缓

存动作有特殊的要求。HTTP 对缓存行为（behavior）和可缓存响应（cacheable responses）

的定义在第 13 章定义。

实际上，目前万维网上有多种被实践和部署的缓存和代理的体系结构和配置。这些系统包括节

省带宽的缓存代理（proxy cache）层次（hierarchies）系统，可以广播（broadcast）或多播

（multicast）缓存数据的系统，通过 CD-ROM 发布缓存数据子集的机构，等等。HTTP 系统

（http system）会被应用于宽带连接的企业局域网中的协作，并且可以被用于 PDAs 进行低耗

无线断续连接访问。HTTP1.1 的宗旨是为了支持各种各样的已经部署的配置，同时引进一种协

议结构，让它满足可以建立高可靠性的 web 应用程序，即使不能达到这种要求，也至少可以可

剩余104页未读，继续阅读

评论收藏

内容反馈

成都瘦西湖

2019-04-24

下下来了，翻译偶尔有点小问题，不过能感受出来，自行纠正

xieyuana1

粉丝: 0
资源: 2

HTTP协议(RFC2616)中文版.pdf

HTTP协议（RFC2616）中文版.pdf

RFC2616(HTTP协议详解)

HTTP1.1英文版+RFC2616中文版等资料汇总.zip

HTTP协议(RFC2616)中文版

RFC2616（HTTP）中文版

rfc2616中文版

rfc2616 http协议中文

rfc2616.pdf

http1.1协议rfc2616中文版

HTTP协议(RFC2616)中文版电子书.rar

RFC 2616规范 中文（谷翻）

HTTP 1.1标准RFC2616，中文版和英文版

RFC 2616 HTTP 1.1 超文本传输协议(中文版有目录) pdf

HTTP1.1协议中文版-RFC2616

HTTP协议(RFC2616)

HTTP协议(RFC2616)中文版1

最新资源

RFC 2616规范中文（谷翻）