超文本传输协定

HTTP在客户端-服务器计算模型中用作请求-响应协议。例如，客户端可以是一个网络浏览器，服务器可能是一个运行在计算机上，作为一个网站主机的应用程序。客户端向服务器提交一个HTTP请求消息。服务器提供诸如HTML文件和其他内容的资源，或者代表客户端执行其他功能，向客户端返回一个响应信息。这一响应包含关于请求的完成状态信息，也可能在其消息正文中包含请求的内容。

网络浏览器是用户代理(UA)的一个实例。其他类型的用户代理包括搜索提供商（网络爬虫），语音浏览器，移动应用和访问、使用或显示网络内容的其他软件所使用的索引软件。

HTTP旨在允许中间网络元素改进或支持客户端和服务器之间的通信。高流量网站通常受益于代表上游服务器提供内容的web缓存服务器以缩短响应时间。网络浏览器缓存先前访问的网络资源，并尽可能重用它们以减少网络流量。通过与外部服务器中继消息，专用网边界的HTTP代理服务系统可以在没有全局可路由地址的情况下促进客户端的通信。

HTTP是一个在互联网协议套件框架内设计的协议的应用层协议。它的定义假定存在一个潜在的和可靠的传输层协议，^[6]并且传输控制协议(TCP)是常被用到的。但是，可以修改HTTP来使用例如用户数据报协议(UDP)不可靠的协议，比如在HTTPU和简单服务发现协议(SSDP)中。

使用统一资源标识符（URI）方案http和https，HTTP资源由统一资源定位符(URLs)在网络被识别与定位。例如，包括所有可选组件:

            userinfo                  
        ┌───────┴───────┐ ┌────┴────────┐ ┌┴┐
 http://john.doe:password@www.example.com:123/forum/questions/?tag=networking&order=newest#top
 └─┬─┘ └───────────┬────────────────────────┘└─┬─────────────┘└────────┬──────────────────┘└┬─┘
          authority                      path                               







URI被编码为文件中的，以便形成相互链接文件。HTTP/1.1是对初始HTTP(HTTP/1.0)的修订。在HTTP/1.0中，对于每个资源请求都是建立到同一个服务器的一个单独连接。HTTP/1.1可以在获得页面后，多次重复使用一个连接来下载图像，脚本,样式表,等等。因此，当建立TCP连接会带来相当大的开销时，HTTP/1.1通信经历的延迟却越短。

超文本这一术语是由泰德·纳尔逊在1965年Xanadu项目中提出的。这又受到了万尼瓦尔·布什20世纪30年代关于基于缩微胶片的信息检索和管理系统"memex"，该系统在他1945年的文章"As We May Think"中有所描述。蒂姆·伯纳斯·李和他在欧洲核子研究中心的团队被认为发明了最初的HTTP，以及HTML和与网页服务器和基于文本的网页浏览器相关的技术。伯纳斯-李在1989年首次提出了“WorldWideWeb”项目——现在被称为万维网。该协议的第一个版本只有一种方法，即GET，它会向服务器请求一个页面。^[7]服务器的响应总是一个HTML页面。^[8]

第一个记录在案的HTTP版本是HTTP V0.9(1991年)。Dave Raggett于1995年领导了HTTP工作组（HTTP WG），希望通过扩展操作、扩展协商、更丰富的元信息来扩展协议，并与通过添加额外方法和头字段。^[9][10]RFC 1945于1996年正式推出并发布了HTTP 1.0版。

该工作组计划在1995年12月发布新的标准^[11]并且对基于当时正处于开发中的RFC 2068(称为HTTP-NG)所开发的预先标准化的HTTP/1.1的支持在1996年初被主流浏览器开发者迅速采用。到那年3月，在Arena浏览器,^[12]网景导航者2.0,^[12]网景导航者黄金版2.01，^[12]Mosaic浏览器2.7,Lynx浏览器2.5,和Internet Explorer 2.0中，预先标准化的HTTP/1.1已得到支持。终端用户很快地适应了新的浏览器。1996年3月，一家网络托管公司报告说，互联网上使用的浏览器中有40%以上符合HTTP/1.1标准。这家网络托管公司报告说，到1996年6月，所有访问他们服务器的浏览器中有65%符合HTTP/1.1标准。^[13]RFC 2068定义的HTTP/1.1标准于1997年1月正式发行。对HTTP/1.1标准的改进和更新发布于1999年6月RFC 2616中。

