HTTP 协议浅析(下.修订)

HTTP 协议浅析(下)

协议结构

　　 HTTP 报文由从客户机到服务器的请求和从服务器到客户机的响应构成。请求报文格式如下：

　　请求行 － 通用信息头 － 请求头 － 实体头 － 报文主体

　　请求行以方法字段开始，后面分别是 URL 字段和 HTTP 协议版本字段，并以 CRLF 结尾。 SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有关通用信息头，请求头和实体头方面的具体内容可以参照相关文件。

　　应报文格式如下：

　　状态行 － 通用信息头 － 响应头 － 实体头 － 报文主体

　　状态码元由 3 位数字组成，表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述，状态码用来支持自动操作，而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头，响应头和实体头方面的具体内容可以参照相关文件。

工作原理

　　既然我们明白了 URL 的构成，那么 HTTP 是怎么工作呢？我们接下来就要讨论这个问题。

　　一次 HTTP 操作称为一个事务，其工作过程可分为四步：

　　首先客户机与服务器需要建立连接。只要单击某个超级链接， HTTP 的工作就开始了。

　　建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（ URL ）、协议 版本号 ，后边是 MIME 信息包括请求修饰符、客户机信息和可能的内容。

　　服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。

　　客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客 户机与服务器断开连接。

　　如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由 HTTP 自己完成的，用户只要用鼠标点击，等待信息显示就可以了。

　　许多 HTTP 通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。在 Internet 上， HTTP 通讯通常发生在 TCP/IP 连接之上。缺省端口是 TCP 80 ，但其它的端口也是可用的。但这并不预示着 HTTP 协议在 Internet 或其它网络的其它协议之上才能完成。 HTTP 只预示着一个可靠的传输。

　　这个过程就好像我们打电话订货一样，我们可以打电话给商家，告诉他我们需要什么规格的商品，然后商家再告诉我们什么商品有货，什么商品缺货。这些，我们是通过电话线用电话联系（ HTTP 是通过 TCP/IP ），当然我们也可以通过传真，只要商家那边也有传真。

　　以上简要介绍了 HTTP 协议的宏观运作方式，下面介绍一下 HTTP 协议的内部操作过程。

　　在 WWW 中， “ 客户 ” 与 “ 服务器 ” 是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。基于 HTTP 协议的客户 / 服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。这就好像上面的例子，我们电话订货的全过程。

　　其实简单说就是任何服务器除了包括 HTML 文件以外，还有一个 HTTP 驻留程序，用于响应用户请求。你的浏览器是 HTTP 客户，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了 HTTP 请求，此请求被送往由 IP 地址 指定的 URL 。驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，在网络上发送和接收的数据已经被分成一个或多个数据包（ packet ），每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。 TCP/IP 决定了每个数据包的格式。如果事先不告诉你，你可能不会知道信息被分成用于传输和再重新组合起来的许多小块。

　　也就是说商家除了拥有商品之外，它也有一个职员在接听你的电话，当你打电话的时候，你的声音转换成各种复杂的数据，通过电话线传输到对方的电话机，对方的电话机又把各种复杂的数据转换成声音，使得对方商家的职员能够明白你的请求。这个过程你不需要明白声音是怎么转换成复杂的数据的。

 

安全及幂等方法

安全方法

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

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

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

幂等方法

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

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

 

HTTP返回代码解释：

　　 "100" : Continue

　　 "101" : witching Protocols

　　 "200" : OK

　　 "201" : Created

　　 "202" : Accepted

　　 "203" : Non-Authoritative Information

　　 "204" : No Content

　　 "205" : Reset Content

　　 "206" : Partial Content

　　 "300" : Multiple Choices

　　 "301" : Moved Permanently

　　 "302" : Found

　　 "303" : See Other

　　 "304" : Not Modified

　　 "305" : Use Proxy

　　 "307" : Temporary Redirect

　　 HTTP 400 - 请求无效

　　 HTTP 401.1 - 未授权：登录失败

　　 HTTP 401.2 - 未授权：服务器配置问题导致登录失败

　　 HTTP 401.3 - ACL 禁止访问资源

　　 HTTP 401.4 - 未授权：授权被筛选器拒绝

　　 HTTP 401.5 - 未授权： ISAPI 或 CGI 授权失败

　　 HTTP 403 - 禁止访问

　　 HTTP 403 - 对 Internet 服务管理器 (HTML) 的访问仅限于 Localhost

　　 HTTP 403.1 禁止访问：禁止可执行访问

　　 HTTP 403.2 - 禁止访问：禁止读访问

　　 HTTP 403.3 - 禁止访问：禁止写访问

　　 HTTP 403.4 - 禁止访问：要求 SSL

　　 HTTP 403.5 - 禁止访问：要求 SSL 128

　　 HTTP 403.6 - 禁止访问： IP 地址被拒绝

　　 HTTP 403.7 - 禁止访问：要求客户证书

　　 HTTP 403.8 - 禁止访问：禁止站点访问

　　 HTTP 403.9 - 禁止访问：连接的用户过多

　　 HTTP 403.10 - 禁止访问：配置无效

　　 HTTP 403.11 - 禁止访问：密码更改

　　 HTTP 403.12 - 禁止访问：映射器拒绝访问

　　 HTTP 403.13 - 禁止访问：客户证书已被吊销

　　 HTTP 403.15 - 禁止访问：客户访问许可过多

　　 HTTP 403.16 - 禁止访问：客户证书不可信或者无效

　　 HTTP 403.17 - 禁止访问：客户证书已经到期或者尚未生效

　　 HTTP 404.1 - 无法找到 Web 站点

　　 HTTP 404 - 无法找到文件

　　 HTTP 405 - 资源被禁止

　　 HTTP 406 - 无法接受

　　 HTTP 407 - 要求代理身份验证

　　 HTTP 410 - 永远不可用

　　 HTTP 412 - 先决条件失败

　　 HTTP 414 - 请求 - URI 太长

　　 HTTP 500 - 内部服务器错误

　　 HTTP 500.100 - 内部服务器错误 - ASP 错误

　　 HTTP 500-11 服务器关闭

　　 HTTP 500-12 应用程序重新启动

　　 HTTP 500-13 - 服务器太忙

　　 HTTP 500-14 - 应用程序无效

　　 HTTP 500-15 - 不允许请求 global.asa

　　 Error 501 - 未实现

　　 HTTP 502 - 网关错误

版本历史

协议版本

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

　　

0.9

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

　　

HTTP/1.0

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

　　

HTTP/1.1

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

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

　　 1 缓存处理

　　 2 带宽优化及网络连接的使用

　　 3 错误通知的管理

　　 4 消息在网络中的发送

　　 5 互联网地址的维护

　　 6 安全性及完整性