【转】：http://www.iteye.com/topic/648673
HTTP 协议浅析(上)
超文本传输协议 (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 协议提供传输控制，按顺序组织数据，和错误纠正。
通过 HTTP 或者 HTTPS 协议请求的资源由统一资源标示符（ Uniform Resource Identifiers ）（或者，更准确一些， URLs ）来标识。
HTTP 是超文本传输协议，是客户端浏览器或其他程序与 Web 服务 器之间的应用层通信协议。在 Internet 上的 Web 服务器上存放的都是超文本信息，客户机需要通过 HTTP 协议传输所要访问的超文本信息。 HTTP 包含命令和传输信息，不仅可用于 Web 访问，也可以用于其他因特网 / 内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。
当我们想浏览一个网站的时候，只要在浏览器的地址栏里输入网站的地址就可以了，例如 www.abc.com, 但是在浏览器的地址栏里面出现的却是： http://www.abc.com , 你知道为什么会多出一个 “http” 吗？
我们在浏览器的地址栏里输入的网站地址叫做 URL (Uniform Resource Locator ， 统一资源定位符 ) 。就像每家每户都有一个门牌地址一样，每个网页也都有一个 Internet 地址。当你在 浏览器的地址框中输入一个 URL 或是单击一个超级链接时， URL 就确定了要浏览的地址。浏览器通过超文本传输协议 (HTTP) ，将 Web 服务器上站点的网页代码提取出来，并翻译成漂亮的网页。因此，在我们认识 HTTP 之前，有必要先弄清楚 URL 的组成 , 例如： http://www.abc.com/china/index.htm 。它的含义如下：
1. http:// ：代表超文本传输协议，通知 abc.com 服务器显示 Web 页，通常不用输入；
2. www ：代表一个 Web （万维网）服务器；
3. abc.com/ ：这是装有网页的服务器的域名，或站点服务器的名称；
4. China/ ：为该服务器上的子目录，就好像我们的文件夹；
5. Index.htm ： index.htm 是文件夹中的一个 HTML 文件（网页）。
我们知道， Internet 的基本协议是 TCP/IP 协议，然而在 TCP/IP 模型最上层的是应用层（ Application layer ），它包含所有高层的协议。高层协议有：文件传输协议 FTP 、电子邮件传输协议 SMTP 、域名 系统服务 DNS 、网络新闻传输协议 NNTP 和 HTTP 协议等。
HTTP 协议（ HyperText Transfer Protocol ，超文本传输协议）是用于从 WWW 服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示 ( 如文本先于图形 ) 等。这就是你为什么在浏览器中看到的网页地址都是以 http:// 开头的原因。
自 WWW 诞生以来，一个多姿多彩的资讯和虚拟的世界便出现在我们眼前，可是我们怎么能够更加容易地找到我们需要的资讯呢？当决定使用超文本作为 WWW 文档的标准格式后，于是在 1990 年，科学家们立即制定了能够快速查找这些超文本文档的协议，即 HTTP 协议。经过几年的使用与发展，得到不断的完善和扩展，目前在 WWW 中使用的是 HTTP/1.0 的第六版。
HTTP （ HyperText Transfer Protocol ）是超文本传输协议的缩写，它用于传送 WWW 方式的数据，关于 HTTP 协议的详细内容请参考 RFC2616 。 HTTP 协议采用了请求 / 响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、 URL 、协议版本、以及包含请求修饰符、客户信息和内容的类似于 MIME 的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
通常 HTTP 消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个指示头域结束的空行和可选的消息体组成。 HTTP 的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（ : ）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。
通用头域
通用头域包含请求和响应消息都支持的头域，通用头域包含 Cache-Control 、 Connection 、 Date 、 Pragma 、 Transfer-Encoding 、 Upgrade 、 Via 。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在 UPnP 消息中使用的通用头域。
Cache-Control 头域
Cache-Control 指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control 并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括 no-cache 、 no-store 、 max-age 、 max-stale 、 min-fresh 、 only-if-cached ，响应消息中的指令包括 public 、 private 、 no-cache 、 no-store 、 no-transform 、 must-revalidate 、 proxy-revalidate 、 max-age 。各个消息中的指令含义如下：
Public 指示响应可被任何缓存区缓存。
Private 指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。
no-cache 指示请求或响应消息不能缓存
no-store 用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
max-age 指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
min-fresh 指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale 指示客户机可以接收超出超时期间的响应消息。如果指定 max-stale 消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。
Date 头域
Date 头域表示消息发送的时间，时间的描述格式由 rfc822 定义。例如， Date:Mon,31Dec200104:25:57GMT 。 Date 描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
Pragma 头域
Pragma 头域用来包含实现特定的指令，最常用的是 Pragma:no-cache 。在 HTTP/1.1 协议中，它的含义和 Cache-Control:no-cache 相同。
请求消息
请求消息的第一行为下面的格式：
MethodSPRequest-URISPHTTP-VersionCRLFMethod 表示对于 Request-URI 完成的方法，这个字段是大小写敏感的，包括 OPTIONS 、 GET 、 HEAD 、 POST 、 PUT 、 DELETE 、 TRACE 。方法 GET 和 HEAD 应该被所有的通用 WEB 服务器 支持，其他所有方法的实现是可选的。 GET 方法取回由 Request-URI 标识的信息。 HEAD 方法也是取回由 Request-URI 标识的信息，只是可以在响应时，不返回消息体。 POST 方法可以请求服务器接收包含在请求中的实体信息，可以用于提交 表单 ，向新闻组、 BBS 、邮件群组和数据库发送消息。
SP 表示空格。 Request-URI 遵循 URI 格式，在此字段为星号（ * ）时，说明请求并不用于某个特定的资源地址，而是用于服务器本身。 HTTP-Version 表示支持的 HTTP 版本，例如为 HTTP/1.1 。 CRLF 表示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信 息。请求头域可能包含下列字段 Accept 、 Accept-Charset 、 Accept-Encoding 、 Accept-Language 、 Authorization 、 From 、 Host 、 If-Modified-Since 、 If-Match 、 If-None-Match 、 If-Range 、 If-Range 、 If-Unmodified-Since 、 Max-Forwards 、 Proxy-Authorization 、 Range 、 Referer 、 User-Agent 。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。
典型的请求消息：
Host: download.microtool.de
Accept: */*
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/4.04[en](Win95;I;Nav)
Range: bytes=554554-
上例第一行表示 HTTP 客户端（可能是浏览器、下载程序）通过 GET 方法获得指定 URL 下的文件。棕色的部分表示请求头域的信息，绿色的部分表示通用头部分。
Host 头域
Host 头域指定请求资源的 Intenet 主机和 端口号 ，必须表示请求 url 的原始服务器或网关的位置。 HTTP/1.1 请求必须包含 主机头 域，否则系统会以 400 状态码返回。
Referer 头域
Referer 头域允许客户端指定请求 uri 的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化 cache 等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的 uri 没有自己的 uri 地址， Referer 不能被发送。如果指定的是部分 uri 地址，则此地址应该是一个 相对地址 。
Range 头域
Range 头域可以请求实体的一个或者多个子范围。例如，
表示头 500 个字节： bytes=0-499
表示第二个 500 字节： bytes=500-999
表示最后 500 个字节： bytes=-500
表示 500 字节以后的范围： bytes=500-
第一个和最后一个字节： bytes=0-0,-1
同时指定几个范围： bytes=500-600,601-999
但是服务器可以忽略此请求头，如果无条件 GET 包含 Range 请求头，响应会以状态码 206 （ PartialContent ）返回而不是以 200 （ OK ）。
User-Agent 头域
User-Agent 头域的内容包含发出请求的用户信息。
响应消息
响应消息的第一行为下面的格式：
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
HTTP-Version 表示支持的 HTTP 版本，例如为 HTTP/1.1 。 Status-Code 是一个三个数字的结果代码。 Reason-Phrase 给 Status-Code 提供一个简单的文本描述。 Status-Code 主要用于机器自动识别， Reason-Phrase 主要用于帮助用户理解。 Status-Code 的第一个数字定义响应的类别，后两个数字没有分类的作用。第一个数字可能取 5 个不同的值：
1xx: 信息响应类，表示接收到请求并且继续处理
2xx: 处理成功响应类，表示动作被成功接收、理解和接受
3xx: 重定向 响应类，为了完成指定的动作，必须接受进一步处理
4xx: 客户端错误，客户请求包含语法错误或者是不能正确执行
5xx: 服务端错误，服务器不能正确执行一个正确的请求
响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和 Request-URI 进一步的信息。响应头域包含 Age 、 Location 、 Proxy-Authenticate 、 Public 、 Retry-After 、 Server 、 Vary 、 Warning 、 WWW-Authenticate 。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一般将会作为实体头域处理。
典型的响应消息：
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:"a030f020ac7c01:1e9f"
Content-length:39725426
Content-range:bytes554554-40279979/40279980
上例第一行表示 HTTP 服务端响应一个 GET 方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体头域的信息。
Location 响应头
Location 响应头用于重定向接收者到一个新 URI 地址。
Server 响应头
Server 响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。
HTTP- 运作方式
HTTP 协议是基于请求／响应 范式 的。一个客户机与 服务器 建立连接后，发送一个请求给服务器，请求方式的格式为，统一资源标识符、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。
许多 HTTP 通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理 (UA) 和源服务器 (O) 之间通过一个单独的连接来完成。
当一个或多个中介出现在请求／响应链中时，情况就变得复杂一些。中介由三种：代理 (Proxy) 、 网关 (Gateway) 和通道 (Tunnel) 。一个代理根据 URI 的绝对格式来接受请求，重写全部或部分消息，通过 URI 的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介 ( 例如：防火墙等 ) 或者是中介不能识别消息的内容时，通道经常被使用 .
实体
请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括 Allow 、 Content-Base 、 Content-Encoding 、 Content-Language 、 Content-Length 、 Content-Location 、 Content-MD5 、 Content-Range 、 Content-Type 、 Etag 、 Expires 、 Last-Modified 、 extension-header 。 extension-header 允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流，它的编码方式由 Content-Encoding 或 Content-Type 定义，它的长度由 Content-Length 或 Content-Range 定义。
Content-Type 实体头
Content-Type 实体头用于向接收方指示实体的介质类型，指定 HEAD 方法送到接收方的实体介质类型，或 GET 方法发送的请求介质类型 Content-Range 实体头
Content-Range 实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例如，传送头 500 个字节次字段的形式： Content-Range:bytes0-499/1234 如果一个 http 消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求）， Content-Range 表示传送的范围， Content-Length 表示实际传送的字节数。
Last-modified 实体头
Last-modified 实体头指定服务器上保存内容的最后修订时间。
例如，传送头 500 个字节次字段的形式： Content-Range:bytes0-499/1234 如果一个 http 消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求）， Content-Range 表示传送的范围， Content-Length 表示实际传送的字节数。
Last-modified 实体头
