Http协议讲解

《Http协议讲解》由会员分享，可在线阅读，更多相关《Http协议讲解（10页珍藏版）》请在金锄头文库上搜索。

1、了解 WWW 效劳与 协议/上网工作原理(图)历史上，先后问世了多个具有重大社会影响的电子通信技术。第一个这样的技术是 19 世纪 70 年月制造的 。 使得不在同一物理位置的两人得以实时地口头沟通。它对社会有重大的影响有好的也有坏的。下一个电子通信技术是 20 世纪 20 年月及 30 年月问世的播送收音机/电视机。播送收音机/电视机使得人们能收听收视大量的音频和视频信息。它对社会同样有重大的影响有好的也有坏的。转变了人们的生活与工作方式的第三个重大通信技术是 web。web 最吸引用户的或许是它的随选(on demand)操作性。用户只在想要时收到所要的东西。这一点不同于播送收音机/电视机

2、。播送收音机/电视机的用户是在其内容供给商播出内容期间被迫收听收视。除了随选操作性，Web 还有很多大家宠爱的其他精彩特性。任何个人都可以极其简洁地在 Web 上公布任何信息;任何人都可能以极低的本钱成为发行人。超链接和搜寻引擎挂念我们在 Web 站点的海洋中导航。图形和动画刺激着我们的感官。表单、Java 小应用程序、Activex 控件 以及其他很多设备使得我们能与 Web 页面和站点交互。Web 还越来越普遍地供给存放在因特网中的、可随选访问(即点播)的大量音频和视频材料的菜单接口。 概貌Web 的应用层协议 是Web 的核心。 在 Web 的客户程序和效劳器程序中得以实现。运行在不同端

3、系统上的客户程序和效劳器程序通过交换 消息彼此沟通。 定义这些消息的构造以及客户和效劳器如何交换这些消息。在具体解释 之前，我们先来回忆一些web 中的术语。Web 页面(web page，也称为文档)由多个对象构成。对象(object)仅仅是可由单个URL 寻址的文件， 例如 HTML 文件、JPG 图像、GIF 图像、JAVA 小应用程序、语音片段等。大多数Web 页面由单个根本HIML 文件和假设干个所引用的对象构成。例如，假设一个 Web 页面包含HTML 文本和 5 个 JPEG 图像，那么它由 6 个对象构成，即根本 H1ML 文件加 5 个图像。根本HTML 文件使用相应的URL

4、 来引用本页面的其他对象。每个 URL 由存放该对象的效劳器主机名和该对象的路径名两局部构成。例如，在如下的URL 中: chinaitlab /urlpath/picture.qif chinaitlab 是一个主机名，/urlpath/picture.qif 是一个路径名。扫瞄器是 web 的用户代理，它显示所恳求的 Web 页面，并供给大量的导航与配置特性。Web 扫瞄器还实现 的客户端，因此在web 上下文中，我们会从进程意义上互换使用“扫瞄器”和“客户”两词。流行的Web 扫瞄器有Netscape Com municator，firefox 和微软的IE 等。Web 效劳器存放可由U

5、RL 寻址的 Web 对象。web 效劳器还实现 的效劳器端。流行的 Web 效劳器有Apache、微软的IIS 以及Netscape Enterprise Server。Netcraft 供给了 web 效劳器的概要剖析Netcrft 2000。 定义Web 客户(即扫瞄器)如何从 web 效劳器恳求Web 页面，以及效劳器如何把Web 页面传送给客户。以下图呈现了这种恳求响应行为。当用户恳求一个 Web 页面(譬如说点击某个超链接)时，扫瞄器把恳求该页面中各个对象的 恳求消息发送给效劳器。效劳器收到恳求后，以运送含有这些对象 响应消息作为响应。到 1997 年底，根本上全部的扫瞄器和Web

