超文本传输协议-HTTP

超文本传输协议-HTTP(HTTP，HyperText Transfer Protocol)是因特网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。 HTTP概述 　　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或者HTTPS协议请求的资源由统一资源定位器（Uniform Resource Identifiers）（或者，更准确一些，URLs）来标识。 HTTP请求信息（Request Message） 发出的请求信息包括以下几个 HTTP请求行，例如GET /images/logo.gif HTTP/1.1，表示从/images 目录下请求logo.gif 这个文件。 （请求）头，例如Accept-Language: en 空行 可选的消息体 请求行和标题必须以 作为结尾（也就是，回车然后换行）。空行内必须只有 而无其他空格。在HTTP/1.1 协议中，所有的请求头，除Host外，都是可选的。 HTTP请求方法（Request Methods） HTTP协议中定义了八种方法（有时也叫“动作”）来表示对指定数据的操作。 HEAD （Head方法）要求响应与相应的GET请求的响应一样，但是没有的响应体（response body）。这用来获得响应头（response header）中的 元数据信息（meta-infomation）有（很）帮助，（因为）它不需要传输所有的内容。 GET （Get方法用来）请求指定的资源。它是目前网上最常用的方法。它不应该用于一些会造成副作用的操作中 （在网络应用中用它来提交动作是一种常见的错误用法）。（细节请）参考后面的“安全方法”（这一节）。 POST （POST方法用来）向指定的资源提交需要处理的数据。这些数据写在请求的内容里。（POST请求）可以导致新资源的产生和已有资源的更新。 PUT 上传指定资源 DELETE 删除指定资源 TRACE （Trace方法告诉服务器端）返回收到的请求。客户端可以（通过此方法）察看在请求过程中中间服务器添加或者改变哪些内容。 OPTIONS 返回服务器（在指定URL上）支持的HTTP方法。通过请求“*”而不是指定的资源，这个方法可以用来检查网络服务器的功能。 CONNECT 将请求的连接转换成透明的TCP/IP通道，通常用来简化通过非加密的HTTP代理的SSL-加密通讯（HTTPS）。 HTTP服务器至少应该实现Get和Head方法，可能的话，也实现OPTIONS方法。 HTTP安全方法 　　有些方法（比如HEAD, GET, OPTIONS, and TRACE) 被定义为安全方法，这些方法针对的只是信息的返回，并不会改变服务器的状态（换句话说就是这些方法不会产生副作用）。不安全的方法（例如POST, PUT and DELETE) 应该用特殊的方式向用户展示，通常是按钮而不是链接，这样就可以使用户意识到可能要负的责任（例如一个按钮带来的资金交易。） HTTP协议版本号 　　超文本传输协议已经演化出了很多版本，它们中的大部分都是向下兼容的。客户端在请求的开始告诉服务器它采用的协议版本号，而后者则在响应中采用相同或者更早的协议版本。 HTTP/0.9 　　已过时。只接受 GET 一种请求方法，没有在通讯中指定版本号，且不支持请求头。由于该版本不支持 POST 方法，所以客户端无法向服务器传递太多信息。 HTTP/1.0 　　这是第一个在通讯中指定版本号的 HTTP 协议版本，至今仍被广泛采用，特别是在代理服务器中。 HTTP/1.1 　　当前版本。持久连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。 此版相较于 HTTP/1.0 协议的区别主要体现在： HTTP缓存处理 带宽及网络连接的管理 安全性及完整性 HTTP状态行 参见：HTTP状态码 所有 HTTP 响应的第一行都是状态行, 依次是当前 HTTP 版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。 状态代码的第一个数字代表当前响应的类型： 1xx 消息——请求已被服务器接收，继续处理 2xx 成功——请求已成功被服务器接收、理解、并接受 3xx 重定向——需要后续操作才能完成这一请求 4xx 请求错误——请求含有词法错误或者无法被执行 5xx 服务器错误——服务器在处理某个正确请求时发生错误 虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK"，"404 Not Found"，但是 WEB 开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。 例子 下面是一个HTTP客户端与服务器之间会话的例子，运行于www.cnpaf.net，端口80 客户端请求： GET / HTTP/1.1 Host：www.google.com （紧跟着一个换行，通过敲入回车实现） 服务器应答： HTTP/1.1 200 OK Content-Length: 61655 Content-Type: text/html Content-Location: http://www.cnpaf.net/index.htm Last-Modified: Thu, 23 Oct 2008 01:51:26 GMT Accept-Ranges: bytes ETag: "70e053dcb134c91:3554" Server: Microsoft-IIS/6.0 Date: Thu, 23 Oct 2008 01:59:25 GMT Connection: close Connection: keep-alive （紧跟着一个空行，并且由HTML格式的文本组成了中国协议分析网的主页） 　　在HTTP1.0中，客户端发送一个请求至服务器，服务器发送一个应答至客户端。之后，连接将被释放。另一方面，HTTP1.1支持持久连接。这使得客户端可以发送请求并且接收应答，然后迅速的发送另一个请求和接收另一个应答。因为多个额外的请求，TCP连接并没有被释放，而每个请求中关于TCP的负载相对较少。同时，在得到上一个请求的应答之前发送多个请求（通常是两个）也成为可能。这个技术被称为“流水线”。