跳转到内容

超文本传输协议

本页使用了标题或全文手工转换
维基百科，自由的百科全书

这是本页的一个历史版本，由Ntoukk（留言 | 贡献）在2012年12月3日 (一) 08:43 （→概述）编辑。这可能和当前版本存在着巨大的差异。

網際網路协议套組
應用層
傳輸層
網路層
連結層
HTTP／HTTPS
版本
请求方法
报文主体
頭欄位
狀態碼
相关主题

超文本傳輸協定（HTTP，HyperText Transfer Protocol）是網際網路上應用最為廣泛的一种網路協議。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

概述

HTTP的发展是万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協議中一個現今被廣泛使用的版本——HTTP 1.1。

HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。我们称这个客户端为用户代理程式（user agent）。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnel）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和基于它支持的层。事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定其下层协议提供可靠的传输，任何能够提供这种保证的协议都可以被其使用。

通常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器向客户端发回一个状态行，比如"HTTP/1.1 200 OK"，和响应的消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。

HTTP使用TCP而不是UDP的原因在于打开一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。具体细节请参考『TCP和UDP的不同』。

通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。

请求信息（Request Message）

发出的请求信息包括以下几个

  • 请求行，例如GET /images/logo.gif HTTP/1.1，表示从/images目录下请求logo.gif这个文件。
  • （请求）头，例如Accept-Language: en
  • 空行
  • 可选的消息体

请求行和标题必须以<CR><LF>作为结尾（也就是，回车然后换行）。空行内必须只有<CR><LF>而无其他空格。在HTTP/1.1协议中，所有的请求头，除Host外，都是可选的。

请求方法

HTTP/1.1协议中共定义了八种方法（有时也叫“动作”）来表明Request-URI指定的资源的不同操作方式：

OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
HEAD
向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。参见安全方法
POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT
向指定资源位置上传其最新内容。
DELETE
请求服务器删除Request-URI所标识的资源。
TRACE
回显服务器收到的请求，主要用于测试或诊断。
CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。

HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。当然，所有的方法支持的实现都应当符合下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。

安全及幂等方法

安全方法

开发者应当意识到他们的软件代表了用户在因特网上进行交互，并且应当告知用户，他们正在进行的操作可能对他们自身或者其他人有未曾预料的重要影响。

特别地，对于GET和HEAD方法而言，除了进行获取资源信息外，这些请求不应当再有任何其他意义。也就是说，这些方法应当被认为是“安全的”。客户端应当使用其他“非安全”方法，例如POST，PUT及DELETE来以特殊的方式（通常是按钮而不是超链接）使得客户能够意识到可能要负的责任（例如一个按钮带来的资金交易）或者被告知正在请求的操作可能是不安全的（例如某个文件将被上传或删除）。

但是，不能想当然地认为服务器在处理某个GET请求时不会产生任何副作用。事实上，很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。

幂等方法

假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作“幂等”的。GET，HEAD，PUT和DELETE方法都有这样的幂等属性，同样由于根据协议，OPTIONS，TRACE都不应有副作用，因此也理所当然也是幂等的。

假如某个由若干个请求做成的请求序列产生的结果在重复执行这个请求序列或者其中任何一个或多个请求后仍没有发生变化，则这个请求序列便是“幂等”的。但是，可能出现若干个请求做成的请求序列是“非幂等”的，即使这个请求序列中所有执行的请求方法都是幂等的。例如，这个请求序列的结果依赖于某个会在下次执行这个序列的过程中被修改的变量。

协议版本号

超文本传输协议已经演化出了很多版本，它们中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本号的用法。客户端在请求的开始告诉服务器它采用的协议版本号，而后者则在响应中采用相同或者更早的协议版本。

0.9

已过时。只接受GET一种请求方法，没有在通讯中指定版本号，且不支持请求头。由于该版本不支持POST方法，因此客户端无法向服务器传递太多信息。

HTTP/1.0

这是第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用，特别是在代理服务器中。

HTTP/1.1

当前版本。持久连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。

HTTP/1.1相较于HTTP/1.0协议的区别主要体现在：

  • 缓存处理
  • 带宽优化及网络连接的使用
  • 错误通知的管理
  • 消息在网络中的发送
  • 互联网地址的维护
  • 安全性及完整性

状态行

