Http协议讲解Word下载.docx
《Http协议讲解Word下载.docx》由会员分享，可在线阅读，更多相关《Http协议讲解Word下载.docx（11页珍藏版）》请在冰豆网上搜索。
大多数Web页面由单个基本HIML文件和若干个所引用的对象构成。
例如，如果一个Web页面包含HTML文本和5个JPEG图像，那么它由6个对象构成，即基本H1ML文件加5个图像。
基本HTML文件使用相应的URL来引用本页面的其他对象。
每个URL由存放该对象的服务器主机名和该对象的路径名两部分构成。
例如，在如下的URL中:
是一个主机名，/urlpath/picture.qif是一个路径名。
浏览器是web的用户代理，它显示所请求的Web页面，并提供大量的导航与配置特性。
Web浏览器还实现HTTP的客户端，因此在web上下文中，我们会从进程意义上互换使用“浏览器”和“客户”两词。
流行的Web浏览器有NetscapeCommunicator，firefox和微软的IE等。
Web服务器存放可由URL寻址的Web对象。
web服务器还实现HTTP的服务器端。
流行的Web服务器有Apache、微软的IIS以及NetscapeEnterpriseServer。
Netcraft提供了web服务器的概要剖析[Netcrft2000]。
HTTP定义Web客户（即浏览器）如何从web服务器请求Web页面，以及服务器如何把Web页面传送给客户。
下图展示了这种请求—响应行为。
当用户请求一个Web页面（譬如说点击某个超链接）时，浏览器把请求该页面中各个对象的HTTP请求消息发送给服务器。
服务器收到请求后，以运送含有这些对象HTTP响应消息作为响应。
到1997年底，基本上所有的浏览器和Web服务器软件都实现了在RFC1945中定义的HTTP/1.0版本。
1998年初，一些Web服务器软件和浏览器软件开始实现在RFC2616中定义的HTTP/1.1版本。
H1TP/1.1与HTTP/1.0后向兼容;
运行1.1版本的web服务器可以与运行1.0版本的浏览器“对话”，运行1.1版本的浏览器也可以与运行1.0版本的Web服务器“对话”。
图1HTTP请求与响应行为
HTTP/1.0和HTTP/1.1都把TCP作为底层的传输协议。
HTTP客户首先发起建立与服务器TCP连接。
一旦建立连接，浏览器进程和服务器进程就可以通过各自的套接字来访问TCP。
如前所述，客户端套接字是客户进程和TCP连接之间的“门”，服务器端套接字是服务器进程和同一TCP连接之间的“门”。
客户往自己的套接字发送HTTP请求消息，也从自己的套接字接收HTTP响应消息。
类似地，服务器从自己的套接字接收HTTP请求消息，也往自己的套接字发送HTTP响应消息。
客户或服务器一旦把某个消息送入各自的套接字，这个消息就完全落入TCP的控制之中。
TCP给HTTP提供一个可靠的数据传输服务;
这意味着由客户发出的每个HTTP请求消息最终将无损地到达服务器，由服务器发出的每个HTTP响应消息最终也将无损地到达客户。
我们可从中看到分层网络体系结构的一个明显优势——HTTP不必担心数据会丢失，也无需关心TCP如何从数据的丢失和错序中恢复出来的细节。
这些是TCP和协议栈中更低协议层的任务。
TCP还使用一个拥塞控制机制。
该机制迫使每个新的TCP连接一开始以相对缓慢的速率传输数据，然而只要网络不拥塞，每个连接可以迅速上升到相对较高的速率。
这个慢速传输的初始阶段称为缓启动（slowstart）。
需要注意的是，在向客户发送所请求文件的同时，服务器并没有存储关于该客户的任何状态信息。
即便某个客户在几秒钟内再次请求同一个对象，服务器也不会响应说:
自己刚刚给它发送了这个对象。
相反，服务器重新发送这个对象，因为它已经彻底忘记早先做过什么。
既然HTTP服务器不维护客户的状态信息，我们于是说HTTP是一个无状态的协议（statelessprotocol）。
非持久连接和持久连接
HTTP既可以使用非持久连接（nonpersistentconnection），也可以使用持久连接（persistentconnection）。
HTTP/1.0使用非持久连接，HTTP/1.1默认使用持久连接。
非持久连接
让我们查看一下非持久连接情况下从服务器到客户传送一个Web页面的步骤。
假设该贝面由1个基本HTML文件和10个JPEG图像构成，而且所有这些对象都存放在同一台服务器主机中。
再假设该基本HTML文件的URL为:
下面是具体步骡:
1.HTTP客户初始化一个与服务器主机中的HTTP服务器的TCP连接。
HTTP服务器使用默认端口号80监听来自HTTP客户的连接建立请求。
2.HTTP客户经由与TCP连接相关联的本地套接字发出—个HTTP请求消息。
这个消息中包含路径名/somepath/index.html。
3.HTTP服务器经由与TCP连接相关联的本地套接字接收这个请求消息，再从服务器主机的内存或硬盘中取出对象/somepath/index.html，经由同一个套接字发出包含该对象的响应消息。
4.HTTP服务器告知TCP关闭这个TCP连接（不过TCP要到客户收到刚才这个响应消息之后才会真正终止这个连接）。
5.HTTP客户经由同一个套接字接收这个响应消息。
TCP连接随后终止。
该消息标明所封装的对象是一个HTML文件。
客户从中取出这个文件，加以分析后发现其中有10个JPEG对象的引用。
6.给每一个引用到的JPEG对象重复步骡1-4。
浏览器在接收web页面的同时把它显示给用户。
不同的浏览器可能会以略有不同的方式解释（也就是向用户显示）同一个web页面。
HTTP与客户如何解释Web页面没有任何关系，其规范（[RFC1945]和[RFC2616I）仅仅定义HTTP客户程序和服务器程序之间的通信协议。
上述步骤之所以称为使用非持久连接，原因是每次服务器发出一个对象后，相应的TCP连接就被关闭，也就是说每个连接都没有持续到可用于传送其他对象。
每个TCP连接只用于传输一个请求消息和一个响应消息。
就上述例子而言，用户每请求一次那个web页面，就产生11个TCP连接。
在上述步骡中，我们有意不说清客户是通过10个串行的TCP连接先后取得所有JPEG对象，还是通过并行的TCP连接同时取得其中某些JPEG对象。
实际上，现今的浏览器允许用户通过配置来控制并行连接的程度。
大多数浏览器默认可以打开5到10个并行的TCP连接，每个连接处理一个请求—响应事务。
用户要是喜欢，可以把最大并行连接数设为l，那样的话这10个连接是串行地建立的。
我们将在第3章看到，使用并行连接可以缩短响应时间。
继续介绍之前，先估算一下从客户请求基本HTML文件到它收到该文件所经历的时间。
为此我们定义往返时间（roundtriptime，简称RTT），它是一个小分组从客户主机游动到服务器主机再返回客户主机所花的时间。
RTT包括分组传播延迟、在中间路由器和交换机土的分组排队延迟以及分组处理延迟。
下面考虑用户点击某个超链接时会发生什么。
用户的点击导致浏览器发起建立一个与Web服务器的TCP连接;
这里涉及·
—次“三次握手”过程——首先是客户向服务器发送一个小的冗余消息，接着是服务器向客户确认并响应以一个小的TCP消息，最后是客户向服务器回确认。
三次握手过程的前两次结束时，流逝的时间为1个RTT。
此时客户把HTTP请求消息发送到TCP连接中，客户接着把三次握手过程最后一次中的确认捎带在包含这个消息的数据分节中发送以去。
服务器收到来自TCP连接的请求消息后，把相应的HTML文件发送到TCP连接中，服务器接着把对早先收到的客户请求的确认捎带在包含该HTML文件的数据分节中发送出去。
这个HTTP请求顺应交互也花去1个RTT时间。
因此，总的响应时间粗略地算是2个RTT加上服务器发送这个HTMI文件的时间。
持久连接
非持久连接有些缺点。
首先，客户得为每个待请求的对象建立并维护一个新的连接。
对于每个这样的连接，TCP得在客户端和服务器端分配TCP缓冲区，并维持TCP变量。
对于有可能同时为来自数百个不同客户的请求提供服务的web服务器来说，这会严重增加其负担。
其次，如前所述，每个对象都有2个RTT的响应延长——一个RTT用于建立TCP连接，另—个RTT用于请求和接收对象。
最后，每个对象都遭受TCP缓启动，因为每个TCP连接都起始于缓启动阶段。
不过并行TCP连接的使用能够部分减轻RTT延迟和缓启动延迟的影响。
在持久连接情况下，服务器在发出响应后让TCP连接继续打开着。
同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。
整个Web页面（上例中为包含一个基本HTMLL文件和10个图像的页面）自不用说可以通过单个持久TCP连接发送:
甚至存放在同一个服务器中的多个web页面也可以通过单个持久TCP连接发送。
通常，HTTP服务器在某个连接闲置一段特定时间后关闭它，而这段时间通常是可以配置的。
持久连接分为不带流水线（withoutpipelining）和带流水线（withpipelining）两个版本。
如果是不带流水线的版本，那么客户只在收到前一个请求的响应后才发出新的请求。
这种情况下，web页面所引用的每个对象（上例中的10个图像）都经历1个RTT的延迟，用于请求和接收该对象。
与非持久连接2个RTT的延迟相比，不带流水线的持久连接已有所改善，不过带流水线的持久连接还能进一步降低响应延迟。
不带流水线版本的另一个缺点是，服务器送出一个对象后开始等待下一个请求，而这个新请求却不能马上到达。
这段时间服务器资源便闲置了。
HTTP/1.1的默认模式使用带流水线的持久连接。
这种情况下，HTTP客户每碰到一个引用就立即发出一个请求，因而HTTP客户可以一个接一个紧挨着发出各个引用对象的请求。
服务器收到这些请求后，也可以一个接一个紧挨着发出各个对象。
如果所有的请求和响应都是紧挨着发送的，那么所有引用到的对象一共只经历1个RTT的延迟（而不是像不带流水线的版本那样，每个引用到的对象都各有1个RTT的延迟）。
另外，带流水线的持久连接中服务器空等请求的时间比较少。
与非持久连接相比，持久连接（不论是否带流水线）除降低了1个RTT的响应延迟外，缓启动延迟也比较小。
其原因在于既然各个对象使用同一个TCP连接，服务器发出第一个对象后就不必再以一开始的缓慢速率发送后续对象。
相反，服务器可以按照第一个对象发送完毕时的速率开始发送下一个对象。
HTTP消息格式
HTTP规范1.0[RPcl945]和1.1[RFC2616]定义了HTTP消息的格式。
HTTP消息分为请求消息和响应稍息两类。
下面我们分别进行介绍。
HTTP请求消息
下面是一个典型的HTTP请求消息:
GET/somedir/page.htmlH7TP/1.1
Host:
Connection:
close
User-agent:
Mozilla/4.0
Accept-language:
zh-cn
（额外的回车符和换行符）
仔细检查这个简单的请求消息，我们可从中学到不少东西。
首先，这个消息是用普通的ASCII文本书写的。
其次，这个消息共有5行（每行以一个回车符和一个换行符结束），最后一行后面还有额外的一个回车特和换行符。
当然，一个请求消息可以不止这么多行，也可以仅仅只有一行。
该请求消息的第一行称为请求行（requestline），后续各行都称为头部行（header）。
请求行有3个宁段:
方法字段、URL字段、HTTP版本宇段。
方法字段有若干个值可供选择，包括GET、POST和HEAD。
HTTP请求消息绝大多数使用GET方法，这是浏览器用来请求对象的方法，所请求的对象就在URL字段中标识。
本例表明浏览器在请求对象/somedir/page.html。
版本字段是不言自明的;
本例中浏览器实现的是HTTP/1.1版本。
现在看一下本例中的各个头部行。
头部行Host:
定存放所请求对象的主机。
请求消息中包含头部Connection:
close是在告知服务器本浏览器不想使用持久连接;
服务器发出所请求的对象后应关闭连接。
尽管产生这个请求消息的浏览器实现的是HTTP/1.1版本，它还是不想使用持久连接。
User-agent头部行指定用户代理，也就是产生当前请求的浏览器的类型。
本例的用户代理是Mozilla/4.0，它是Nelscape浏览器的一个版本。
这个头部行很有用，因为服务器实际上可以给不同类型的用户代理发送同一个对象的不同版本（这些不同版本位用同一个URL寻址）。
最后，Accept-languag:
头部行指出要是所请求对象有简体中文版本，那么用户宁愿接收这个版本;
如果没有这个语言版本，那么服务器应该发送其默认版本。
Accept-languag:
仅仅是HTTP的众多内容协商头部之一。
我们接着看一下下图所示的请求消息的一般格式。
图2:
HTTP请求格式
上面的请求消息例子符合这个格式，不过一般格式中还有一个位于各个头部（及额外的回车符和换行符）之后的“附属体”（毗叮body）。
附属体不在GET方法中使用，而是在POST方法中使用。
POST方法适用于需由用户填写表单的场合，如往google搜索引擎中填入待搜索的词。
用户提交表单后，浏览器就像用户点击了超链接那样仍然从服务器请求一个Web页面，不过该页面的具体内容却取决于用户填写在表单各个字段中的值。
如果浏览器使用POST方法提出该请求，那么请求消息附属体中包含的是用户填写在表单各个字段中的值。
与GET方法类似的是HEAD方法，两者的差别只是服务器在对HEAD方法的响应消息中去掉了所请求的对象，其他内容则与对GET方法的响应消息一样。
HEAD方法通常用于HTTP服务器软件开发人员进行调试。
HTTP响应消息
下面是一个典型的HTTP响应消息:
HTTP/1.12000K
Connectlon:
Date:
Thu,13Oct200503:
17:
33GMT
Server:
Apache/2.0.54（Unix）
Last—Nodified:
Mon,22Jun199809;
23;
24GMT
Content—Length:
682l
Content—Type:
text/html
（数据数据数据数据数据…………）
这个响应消息分为3部分：
1个起始的状态行（statusline），6个头部行、1个包含所请求对象本身的附属体。
状态行有3个字段:
协议版本字段、状态码字段、原因短语字段。
本例的状态行表明，服务器使用HTTP/1.1版本，响应过程完全正常（也就是说服务器找到了所请求的对象，并正在发送）。
服务器使用Connectlon:
close头部行告知客户自己将在发送完本消息后关闭TCP连接。
Date:
头部行指出服务器创建并发送本响应消息的日期和时间。
注意，这并不是对象本身的创建时间或最后修改时间，而是服务器把该对象从其文件系统中取出，插入响应消息中发送出去的时间。
Server:
头部行指出本消息是由Apache服务器产生的;
它与HTTP请求消息中的User-agent:
头部行类似。
Last—Nodified:
头部行指出对象本身的创建或最后修改日期或时间。
头部对于对象的高速缓存至关重要，且不论这种高速缓存是发生在本地客户主机上还是发生在网络高速缓存服务器主机（也就是代理服务器主机）上。
Content—Length:
头部行指出所发送对象的字节数。
Content—Type:
头部行指出包含在附属体中的对象是HTML文本。
对象的类型是由Content—Type:
头部而不是由文件扩展名正式指出的。
注意，如果服务器收到一个HTTP/1.0的请求，那么它即使是一个HTTP/1.1服务器，也不会使用持久连接。
相反，这样的HTTP/1.1服务器会在发出所请求的对象后关闭TCP连接。
这么做是必要的，因为HTTP/1.0客户期待服务器马上关闭连接。
我们接着看一下如下图所示的响应消息的一般格式。
前面的响应消息例子完全符合这个格式。
响应消息中的状态码和原因短语指示相应请求的处理结果，下面列出了一些常见的状态码和相应的原因短语:
图3:
响应消息的一般格式
●2000K;
请求成功，所请求信息在响应消息中返回。
●301MovedPermanently:
所请求的对象己永久性迁移;
新的URL在本响应消息的Location:
头部指出。
客户软件会自动请求这个新的URL。
●400BadRequest;
表示服务器无法理解相应请求的普通错误的状态码
●404NotFound:
服务器上不存在所请求的文档。
●HTTPVersionNotSupport:
服务器不支持所请求的HTTP协议版本。
你想如何看到一个真实的H1TP应答消息呢?
这非常简单。
可以使用nc工具连接到你喜欢的服务器（nc/netcat是一个黑客很喜欢用的工具，可以方便在主机之间建立TCP连接），然后输入一行请求消息，用来请求位于该服务器上的某个对象。
例如，如果你可以输入以下指令:
nc80
GET/index.shtml HTTP/1.0
（在输入第二行之后，敲两次回车），这就打开了一个到主机的端口80的TCP连接，然后发送HTTPGET命令。
你应该能看到包含着YESKY主页的基本HTML文件的应苔消息。
如果你想只看到HTTP消息行而不接收该对象本身，那么就把上面的GET换成HEAD。
最后，看一下能得到什么样的应答消息。
在这里我们讨论了大量能够在HTTP请求和应答消息中使用的头部行。
HTTP规范（尤其是HTTP/1.1）定义了更多可以由浏览器、Web服务器和网络缓冲服务器插入的头部行。
我们可以便用nc工具完全控制在请求消息中包含哪些头部，那么浏览器如何决定该在请求消息个包含哪些头部呢?
Web服务器又是如何决定该在响应消息中包含哪些头部?
浏览器是根据自己的用户代理类型、所支持的HTTP版本（HTTP/1.0版本的浏览器自然不会产生HTTP/1.1版本的头部）、用户对浏览器的配置（如所偏爱的语言）等因素生成请求消息中的各个头部的。
web服务器有类似的情形:
它们有不同的产品、版本和配置，所有这些因素都会影响在响应消息中包含哪些头部。
本文讨论过的和即将讨论的用于HTTP请求消息和响应消息中的头部仅仅是很小的一部分，HTTP规范中定义了更多可用的头部，可以查阅相关的RFC文档进行更详细的了解。
用户—服务器交互
身份认证和cookie
我们已经知道HTTP服务器是无状态的。
这样的处理可以简化服务器程序的设计，以便开发出更高性能的Web服务器软件。
然而，一个Web站点往往有标识其用户的需求，因为其web服务器可能希望限制用户的访问，也可能想要根据用户的身份来提供内容。
HTTP提供了两种帮助服务器标识用户的机制:
身份认证和cookle。
身份认证许多web站点要求用户提供一个用户名—口令对才能访问存放在其服务器中的文档。
这种要求称为身份认证（authentication）。
HTTP提供特殊的状态码和头部来帮助Web站点执行身份认证。
我们通过查看一个例子来领会这些特殊的状态码和头部如何工作。
假设有—个客户在请求来自某个服务器的一个对象，而该服务器要求用户授予权限。
客户首先发送一个不合特殊头部的普通请求消息。
服务器以空的附属体和一个“401AuthorizationRequired”状态码作为响应。
服务器还在这个响应消息中包含“个WWW-Authenticate:
头部，说明具体如何执行身份认证。
这个头部的典型值是指出用户需要提供一个用户名—口令对。
客户收到这个响应消息后提示用户输入用户名和口令，然后重新发送请求消息。
这一回客户在请求消息中包含了一个Authorization:
头部，其中包含有用户输入的用户名和口令。
取得第一个对象后，客户在同为请求该服务器上对象的后续请求中继续发送这个用户名—口令对。
这个做法一般将持续到用户关闭浏览器为止。
在浏览器未被关闭之前，这个用户名—口令对是高速缓存着的，因此浏览器不会每请求一个对象就提示用户输入一次用户名和口令。
通过上述方式，要求用户授权的Web站点就能标识出每个请求的用户了。
我们需要知道，HTTP执行的是一种相当脆弱的身份认证方式，不难攻破。
现代有很多更为安全的认证方式，我们会在以后介绍。
cookie是一种可让Web站点用来跟踪用户的候选机制，定义在RFC2109中。
有些Web站点使用cookie，其他Web站点则不用。
下面查看一个例子。
假设一个客户首次联系一个使用cookie的web站点。
服务器会在其响应中包含一个Set—Cookie:
头部。
该头部的值可以是一个由Web服务器产生的客户标
升级会员 