了解WWW服务和HTTP协议.docx
《了解WWW服务和HTTP协议.docx》由会员分享，可在线阅读，更多相关《了解WWW服务和HTTP协议.docx（9页珍藏版）》请在冰豆网上搜索。
了解WWW服务和HTTP协议
历史上，先后问世了多个具有重大社会影响的电子通信技术。
第一个这样的技术是19世纪70年代发明的电话。
电话使得不在同一物理位置的两人得以实时地口头交流。
它对社会有重大的影响——有好的也有坏的。
下一个电子通信技术是20世纪20年代及30年代问世的广播收音机/电视机。
广播收音机/电视机使得人们能收听收视大量的音频和视频信息。
它对社会同样有重大的影响——有好的也有坏的。
改变了人们的生活与工作方式的第三个重大通信技术是web。
web最吸引用户的也许是它的随选（ondemand）操作性。
用户只在想要时收到所要的东西。
这一点不同于广播收音机/电视机。
广播收音机/电视机的用户是在其内容供应商播出内容期间被迫收听收视。
除了随选操作性，Web还有许多大家喜爱的其他精彩特性。
任何个人都可以极其容易地在Web上公布任何信息;任何人都可能以极低的成本成为发行人。
超链接和搜索引擎帮助我们在Web站点的海洋中导航。
图形和动画刺激着我们的感官。
表单、Java小应用程序、Activex控件以及其他许多设备使得我们能与Web页面和站点交互。
Web还越来越普遍地提供存放在因特网中的、可随选访问（即点播）的大量音频和视频材料的菜单接口。
HTTP概貌
Web的应用层协议HTTP是Web的核心。
HTTP在Web的客户程序和服务器程序中得以实现。
运行在不同端系统上的客户程序和服务器程序通过交换HTTP消息彼此交流。
HTTP定义这些消息的结构以及客户和服务器如何交换这些消息。
在详细解释HTTP之前，我们先来回顾一些web中的术语。
Web页面（webpage，也称为文档）由多个对象构成。
对象（object）仅仅是可由单个URL寻址的文件，例如HTML文件、JPG图像、GIF图像、JAVA小应用程序、语音片段等。
大多数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的延迟（而
升级会员 