http1.1中文手册

4星 · 超过85%的资源需积分: 14 115 浏览量更新于2023-03-03 评论 1 收藏 665KB DOC 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

Network Working Group(网络工作组) R. Fielding

Request for Comments: 2616 UC Irvine

Obsoletes(过时弃用）: 2068 J. Gettys

Category: Standards Track （类别:标准组）

Compaq/W3C

J. Mogul

Compaq

H. Frystyk

W3C/MIT

L. Masinter

Xerox

P. Leach

Microsoft

T. Berners-Lee

W3C/MIT

June 1999

超文本传输协议-HTTP/1.1

说明

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

“互联网官方协议标准”（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 相比，要求更为严格，以

确保各项功能得到可靠实现。

实际的信息系统除了简单的检索外，要求更多的功能性 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)

作为请求或应答的有效负荷而传输的信息.一个实体包含报头形式的维护信息和消息体形式的

内容,由第 7 节详述.

表示方法(Representation)

一个应答包含的实体是由内容协商决定的,如第 12 章所述.一个特定的应答状态所对应的表示方

法可能有多个.

内容协商(Content Negotiation)

为请求服务时选择适当表示方法的机制（mechanism),如第 12 节所述.任何应答里实体的表示方

法都是可协商的(包括出错应答).

变量（Variant)

在任何给定时刻,与一个资源对应的表示方法可以有一个或更多.每个表示方法称作一个变量.使

用变量这个术语并不必然意味着资源是由内容协商决定的.

客户机（Client）

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

用户代理(User agent)

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

具.

服务器(Server)

同意连接以便通过发回应答为请求提供服务的应用程序.任何给定的程序都有可以既做客户端

又做服务器;我们使用这些术语仅指特定连接中程序完成的任务,而不是指通常意义上程序的性

能.同样,任何服务器都可以基于每个请求的性质扮演原服务器,代理,网管,或者隧道等诸角色之

一。

原服务器（Origin server)

给定的资源驻留或创建的地方.

代理服务器（ Proxy）

一个既做服务器又做客户端的中介程序.,其用途是代表其他客户发送请求.请求在内部得到服务,

或者经过一定的翻译转至其他服务器.一个代理服务器必须能同时履行本说明中客户端和服务

器要求.“透明代理”（transparent proxy）是一种除了必需的验证和鉴定外不修改请求或相应的代

理.“非透明代理”（non-transparent proxy）是一种修改请求或应答以便为用户代理提供附加服务

的代理,附加服务包括类注释服务,媒体类型转换,协议简化,或者匿名滤除等.除非经明确指

出,HTTP 代理要求对两种代理都适用.

网关（gateway）

为其他服务器充当中介的服务器.与代理服务器不同,网关接收请求,仿佛它就是被请求资源所在

的原服务器;提出请求的客户可能觉察不到它正在同网关通信.

一个在两个连接之间充当盲目中继（blind relay)的中间程序.一旦有效,隧道便不再被认为是

HTTP 通信的用户,虽然隧道可能已经被 HTTP 请求初始化了.当两端的中继连接都关闭的时候,

隧道不再存在.

高速缓存（Cache）

一个程序应答信息的本地存储和控制此信息存储、检索和删除的子系统,一个高速缓冲存储器

存储应答为的是减少对将来同样请求的应答时间和网络带宽消耗,任一客户或服务器都可能包

含一个高速缓存,但高速缓存不能应用于一个充当隧道的服务器.

可缓存（Cacheable）

如果一个高速缓存允许存储应答信息的一份拷贝运用于应答后继请求的拷贝,一个应答就是可

缓存的.用来确定 HTTP 应答的缓存能力（cacheability）的规则在 13 节中有定义.即使一个资源

是可缓存的,也可能对一个高速缓存能否将缓存拷贝用于某特定请求存在附加的约束.

直接（first-hand）

如果一个应答直接到来并且没有缘于原服务器,或若干代理服务器的不必要的延时,那么这个应

答就是直接的.如果它的有效性已经被原服务器直接认证,那么这个应答也同样是第一手的.

明确终止时间（explicit expiration time）

原服务器预算一个实体在无需进一步确认的情况下不再被高速缓存返回的时间.

探索终止时间（heuristic expiration time）

当没有外在的终止时间可利用时, 由高速缓存所指定的终止时间.

年龄（Age）

一个应答的年龄是从它被发送,或被原服务器成功确认到现在的时间.

保鲜寿命（Freshness lifetime）

一个应答生成和过期之间的时间长度.

保鲜（Fresh）

如果一个应答的年龄还没有超过保鲜寿命,它就是保鲜的.

陈旧（Stale）

一个应答的年龄已经超过了它的保鲜寿命,就是陈旧的.

语义透明（semantically transparent）

当它的使用除了改善性能外既未影响请求客户机也未影响原服务器时, 高速缓存对于某特定的

应答就是工作于语义透明方式了.当高速缓存语义透明时,客户恰好收到与原服务器直接处理请

求后得到的应答（除了逐段转接的报头部分）完全相同的应答。

有效性判别器（Validator）

一个用来查找一个高速缓存记录是否是一个实体的等效拷贝的协议元素(例如,一个实体标记

（entity tag）或最终更改时间（Last-Modified time)).

上游/下游（upstream/downstream）

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

向内/向外（inbound/outbound）

向内和向外指的是消息的请求和应答路径:"向内"即"移向原服务器","向外"即"移向用户代理".

1。4 总体操作

HTTP 协议是一种请求/应答协议。与主机建立连接后，客户以请求方法，URI 和协议版

本的形式向服务器发送请求，继以类 MIME 信息，其中包括请求修改，客户信息和可能的

