超文本传输协议(HTTP1.1)中文

应用层
超文本传输协议（HTTP）
一、前言
TCP/IP应用层协议有许多种，本文档讲解我们最熟悉的超文本传输协议（HTTP）。

超文本传输协议（HTTP）版本1.1是一个草案标准，其描述见RFC 2612。

旧的HTTP 1.0是一个指示性协议，RFC 1945对它进行了描述。

超文本传输协议是为了传输超文本标记语言（Hypertext Markup Language，HTML）而设计的协议。

HTML是一种用于创建超文本文档的标记语言。

有关HTML的信息请参见相关的超文本标记语言的书籍。

二、HTTP综述
HTTP基于请求—响应活动。

客户端运行浏览器应用程序，它建立与服务器的连接，并以请求的形式发送一个请求到服务器。

服务器用一个状态行做出响应，包括信息的协议版本以及成功或者错误代码，后面跟着一个消息，它包含服务器信息、实体信息和可能的内容。

HTTP事务被划分为如下4个步骤。

除了实验性应用程序之外，现行习惯要求客户在发出每个请求之前先建立连接，并由服务器在发送响应之后关闭连接。

客户和服务器都应当注意任何一方都有可能过早地关闭连接，原因可能是用户操作、自动超时或者程序故障等，他们应当以一种可预见的并且所期望的方式处理这种关闭行为。

在任何一种情况下，任何一方或者双方关闭的连接总是终止当前请求，而不管它的状态如何。

简单的说HTTP是一种无状
态协议，因为它不跟踪连接。

例如：为了装入包含两个图形的页面，支持图形的浏览器将打开三个TCP 连接：一个连接用于页面，而另外连个连接用于图形。

然而大多数浏览器能够同时处理几个这样的连接。

如果一个页面包含大量要素，每个资源都新建一个TCP连接，这将占用大量资源。

在HTTP1.1中缓和了这个问题，它为每种类型元素建立一个TCP连接，同样类型的元素使用同一个TCP连接。

HTTP 1.1不同于HTTP 1.0的地方就是它使用了永久连接。

三、统一资源标识URI
URI亦可称为web地址，是统一资源定位器（URL）和统一资源名称（URN）的组合。

依照RFC 1945种的定义，“统一资源标识符是通过名称、位置或者其他的特征标识资源的简单格式字符串”。

四、HTTP消息类型
HTTP消息既可以是客户端请求也可以是服务器响应。

下面说明了HTTP消息类型：HTTP-message = Request | Response
五、消息头
HTTP消息头字段为如下形式之一：
●一般报文头
●请求报文头
●响应报文头
●实体报文头
●消息体：如果未使用传输编码，可以把消息体称为实体。

●消息长度
5.1一般报文头
一般报文头字段既可以用于请求消息，又可以用于响应消息。

当前的一般报文头字段选项如下：
●缓存控制（Cach-Control）
●连接
●日期
●标记（Pragma）
●传输编码（Transfer-Encoding）
●升级（Upgrade）
●通过（Via）
六、HTTP方法
HTTP方法是HTTP客户机向服务器发出的命令。

HTTP 1.0版本仅定义了三种方法如下表，HTTP1.1
七、状态码
HTTP服务器发送状态码以指出请求的成功或者失败。

HTTP 1.1版本定义的HTTP状态码如下：
八、访问认证
HTTP提供了一种认证机制，它允许服务器规定资源的访问许可及使用这些资源的客户。

认证方法可以是如下两种之一。

8.1基本认证机制
基本认证机制基于用户ID和密码。

在这种认证机制中，服务器只在用户ID和密码通过验证时才允许连接。

在基本认证中，用户ID和密码没有加密。

他们按Base64格式编码。

因此极力推荐使用SSL或者TLS。

8.2摘要认证机制（digest authentication scheme）
摘要认证机制是对HTTP的扩展，其描述见RFC 2617。

在这种认证机制中，用户ID和一个包含密码的散列值的摘要被发送到服务器。

服务器计算一个类似的摘要，如果两个摘要相同则授予对受保护资源的访问。

注意到如果启用摘要认证，在网络上发送的不仅仅是加密密码，这种密码在有正确的密钥下可以被解密，而且还有一个密码的散列值，这是不能被解密的。

因此，与Base64编码密码相比，摘要认证提供了高级的安全性。

可惜的是，摘要认证还没有得到所有浏览的支持。

九、HTTP缓存
HTTP的重要特征之一就是高速缓存能力。

因为HTTP是一个分布式的基于信息的协议，缓存能够显著地提高性能。

HTTP 1.1协议有许多功能可以有效而正确地使用缓存。

在大多数情况下，客户端请求和服务器响应在某个合理的时间范围内可以被保存在一个缓存中，以处理将来相应的请求。

如果响应在缓存中并且正确，则没有必要向服务器请求另一个响应。

这种方法不仅减少了网络带宽需求，而且还加快了速度。

服务器有一种机制来评估响应信息保持有效的最短时间。

那就意味着，服务器确定哪个特定响应消息的过期时间（expiration time）。

因此在这个时间内，可以在不用参考服务器的情况下使用缓存的消息。

考虑一下，如果超过这个时间。

为了能够确认数据是否改变，定义如下认证机制：
9.1过期机制
为了确定数据是否最新，应当确定一个过期时间按。

在大多数情况下，源服务器在特定响应消息中明确地定义过期时间。

如果这样，缓存的数据在过期时间内可以发送给随后的请求。

如果源服务器没有定义任何过期时间。

可以用某些方法来估计/计算一个合理的过期时间（诸如，最后修改（Last-Modified）时间）。

因为这不是从服务器发出的，应当谨慎地使用它们。

9.2验证机制
当超过过期时间时，数据有可能变得失效。

为了确保响应消息的验证，缓存必须检查源服务器（或者可能是一个具有最新响应的中间缓存），确认响应消息是否仍然可用。

HTTP 1.1为此提供了条件性方法。

当一个源服务器发送一个完整的响应时，它把某种验证器附加到消息上。

然后用户代理或者代理缓存将把它作为缓存验证器。

客户端（用户代理或者代理缓存）产生一个附有缓存验证器的条件请求。

然后服务器评估消息并用一个没有实体的特殊代码（通常是304（未修改））做出响应。

否则服务器发送完整的响应（包括实体）。

这种方法不仅在验证器不匹配的情况下避免了额外的往返时间，而且在验证器匹配的情况下避免了发送完整的响应。