《超文本传输协议中文》由会员分享，可在线阅读，更多相关《超文本传输协议中文（6页珍藏版）》请在金锄头文库上搜索。
1、应用层超文本传输协议（HTTP） 、前言TCP/IP应用层协议有许多种，本文档讲解我们最熟悉的超文本传输协议（HTTP）。超文本传输协议（HTTP）版本1.1是一个草案标准，其描述见RFC 2612。旧的HTTP 1.0是一个指示 性协议， RFC 1945 对它进行了描述。超文本传输协议是为了传输超文本标记语言（ Hypertext Markup Language，HTML）而设计的协议。HTML是一种用于创建超文本文档的标记语言。有关HTML的信息请 参见相关的超文本标记语言的书籍。、HTTP 综述HTTP 基于请求响应活动。客户端运行浏览器应用程序，它建立与服务器的连接，并以请求的形式
2、发送一个请求到服务器。服务器用一个状态行做出响应，包括信息的协议版本以及成功或者错误代码，后 面跟着一个消息，它包含服务器信息、实体信息和可能的内容。HTTP事务被划分为如下4个步骤。測览器除了实验性应用程序之外，现行习惯要求客户在发出每个请求之前先建立连接，并由服务器在发送响 应之后关闭连接。客户和服务器都应当注意任何一方都有可能过早地关闭连接，原因可能是用户操作、自 动超时或者程序故障等，他们应当以一种可预见的并且所期望的方式处理这种关闭行为。在任何一种情况 下，任何一方或者双方关闭的连接总是终止当前请求，而不管它的状态如何。简单的说HTTP是一种无状 态协议，因为它不跟踪连接。例如：为了
3、装入包含两个图形的页面，支持图形的浏览器将打开三个 TCP 连接：一个连接用于页面，而另外连个连接用于图形。然而大多数浏览器能够同时处理几个这样的连接。如果一个页面包含大量要素，每个资源都新建一个TCP连接，这将占用大量资源。在HTTP1.1中缓 和了这个问题，它为每种类型元素建立一个TCP连接，同样类型的元素使用同一个TCP连接。HTTP 1.1 不同于HTTP 1.0的地方就是它使用了永久连接。三、统一资源标识 URIURI亦可称为web地址，是统一资源定位器（URL）和统一资源名称（URN）的组合。依照RFC 1945 种的定义，“统一资源标识符是通过名称、位置或者其他的特征标识资源的简
4、单格式字符串”。HTTP 消息类型HTTP消息既可以是客户端请求也可以是服务器响应。下面说明了 HTTP消息类型:HTTP-message = Request | Response五、消息头HTTP消息头字段为如下形式之一： 一般报文头 请求报文头 响应报文头 实体报文头 消息体：如果未使用传输编码，可以把消息体称为实体。 消息长度5.1 一般报文头一般报文头字段既可以用于请求消息，又可以用于响应消息。当前的一般报文头字段选项如下 缓存控制（ Cach-Control） 连接 日期 标记（ Pragma） 传输编码（ Transfer-Encoding） 升级（ Upgrade） 通过（ Vi
5、a）六、HTTP方法HTTP方法是HTTP客户机向服务器发出的命令。HTTP 1.0版本仅定义了三种方法如下表，HTTP1.1 版本对其作了扩充。方法描述GET提取请求中包含的URI所标识的信息HEAD提取与目标URI相关的元信息POST发送数据到HTTP服务器（数据应该作为请求中包含的URI所标识的源的一个新从属）OPTIONS确定与资源相关的选项和（或）要求或者服务器的功能PUT发送数据到HTTP服务器（数据应该存储于POST请求中指明的URI）DELETE删除DELETE请求中URI定义的资源TRACE调用请求消息的远程应用层回送，允许客户机看到是哪一个服务器从客户机接收CONNECT用
6、于连接到一个代理设备并且通过代理到达最终节点（例如：SSL通道）七、状态码HTTP服务器发送状态码以指出请求的成功或者失败。HTTP 1.1版本定义的HTTP状态码如下:状态码定义1xx:报告类100继续101关闭协议2xx：成功类200认可，同意201已建立202已接受203不可信信息204无内容205复位内容206部分内容3xx :重定向类300多重选择301永久被移动302已找到303参见304未修改305使用代理306（保留）307临时重定向4xx：客户机错误类400错误请求401非授权的402要求付费403禁止404未找到405方法不允许406未被接受407要求代理证明408请求超时
7、409冲突410离开的411要求长度412前提失败413请求实体太大414请求URI太长415不支持的介质类型416请求的范围不满足417预期失败5xx:服务器错误类500服务器内部错501未执行502错误的网关503服务不可用504网关超时505HTTP版本不支持八、访问认证HTTP 提供了一种认证机制，它允许服务器规定资源的访问许可及使用这些资源的客户。认证方法可 以是如下两种之一。8.1 基本认证机制基本认证机制基于用户ID和密码。在这种认证机制中，服务器只在用户ID和密码通过验证时才允许 连接。在基本认证中，用户ID和密码没有加密。他们按Base64格式编码。因此极力推荐使用SSL或者
8、 TLS。82 摘要认证机制(digest authentication scheme)摘要认证机制是对HTTP的扩展，其描述见RFC 2617。在这种认证机制中，用户ID和一个包含密码 的散列值的摘要被发送到服务器。服务器计算一个类似的摘要，如果两个摘要相同则授予对受保护资源的 访问。注意到如果启用摘要认证，在网络上发送的不仅仅是加密密码，这种密码在有正确的密钥下可以被 解密，而且还有一个密码的散列值，这是不能被解密的。因此，与Base64编码密码相比，摘要认证提供 了高级的安全性。可惜的是，摘要认证还没有得到所有浏览的支持。九、HTTP缓存HTTP的重要特征之一就是高速缓存能力。因为HTT
9、P是一个分布式的基于信息的协议，缓存能够显 著地提高性能。 HTTP 1.1协议有许多功能可以有效而正确地使用缓存。在大多数情况下，客户端请求和服务器响应在某个合理的时间范围内可以被保存在一个缓存中，以处 理将来相应的请求。如果响应在缓存中并且正确，则没有必要向服务器请求另一个响应。这种方法不仅减 少了网络带宽需求，而且还加快了速度。服务器有一种机制来评估响应信息保持有效的最短时间。那就意 味着，服务器确定哪个特定响应消息的过期时间（expiration time）。因此在这个时间内，可以在不用参考 服务器的情况下使用缓存的消息。考虑一下，如果超过这个时间。为了能够确认数据是否改变，定义如下认
10、证机制：9.1 过期机制为了确定数据是否最新，应当确定一个过期时间按。在大多数情况下，源服务器在特定响应消息中明 确地定义过期时间。如果这样，缓存的数据在过期时间内可以发送给随后的请求。如果源服务器没有定义任何过期时间。可以用某些方法来估计/计算一个合理的过期时间（诸如，最后 修改（Last-Modified）时间）。因为这不是从服务器发出的，应当谨慎地使用它们。9.2 验证机制当超过过期时间时，数据有可能变得失效。为了确保响应消息的验证，缓存必须检查源服务器（或者 可能是一个具有最新响应的中间缓存），确认响应消息是否仍然可用。 HTTP 1.1为此提供了条件性方法。当一个源服务器发送一个完整的响应时，它把某种验证器附加到消息上。然后用户代理或者代理缓存 将把它作为缓存验证器。客户端（用户代理或者代理缓存）产生一个附有缓存验证器的条件请求。然后服 务器评估消息并用一个没有实体的特殊代码（通常是304（未修改）做出响应。否则服务器发送完整的响 应（包括实体）。这种方法不仅在验证器不匹配的情况下避免了额外的往返时间，而且在验证器匹配的情 况下避免了发送完整的响应。