2007年HTTPbis Working Group成立了，该组织的部分工作是为了修订和阐述HTTP/1.1规范。2014年6月，工作组发布了更新后的六部分规范废弃RFC 2616以下内容:

• RFC 7230, HTTP/1.1:消息语法和路由
• RFC 7231, HTTP/1.1:语义和内容
• RFC 7232, HTTP/1.1:条件请求
• RFC 7233, HTTP/1.1:范围请求
• RFC 7234, HTTP/1.1:缓存
• RFC 7235, HTTP/1.1:身份验证

HTTP/2发表于2015年5月RFC 7540中。

HTTP会话是一系列网络请求-响应事务。一个HTTP客户端通过建立一个连接到服务器上的特定端口(通常是端口80，偶尔是端口8080），来启动请求。监听该端口的一个HTTP服务器等待客户端的请求消息。收到请求后，服务器会返回一个状态行，如“HTTP/1.1 200 OK”，以及它自己的消息。该消息的正文通常是请求的资源，尽管也可能返回错误消息或其他信息。^[1]

3.1 持久连接

在HTTP/0.9和1.0中，连接在单个请求-响应之后关闭。在HTTP/1.1中引入了一种保持活跃的机制，在这种机制中，一个连接可以被多个请求重用。这样的持久连接明显地减少请求延迟，这是因为客户端在发送第一个请求后不需要重新协商TCP 3-Way握手连接。另一个积极的副作用是，一般来说，由于TCP的慢启动-机制，连接会随着时间而变得更快。

该协议的1.1版还对HTTP/1.0进行了带宽优化改进。例如，HTTP/1.1引入了分块传输编码以允许对持久连接上的内容进行流式传输而不是缓冲。HTTP管线化技术进一步减少延迟时间，允许客户端在等待每个响应之前发送多个请求。对该协议的另一个补充是Byte serving，其中服务器仅传输客户端明确请求的那部分的资源。

3.2 HTTP会话状态

HTTP是一个无状态协议。无状态协议不需要HTTP服务器在多个请求期间保留每个用户的信息或状态。然而，有些网络应用程序使用例如HTTPcookie或网页窗体中的隐藏变量实现状态或服务器端会话.

HTTP提供例如基本认证和摘要验证等多种身份验证方案，这些认证通过一种质询-相依机制运作，其中，服务器在处理请求内容之前识别并发出一个质询。

通过一组可扩展的质询-响应身份验证方案，HTTP为访问控制和身份验证提供了一个通用框架，服务器可以使用这些方案质询客户端请求，客户端可以使用这些方案提供身份验证信息。^[14]

4.1 身份验证域

HTTP身份验证规范还提供了一个任意的、特定于实现的构造，用于进一步划分给定根URI的公共资源。领域值字符串(如果存在)与规范根URI相结合，形成质询的保护空间组分。这实际上允许服务器在一个根URI下定义单独的身份验证范围。^[14]

客户端和服务器通过发送纯文本(ASCII)消息进行通信。客户端向服务器发送请求，服务器发送响应。

5.1 请求消息

请求消息包括以下内容:

• 请求行(例如，GET /images/logo.png HTTP/1.1，它意为从服务器上请求文件/images/logo.png 。)
• 字段名(例如，Accept-Language:en)。
• 空行
• 可选的报文主体

请求行和其他标题字段必须以<CR><LF>(即回车字符后加上换行字符)结尾。空行必须仅包含<CR><LF>，不包含其他空白内容。^[15]在HTTP/1.1协议中，所有除了Host的字段是可选的。

服务器接受只包含路径名的请求行，以便保持与仅支持RFC 1945中的HTTP/1.0之前规范HTTP客户端的兼容性。^[16]

请求方法

HTTP定义方法(有时也称为verbs，但规范中没有提到verbs，也没提到OPTIONS或HEAD一个verbs)来指示要在所识别的资源上期望执行的动作。该资源代表的内容，是预先存在的数据还是动态生成的数据，都取决于服务器的实现。通常，资源对应于驻留在服务器上的文件或可执行文件的输出。HTTP/1.0规范^[17]定义了GET、HEAD和POST方法以及HTTP/1.1规范^[18]添加了五种新方法:OPTIONS、PUT、DELETE、TRACE和CONNECT。通过在这些文档中被指定，它们的含义是众所周知的，并且可以互相依赖的。任何客户端都可以使用任何方法，并且服务器可以配置为支持任何方法组合。如果网络中间层不知道某个方法，它将被视为不安全的非幂等的方法。对可以定义的方法数量没有限制，这允许在不破坏现有基础架构的情况下指定未来的方法。例如，WebDAV定义了7种新方法，以及RFC 5789指定了PATCH方法。

方法名区分大小写^[19][20]。这与不区分大小写的HTTP头字段名称形成对比^[21]。

GET

GET方法请求显示指定资源。使用GET的请求应该只检索数据而不应该有其他效果。(其他一些超文本传输协议方法也是如此) ^[1]W3C发表了关于这一区别的指导原则“网络应用程序的设计不仅应遵循上述原则，而且也应遵循相关限制。" ^[22]

HEAD

HEAD方法的相遇与GET请求的响应相同，但是没有报文主体。这对于检索在响应报头中的元信息非常有用，而不必传输整个内容。

POST

POST请求服务器接受包含在请求中的实体作为由URI指定的web资源新下级。例如，POST后数据可能是对现有资源的注释；公告板、新闻组、邮件列表或评论中的一条信息；将网页窗体提价到数据处理流程得到的结果数据体；或者添加到数据库中的一条项目。 ^[23]

PUT

PUT方法请求将封闭实体存储在指定的UTI。如果该URI指向的是一个已经存在的资源，则会对其进行修改；如果该URI没有指向现有资源，那么服务器可以用该URI创建资源。 ^[24]

DELETE

DELETE方法删除指定的资源。

TRACE

TRACE方法响应接收到的请求，一遍客户端可以查看中间服务器所做的更改或添加（如果有的话）。

OPTIONS

OPTIONS方法返回服务器为指定的URL支持的HTTP方法。这可用于通过请求“*”而不是特定资源来检查网络服务器的功能。

CONNECT

CONNECT方法将请求连接转换为透明的TCP/IP隧道，通常是为了通过未加密的HTTP代理来促进SSL加密通信(HTTPS)。 ^{[25] [26] [27]}

PATCH

PATCH方法对资源部分进行修改。 ^[28]

所有通用的HTTP服务器都需要实现至少GET和HEAD方法，规范认为所有其他方法都是可选的。^[29]

安全方法

按照惯例，其中一些方法(例如GET、HEAD、OPTIONS和TRACE)被定义为是安全的，这意味着它们仅用于信息检索，不应改变服务器的状态。换句话说，他们不应该有副作用，除了了一些相对无害的影响，例如记录日志，web缓存，横幅广告或者增加一个网络计数器。因此，在不考虑应用程序状态的情况下发出任意GET请求应该被认为是安全的。然而，标准没有规定这一点，并且明确承认它不能得到保证。

相比之下，POST、PUT、DELETE和PATCH等方法旨在用于可能对服务器造成副作用或外部副作用的操作，例如金融交易或传输电子邮件。因此，这种方法通常不被网络机器人或者网络爬虫使用；有些不符合规则的网络机器人或爬虫倾向于在不考虑背景或后果是提出请求。

尽管GET请求的安全性得到了肯定，但是，实际上，服务器对请求的处理在技术上没有任何限制。因此，粗心或故意的程序会对服务器造成不小的改变。这是不被鼓励的，这是因为它会给网络缓存,搜索引擎和其他自动化代理造成问题，这些请求可能会对服务器进行意外更改。例如，网站可能允许通过以下URL删除资源http://example.com/article/1234/delete，如果获取方式是随意的话，甚至仅仅使用GET请求，也会删除该文章。^[30]

这种情况的一个实际的例子是在短命的谷歌网际加速器beta，它预取用户正在查看的页面上的任意URLs，导致全体地记录被自动更改或删除。由于广泛的批评，该测试版在首次发布后仅几周就暂停了。^[31][30]

幂等方法和网络应用

方法PUT和DELETE被定义为是幂等的，这意味着多个相同的请求应该具有与单个请求相同的效果。方法GET、HEAD、OPTIONS和TRACE，被规定为安全的，也应该是幂等的，这是因为HTTP是一个无状态协议。^[1]

相反，POST方法不一定是幂等的，因此多次发送相同的POST请求可能会进一步影响状态或导致进一步的副作用(例如金融交易)。在某些情况下，这可能是可取的，但是在其他情况下，这可能是由事故造成的，例如当用户没有意识到他们的动作将导致发送另一个请求，或者他们没有收到关于他们的第一个请求成功的足够的反馈时。虽然网络浏览器可能会显示警报对话框以警告用户：在某些情况下，重新加载页面可能会重新提交POST请求，但是通常由网络应用程序来处理POST检请求不应提交一次以上的情况。

请注意，一个方法是否幂等并不由协议或网络服务器强制执行。编写一个GET或其他请求触发数据库插入或其他非幂等操作网络应用程序是完全可能的，但是，如果用户代理假定重复相同的请求是安全的，忽略此建议可能会导致不良后果。

安全

TRACE方法可以用作被称为跨站点跟踪攻击的一部分；因此，常见的安全建议是在服务器配置中禁用它。^[32]Microsoft IIS支持专有的“TRACK”方法，其行为与TRACE类似，同样建议禁用。^[32]

一览表

5.2 响应信息

响应消息包括以下内容:

• 状态行，包括状态代码和原因消息(例如，HTTP/1.1 200 OK，这表示客户端的请求成功。)
• 响应字段(例如，Content-Type: text/html)
• 空行
• 可选的消息正文

状态行和其他回应字段都必须以<CR><LF>结尾。空行必须仅包含<CR><LF>，不包含其他空白内容。^[15]对于<CR><LF>的严格要求在报文主体中有所宽松，以便一致地使用其他系统换行符，例如<CR>或<LF>。^[33]

状态代码

在HTTP/1.0和此后的版本中，HTTP响应的第一行称为状态行并且包括一个数字状态代码(例如”404”)和文本消息短语(如“未找到”)。用户代理处理响应的方法主要取决于状态代码，其次取决于其他响应字段。可以使用自定义状态代码，因为如果用户代理遇到它无法识别的代码，它可以使用状态代码的第一个数字来确定响应的一般类别。^[34]

标准消息短语仅是建议，可以由网络开发者自行决定用其他“方言”代替他们。如果状态代码表明有问题，用户代理可能会显示消息短语以提供关于问题性质的进一步信息。该标准还允许用户代理尝试解释消息短语，尽管这可能是不明智的，因为标准明确规定状态代码是机器可读的而消息短语是人类可读的。为了更好地解释客户机和服务器之间的请求和响应，HTTP状态代码主要分为五组，命名为:

• 消息 1XX
• 成功 2XX
• 重定向 3XX
• 客户端错误 4XX
• 服务器错误 5XX

建立加密的HTTP连接最流行的方法是HTTPS。^[35]还存在另外两种建立加密的HTTP的方法:安全超文本传输协议（S-HTTP）和使用HTTP/1.1升级报头指定对TLS的升级。然而，支持这两者的浏览器几乎不存在。^[36][37][38]

下面是一个HTTP客户端与一个运行在www.example.com，端口80的HTTP服务器会话示例。如前所述，所有数据都是以纯文本形式发送的(美国信息交换标准码)编码，每行的末尾以双字节<CR><LF>('\r\n')结束。

7.1 客户端请求

GET / HTTP/1.1
Host: www.example.com

客户端请求(在这种情况下由请求行和一个标题字段组成)后面跟着一个空行，以便请求以一个双换行符结束，每个换行符都是回车符接下来是一个换行符。“主机”字段区分共享同一ip地址各种DNS名称，允许基于名称虚拟主机。虽然在HTTP/1.0中是可选的，但在HTTP/1.1中是强制性的。“/”表示/index.html(如果有的话)。)

7.2 服务器响应

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

ETag(实体标签)标头字段用于确定所请求资源的缓存版本是否与服务器上资源的当前版本相同。Content-Type指定HTTP消息传输的数据的互联网媒体类型，而Content-Length表示其长度（单位：字节）。HTTP/1.1网络服务器通过设置字段Accept-Range:bytes发布其对文档特定字节范围请求的响应能力。这一设计的意义在于，如果客户端只需要由服务器发送的资源某些部分^[39]，称为Byte serving。当Connection:close发送时，表示web服务器将在此次传输响应后立即关闭TCP链接。

大多数表头行是可选的。当缺少Content-Length时，长度是由其他方式确定。分块传输编码使用一个大小为0的块来标记内容的结尾。没有Content-Length的身份编码会在套接字关闭之前读取内容。

像gzip这样的内容编码可用于压缩传输的数据。

Gopher协议是20世纪90年代早期被超文本传输协议取代的内容传输协议。SPDY协议是谷歌开发的HTTP替代方案，它被新的HTTP协议HTTP/2取代。