6、 效劳器软件都实现了在RFC 1945 中定义的 /1.0 版本。1998 年初，一些Web 效劳器软件和扫瞄器软件开头实现在RFC 2616 中定义的 /1.1 版本。H1TP/1.1 与 /1.0 后向兼容;运行 1.1 版本的web 效劳器可以与运行 1.0 版本的扫瞄器“对话”，运行1.1 版本的扫瞄器也可以与运行 1.0 版本的Web 效劳器“对话”。图 1 恳求与响应行为 /1.0 和 /1.1 都把TCP 作为底层的传输协议。 客户首先发起建立与效劳器TCP 连接。一旦建立连接，扫瞄器进程和效劳器进程就可以通过各自的套接字来访问 TCP。如前所述，客户端套接字是客户进程和 TCP

7、 连接之间的“门”，效劳器端套接字是效劳器进程和同一TCP 连接之间的“门”。客户往自己的套接字发送 恳求消息，也从自己的套接字接收 响应消息。类似地，效劳器从自己的套接字接收 恳求消息，也往自己的套接字发送 响应消息。客户或效劳器一旦把某个消息送入各自的套接字，这个消息就完全落入 TCP 的把握之中。TCP 给 供给一个牢靠的数据传输效劳;这意味着由客户发出的每个 恳求消息最终将无损地到达效劳器，由效劳器发出的每个 响应消息最终也将无损地到达客户。我们可从中看到分层网络体系构造的一个明显优势 不必担忧数据会丧失，也无需关心 TCP 如何从数据的丧失和错序中恢复出来的细节。这些是TCP 和协议

8、栈中更低协议层的任务。TCP 还使用一个拥塞把握机制。该机制迫使每个新的TCP 连接一开头以相对缓慢的速率传输数据，然而只要网络不拥塞，每个连接可以快速上升到相对较高的速率。这个慢速传输的初始阶段称为缓启动(slo w start)。需要留意的是，在向客户发送所恳求文件的同时，效劳器并没有存储关于该客户的任何状态信息。即便某个客户在几秒钟内再次恳求同一个对象，效劳器也不会响应说:自己刚刚给它发送了这个对象。相反， 效劳器重新发送这个对象，由于它已经彻底遗忘早先做过什么。既然 效劳器不维护客户的状态信息， 我们于是说 是一个无状态的协议(stateless protocol)。非长久连接和长久连

9、接 既可以使用非长久连接(nonpersistent connection)，也可以使用长久连接(persistent connec tion)。 /1.0 使用非长久连接， /1.1 默认使用长久连接。非长久连接让我们查看一下非长久连接状况下从效劳器到客户传送一个 Web 页面的步骤。假设该贝面由 1 个根本HTML 文件和 10 个 JPEG 图像构成，而且全部这些对象都存放在同一台效劳器主机中。 再假设该根本 HTML 文件的 URL 为: chinaitlab /somepath/index.html。下面是具体步骡:1. 客户初始化一个与效劳器主机 chinaitlab 中的 效劳器

10、的 TCP 连接。 效劳器使用默认端口号 80 监听来自 客户的连接建立恳求。2. 客户经由与TCP 连接相关联的本地套接字发出个 恳求消息。这个消息中包含路径名/so mepath/index.html。3. 效劳器经由与TCP 连接相关联的本地套接字接收这个恳求消息，再从效劳器主机的内存或硬盘中取出对象/somepath/index.html，经由同一个套接字发出包含该对象的响应消息。4. 效劳器告知TCP 关闭这个TCP 连接(不过TCP 要到客户收到刚刚这个响应消息之后才会真正终止这个连接)。5. 客户经由同一个套接字接收这个响应消息。TCP 连接随后终止。该消息标明所封装的对象是一个