正文内容。

服务器用包括消息协议版本和成功或错误代码的状态进行应答，继以包括服务器信息，实

体维护信息和可能的实体内容的类 MIME 消息。HTTP 和 MIME 之间的关系如附录 19.4

节所阐述。

大部分的 HTTP 通信由用户代理引发，由应用到一些原服务器上资源的请求构成。最简单

的情形，可以经用户代理（UA）和原服务器（O）之间的单一连接（v）完成。请求

链------------------------>用户代理(UA)-------------------单一连接（v)-------------------原服

务器（O） <-----------------------应答链

当一个或一个以上的中介在请求/应答链中出现的时候，会出现更复杂的情形。常见的中介

形式有三种：代理，网关和隧道。代理是一种转送工具，它接收绝对形式的 URI 请求，重

写全部或部分消息，然后把重新格式化后的请求发送到 URI 确定的服务器上。网关是一种

接收工具，它充当其他服务器的上层，必要时将请求翻译为下层服务器的协议。隧道不改

变消息而充当两个连接之间的中继点；它用于通信需要穿过中介（如防火墙），甚至中介

不能理解信息内容的时候。

请求链-------------------------------------->UA-----v-----A-----v-----B-----v-----C-----v-----O

<-------------------------------------应答链

上图显示了用户代理和原服务器之间的三个中介（A，B 和 C)。游历整条链的请求或应答

消息需通过四个独立的连接。这个特性很重要，因为某些 HTTP 通信选项只能应用于到最

近的非隧道邻居，链的终点的连接，或者沿着链的所有连接。图表尽管是线性的，每部分

可能都在忙于多路同时通信。例如，B 可以接收来自不同于 A 的许多客户的请求，并且／

或者转送到不同于 C 的服务器，与此同时，它还在处理 A 的请求。

任何非隧道的通信成员都可以使用内部的高速缓存来处理请求。高速缓存的作用是如果沿

着链的一个成员对请求采用了高速缓冲的应答，请求/应答链就会大大缩短。以下图解作

为结果产生的链，假定 B 拥有来自 O（通过 C）的一个从前应答的备份，请求尚未被 UA

或 A 缓存。

请求链---------->UA-----v----------A-----v-----B-----C----O <---------应答链

并不是所有的应答都能有效地缓存，一些请求可能含有修改量，对缓存动作有特殊的要求。

缓存动作和缓存应答的 HTTP 要求将在第 13 节定义。实际上，目前万维网上有多种结构

和配置的高速缓存和代理被实验或使用。这些系统包括节省越洋带宽的全国代理层，广播

或多点通信缓存接口，通过 CD-ROM 分配子缓存数据的机构，等等。HTTP 系统应用在

宽频带连接的企业局域网中，通过 PDAs 的低耗无线连接和断续连接的访问。HTTP1.1

的目标是支持各种各样的应用配置，引进协议结构满足那些需要较高可靠性，可以排除故

障或至少指示故障的网络应用的要求。

HTTP 通信在通常发生在 TCP/ＩＰ连接上。默认端口是 TCP 80,不过其它端口也可以使用。

在互联网或其他网络上，这并不妨碍 HTTP 应用在其他协议的顶端。http 仅仅期望可靠的

传输；任何提供这种保证的协议都可以使用；协议传输数据单元的 HTTP/1.1 请求和应答

结构的映象已经超出了本说明书的范围。

在 http/1.0 中，大部分的实现为每个请求/应答交换使用了新连接。而 http/1.1 中，一个

连接可以用于一个或更多请求/应答交换，虽然连接可能会因为各种原因中断（见第 8.1

节）。

2 符号惯例和一般语法

2．1 扩充 BNF

本文档规定的所有机制都用两种方法描述：散文体（prose)和类似于 RFC 822 的扩充 Backus-

Naur Form(BNF)。要理解本说明书，使用者需熟悉符号表示法。扩充 BNF 包括下列结构：

名字=定义

一条规则的名字仅仅是名字本身（没有任何"<"和">"）,跟等于号"="后面的定义是分离的。仅

当连续线的空格用来表示一条长于一行的规则时空白才是重要的。某些基本规则使用大写字母，

如 SP，LWS，HT，CRLF，DIGIT，ALPHA，等等。无论何时，只要它们的存在有利于识别

规则名字，就可以在定义的范围内使用角括号。

“文字”

文字原文使用引号。除特殊情况，原文对外界不敏感。

规则 1 | 规则 2

剩余63页未读，继续阅读

youhan_wen

2015-09-09

内容挺全的

nathena

粉丝: 3
资源: 21

会员权益专享

http1.1中文手册

评论2

会员权益专享

最新资源

http1.1中文手册

评论2

HTTP 1.1.chm

HTTP权威手册pdf版本

HTTP/http协议中文手册

http1.1 网络模型

http1.0和http1.1的区别

HTTP2.0和http1.1有什么区别

nginx1.19.6支持http1.1吗

简述 HTTP1.0 和 HTTP1.1协议区州。

http1.1与http2.0协议区别

在 Curl 命令中指定使用较旧的协议版本，例如使用 --http1.1 参数来强制使用 HTTP/1.1 协议

HTTP1.1、HTTP2和HTTP3是HTTP协议的三个版本——相同点和不同点

6sv1.1大气校正手册

http1.1 和 http2 动画示例

http1.0和http1.1的差别

http1.1和http1.0的区别

http1.0,http1.1,http1.2有什么区别

Apache 怎么设置 http1.1协议

http1.1和http2.0的区别

Http1.1的请求方法

http1.1 和 http2 区别，用动画方式体现他们加载时间

会员权益专享

最新资源