超文本传输协议

维基百科，自由的百科全书

跳转到： 导航, 搜索
網路協議
應用層
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTP ·RTSP · SDP · SOAP · GTP · STUN · NTP · SSDP · 更多
传输层
TCP · UDP · TLS · DCCP · SCTP · RSVP · PPTP · 更多
网络层
IP (IPv4 · IPv6) ·

ICMP · ICMPv6 · IGMP · RIP ·

OSPF · BGP · IS-IS · IPsec · 更多
数据链路层
802.11 · 802.16 · Wi-Fi · WiMAX · ARP · RARP · ATM · DTM · 令牌环 · 以太网 · FDDI · 帧中继 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN · 更多
物理层
以太网物理层 · 调制解调器 · PLC · SONET/SDH · G.709 · 光导纤维 · 同轴电缆 · 双绞线 · 更多
本模板: 查看 • 討論 • 編輯 • 歷史

超文本传输协议(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）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnels）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。 事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。

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

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

通过HTTP或者HTTPS协议请求的资源由统一资源定位器（Uniform Resource Identifiers）（或者，更准确一些，URLs）来标识。

[编辑] 请求信息（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
删除指定资源。
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位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

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

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

[编辑] 持久连接

[编辑] 安全超文本协议

[编辑] 例子

下面是一个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），而不是“传输”（transport）。故其中文译名“超文本传输协议”恰恰引种反映了这种误解。更符合原义的译名应该为“超文本转移协议”。

[编辑] 参考

  1. ^ （中文）Roy Thomas Fielding．架构风格与基于网络的软件架构设计．於2009年4月19日查阅． 

[编辑] 外部链接

来自“http://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE”
个人工具