11、 HTML 文件。客户从中取出这个文件，加以分析后觉察其中有 10 个 JPEG 对象的引用。6. 给每一个引用到的JPEG 对象重复步骡 1-4。扫瞄器在接收 web 页面的同时把它显示给用户。不同的扫瞄器可能会以略有不同的方式解释(也就是向用户显示)同一个 web 页面。 与客户如何解释Web 页面没有任何关系，其标准(RFC 1945和RFC 261 6I)仅仅定义 客户程序和效劳器程序之间的通信协议。上述步骤之所以称为使用非长久连接，缘由是每次效劳器发出一个对象后，相应的 TCP 连接就被关闭， 也就是说每个连接都没有持续到可用于传送其他对象。每个 TCP 连接只用于传输一个恳求消息和

12、一个响应消息。就上述例子而言，用户每恳求一次那个 web 页面，就产生 11 个 TCP 连接。在上述步骡中，我们有意不说清客户是通过 10 个串行的TCP 连接先后取得全部JPEG 对象，还是通过并行的 TCP 连接同时取得其中某些JPEG 对象。实际上，现今的扫瞄器允许用户通过配置来把握并行连接的程度。大多数扫瞄器默认可以翻开 5 到 10 个并行的TCP 连接，每个连接处理一个恳求响应事务。用户要是宠爱，可以把最大并行连接数设为l，那样的话这 10 个连接是串行地建立的。我们将在第 3 章看到，使用并行连接可以缩短响应时间。连续介绍之前，先估算一下从客户恳求根本 HTML 文件到它收到该

13、文件所经受的时间。为此我们定义往返时间(round trip time，简称RTT)，它是一个小分组从客户主机游动到效劳器主机再返回客户主机所花的时间。RTT 包括分组传播延迟、在中间路由器和交换机土的分组排队延迟以及分组处理延迟。下面考虑用户点击某个超链接时会发生什么。用户的点击导致扫瞄器发起建立一个与 Web 效劳器的TCP 连接;这里涉及次“三次握手”过程首先是客户向效劳器发送一个小的冗余消息，接着是效劳器向客户确认并响应以一个小的 TCP 消息，最终是客户向效劳器回确认。三次握手过程的前两次完毕时，消逝的时间为 1 个 RTT。此时客户把 恳求消息发送到TCP 连接中，客户接着把三次握

14、手过程最终一次中确实认捎带在包含这个消息的数据分节中发送以去。效劳器收到来自 TCP 连接的恳求消息后，把相应的 HTML 文件发送到TCP 连接中，效劳器接着把对早先收到的客户恳求确实认捎带在包含该HTML 文件的数据分节中发送出去。这个 恳求顺应交互也花去 1 个RTT 时间。因此，总的响应时间粗略地算是 2 个RTT 加上效劳器发送这个 HTMI 文件的时间。长久连接非长久连接有些缺点。首先，客户得为每个待恳求的对象建立并维护一个新的连接。对于每个这样的连接，TCP 得在客户端和效劳器端安排TCP 缓冲区，并维持TCP 变量。对于有可能同时为来自数百个不同客户的恳求供给效劳的 web 效

15、劳器来说，这会严峻增加其负担。其次，如前所述，每个对象都有 2 个RTT 的响应延长一个 RTT 用于建立TCP 连接，另个RTT 用于恳求和接收对象。最终，每个对象都患病TC P 缓启动，由于每个 TCP 连接都起始于缓启动阶段。不过并行TCP 连接的使用能够局部减轻RTT 延迟和缓启动延迟的影响。在长久连接状况下，效劳器在发出响应后让 TCP 连接连续翻开着。同一对客户/效劳器之间的后续恳求和响应可以通过这个连接发送。整个 Web 页面(上例中为包含一个根本HTMLL 文件和 10 个图像的页面)自不用说可以通过单个长久TCP 连接发送:甚至存放在同一个效劳器中的多个web 页面也可以通过单个长久TCP 连接发送。通常， 效劳器在某个连接闲置一段特定时间后关闭它，而这段时间通常是可以配置的。长久连接分为不带流水线(without pipelining)和带流水线(with pipelinin