参见：HTTP状态码

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

  • 1xx消息——请求已被服务器接收，继续处理
  • 2xx成功——请求已成功被服务器接收、理解、并接受
  • 3xx重定向——需要后续操作才能完成这一请求
  • 4xx请求错误——请求含有词法错误或者无法被执行
  • 5xx服务器错误——服务器在处理某个正确请求时发生错误

虽然RFC 2616中已经推荐了描述状态的短语，例如"200 OK"，"404 Not Found"，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。

持續连接

在HTTP/0.9和1.0使用非持續连接，在非持續连接下：每个tcp只連接一个web对象，连接在每个请求-回應对后都会关闭，一个连接可被多个请求重复利用的保持连接机制被引入。这种连接持續化显著地减少了请求延迟，因为客户不用在首次请求后再次进行TCP交互確認建立连接。现在在HTTP/1.1使用持續连接，不必为每个web对象创建一个新的连接，一个连接可以传送多个对象。 HTTP1.1还进行了带宽优化，例如1.1引入了chunked transfer encoding（分块传输编码）来允许stream化传输持續连接上发送的内容，取代原先的buffer式传输。HTTP管道允许客户在上一个回應被收到前发送多重请求从而进一步减少了延迟时间。 另一项协议的改进是byte serving（字节服务），允许服务器根据客户的请求仅仅传输资源的一部分。

安全超文本协议

目前有两种方法来建立安全超文本协议连接：HTTPS URI方案和HTTP 1.1请求头（由RFC2817引入）。由于浏览器对后者的几乎没有任何支持，因此HTTPS URI方案仍是建立安全超文本协议连接的主要手段。安全超文本连接协议使用https://代替http://

例子

下面是一个HTTP客户端与服务器之间会话的例子，运行于www.google.com，端口80

客户端请求： 

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

（紧跟着一个换行，通过敲入回车实现）

服务器应答： 

HTTP/1.1 200 OK
Content-Length: 3059
Server: GWS/2.0
Date: Sat, 11 Jan 2003 02:44:04 GMT
Content-Type: text/html
Cache-control: private
Set-Cookie: PREF=ID=73d4aef52e57bae9:TM=1042253044:LM=1042253044:S=SMCc_HRPCQiqy
X9j; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Connection: keep-alive

（紧跟着一个空行，并且由HTML格式的文本组成了Google的主页）

在HTTP1.0中，客户端发送一个请求至服务器，服务器发送一个应答至客户端。之后，连接将被释放。另一方面，HTTP1.1支持持久连接。这使得客户端可以发送请求并且接收应答，然后迅速的发送另一个请求和接收另一个应答。因为多个额外的请求，TCP连接并没有被释放，而每个请求中关于TCP的负载相对较少。同时，在得到上一个请求的应答之前发送多个请求（通常是两个）也成为可能。这个技术被称为「流水线」。

中文译名问题

HTTP在中国大陆被翻译为“超文本传输协议”，因为“transfer”在此有“传输”的含意。但HTTP定制者之一的Roy Fielding博士在其论文[1]（6.5.3节）中使用“transfer”表达的是“（表述状态的）转移”（Representational State Transfer），而不是“传输”。这是因为英语单词“transfer”在不同语境下的多义性，请勿误解。

另一方面看，不管在大陆还是港台地区，应用层协议名字中的“transfer”习惯上都被译为“传输”，1991年，Tim Berners-Lee发明设计HTTP的最初目的很单纯，就是为了传输含有超链的文本，最初版本的HTTP只能传输纯文本页面，只有一个GET方法，并不适用于构建各种应用系统，这里HTTP（超文本传输协议）与FTP（文件传输协议）、NNTP（网络新闻传输协议） 、SMTP（简单邮件传输协议）相比，并无特别之处。HTTP流行之后，Roy Fielding2000年论文提出的Representational State Transfer，是HTTP（也可以是其他传输协议）之上构建各种应用系统的一种架构风格，其中的“State Transfer（状态转移）”并未改变“Hypertext Transfer（超文本传输）”的原始含义，由此看“超文本传输协议”的译法并无不妥。

参见

参考

  1. ^ Roy Thomas Fielding. 架构风格与基于网络的软件架构设计 (PDF). [2009-04-19] （中文）. 

外部链接

检索自“https://zh.wikipedia.org/zhwiki/w/index.php?title=超文本传输协议&oldid=23931945”