了解WWW服务与HTTP协议

《了解WWW服务与HTTP协议》由会员分享，可在线阅读，更多相关《了解WWW服务与HTTP协议（15页珍藏版）》请在装配图网上搜索。

1、历史上，先后问世了多个具有重大社会影响的电子通信技术。第一个这样的技术是 19 世纪 70年 代发明的电话。电话使得不在同一物理位置的两人得以实时地口头交流。它对社 会有重大的影响 有好的也有坏的。下一个电子通信技术是 20世纪 20 年代及 30 年代问 世的广播收音机 / 电视机。广 播收音机 / 电视机使得人们能收听收视大量的音频和视频信息。 它对社会同样有重大的影响有好 的也有坏的。 改变了人们的生活与工作方式的第三个重 大通信技术是 web。 web 最吸引用户的也许 是它的随选（on dema nd）操作性。用户只在想要时收到所要的东西。 这一点不同于广播收音机 /电视机。广播收音

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

3、运行在不同端系统上的客户程序和服务器程序通过交换HTTP 消息彼此交流。 HTTP定义这些消息的结构以及客户和服务器如何交换这些消息。在详细解释HTTP之前，我们先来回顾一些 web 中的术语。Web页面（web page，也称为文档）由多个对象构成。对象（object）仅仅是可由单个URL 寻址的文件，例如HTML文件、JPG图像、GIF图像、JAVA小应用程序、语音片段等。大多数 Web页面由单个基本HIML文件和若干个所引用的对象构成。例如，如果一个Web页面 包含HTML 文本和5个JPEG图像，那么它由6个对象构成，即基本H1ML文件加5个图像。基本HTML文件使 用相应的URL来引

4、用本页面的其他对象。每个URL由存放该对象的服务器主机名和该对象的路径名两部分构成。例如，在如下的URL 中：是一个主机名，/urlpath/picture.qif是一个路径名。浏览器是web的用 户代 理，它显示所请求的Web页面，并提供大量的导航与配置特性。Web浏览器还实现HTTP的客户 端，因此在 web 上下文中，我们会从进程意义上互换使用“浏览器”和“客户”两 词。流行的 Web 浏览器有Netscape Communicator，firefox和微软的IE等。Web服务器存放 可由URL寻址的Web 对象。web服务器还实现HTTP的服务器端。流行的Web服务器有Apache、微

5、软的IIS以及 Netscape Enterprise Server。 Netcraft 提供了 web 服务器的概要剖析 Netcrft2000 。HTTP定义Web客户（即浏览器）如何从web服务器请求Web页面，以及服务器如何把Web 页面传送给客户。下图展示了这种请求一响应行为。当用户请求一个Web页面（譬如说点击某个 超链接）时，浏览器把请求该页面中各个对象的HTTP请求消息发送给服务器。服务器收到请求后，以运送含有这些对象HTTP响应消息作为响应。到1997年底，基本上所有的浏览器和Web服务器软件都实现了在RFC1945中定义的HTTP/1.0版本。1998年初，一些Web 服务

6、器软件和浏览器软件开始实现在RFC2616中定义的HTTP/1.1版本。H1TP/1.1与HTTP/1.0后向兼容；运行1.1版本的web服务器可以与运行1.0版本的浏览器“对话”，运行1.1版本的浏览器也可以与运行1.0版本的Web服务器“对话”。HTTP响阳HrrpiiRbl tiCH.cofn图伯TTP请求与响应行为HTTP/1.0和HTTP/1.1都把TCP作为底层的传输协议。HTTP客户首先发起建立与服务器TCP 连接。一旦建立连接，浏览器进程和服务器进程就可以通过各自的套接字来访问TCP如前所述，客户端套接字是客户进程和TCP连接之间的“门”，服务器端套接字是服务器进程和同一TCP

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

8、任务。TCP 还使用一个拥塞控制机制。该机制迫使每个新的 TCP 连接一开始以相对缓慢的速率 传输数 据，然而只要网络不拥塞，每个连接可以迅速上升到相对较高的速率。这个慢速传输的初始阶段称为缓启动(slow start)。需要注意的是，在向客户发送所请求文件的同时，服务器并没有存储关于该客户的任何状态信息。即便某个客户在几秒钟内再次请求同一个对象，服务器也不会响应说：自己刚刚给它发送了这个对象。相反，服务器重新发送这个对象，因为它已经彻底忘记早先做过什么。既然HTTP服务器不维护客户的状态信息，我们于是说HTTP是一个无状态的协议(statelessprotocol)。非持久连接和持久连接HT

9、TP 既可以使用非持久连接 (nonpersistentconnection) ，也可以使用持久连接 (persistent connection)。HTTP/1.0使用非持久连接，HTTP/1.1默认使用持久连接。非持久连接让我们查看一下非持久连接情况下从服务器到客户传送一个Web 页面的步骤。假设该贝面由1个基本HTML文件和10个JPEG图像构成，而且所有这些对象都存放在同一台服务器主机 中。再假设该基本 HTML 文件的 URL 为:下面是具体步骡 :1. HTTP客户初始化一个与服务器主机 中的HTTP服务器的TCP连接。 HTTP服务器使用默认端号80监听来自HTTP客户的连接建立

10、请求。2. HTTP客户经由与TCP连接相关联的本地套接字发出一个 HTTP请求消息。这个消息中 包含路径名 /somepath/index.html 。3. HTTP服务器经由与TCP连接相关联的本地套接字接收这个请求消息，再从服务器主 机的内 存或硬盘中取出对象 /somepath/index.html ，经由同一个套接字发出包含该对象的响 应消息。4. HTTP服务器告知 TCP关闭这个TCP连接(不过TCP要到客户收到刚才这个响应消息之后 才会真正终止这个连接 ) 。5. HTTP客户经由同一个套接字接收这个响应消息。TCP连接随后终止。该消息标明所封装的对象是一个HTML文件。客户从

11、中取出这个文件，加以分析后发现其中有 10个JPEG对象的引用。6. 给每一个引用到的JPEG对象重复步骡1-4。浏览器在接收 web 页面的同时把它显示给用户。不同的浏览器可能会以略有不同的方 式解释 (也就是向用户显示)同一个web页面。HTTP与客户如何解释Web页面没有任何关系，其规范 (RFC1945和RFC26161仅仅定义HTTP客户程序和服务器程序之间的通信协议。上述步骤之所以称为使用非持久连接，原因是每次服务器发出一个对象后，相应的TCP连接就被关闭，也就是说每个连接都没有持续到可用于传送其他对象。每个TCP连接只用于传输一个请求消息和一个响应消息。就上述例子而言，用户每请求

12、一次那个web页面，就产生11个TCP连接。在上述步骡中，我们有意不说清客户是通过10个串行的TCP连接先后取得所有JPEG对象，还是通过并行的TCP连接同时取得其中某些JPEG对象。实际上，现今的浏览器允许用户通过 配置来控制并行连接的程度。大多数浏览器默认可以打开5到10个并行的TCP连接，每个连接处理一个请求一响应事务。用户要是喜欢，可以把最大并行连接数设为I,那样的话这 10个连接是串行地建立的。我们将在第 3章看到，使用并行连接可以缩短响应时间。继续介绍之前，先估算一下从客户请求基本 HTML 文件到它收到该文件所经历的时间。 为此我 们定义往返时间（round trip time，

13、简称RTT，它是一个小分组从客户主机游动到服务 器主机再返回 客户主机所花的时间。RTT包括分组传播延迟、在中间路由器和交换机土的分组排队延迟以及分组处理延迟。 下面考虑用户点击某个超链接时会发生什么。 用户的点击导 致浏览 器发起建立一个与Web服务器的TCP连接;这里涉及一次“三次握手”过程一一首 先是客户向服务 器发送一个小的冗余消息， 接着是服务器向客户确认并响应以一个小的 TCP 消息，最后是客户向服 务器回确认。三次握手过程的前两次结束时，流逝的时间为1个RTT。此时客户把HTTP请求消 息发送到 TCP 连接中，客户接着把三次握手过程最后一次中的确认 捎带在包含这个消息的数据分节

14、中 发送以去。服务器收到来自TCP连接的请求消息后，把相应的HTML文件发送到TCP连接中，服务器接着把对早先收到的客户请求的确认捎带在包含该HTML 文件的数据分节中发送出去。这个HTTP请求顺应交互也花去1个RTT时间。因此，总的响应时间 粗略地算是2个RTT加上服务器发送这个HTMI文件的时间。持久连接非持久连接有些缺点。 首先， 客户得为每个待请求的对象建立并维护一个新的连接。对于每个这样的连接，TCP得在客户端和服务器端分配TCP缓冲区，并维持TCP变量。对于有可能同 时为来自数百个不同客户的请求提供服务的web服务器来说，这会严重增加其负担。其次，如前所述，每个对象都有2个RTT的

15、响应延长个RTT用于建立TCP连接，另个RTT用于请求和接收对象。最后，每个对象都遭受TCP缓启动，因为每个TCP连接都起始于缓启动阶段。不过并行TCP连接的使用能够部分减轻RTT延迟和缓启动延迟的影响。在持久连接情况下，服务器在发出响应后让 TCP 连接继续打开着。同一对客户 /服务器 之间的后续请求和响应可以通过这个连接发送。整个Web 页面 （上例中为包含一个基本HTMLL文件和10个图像的页面）自不用说可以通过单个持久TCP连接发送：甚至存放在同一个服务器中的多个web页面也可以通过单个持久TCP连接发送。通常，HTTP服务器在某个 连接闲 置一段特定时间后关闭它， 而这段时间通常是可

16、以配置的。 持久连接分为不带流水线 （without pipeIining） 和带流水线 （with pipeIining） 两个版本。如果是不带流水线的版本，那么客 户只在收到 前一个请求的响应后才发出新的请求。 这种情况下， web 页面所引用的每个对象 （上例中的 10个图 像）都经历1个RTT的延迟，用于请求和接收该对象。与非持久连接2个RTT的延迟相比，不带流 水线的持久连接已有所改善，不过带流水线的持久连接还能进一步 降低响应延迟。 不带流水线版本的 另一个缺点是， 服务器送出一个对象后开始等待下一个请 求，而这个新请求却不能马上到达。这段时 间服务器资源便闲置了。HTTP/1.1

17、的默认模式使用带流水线的持久连接。这种情况下，HTTP客户每碰到一个引用就立即发出一个请求，因而HTTP客户可以一个接一个紧挨着发出各个引用对象的请求。服务器收到这些请求后， 也可以一个接一个紧挨着发出各个对象。 如果所有的请求和响应都 是紧挨 着发送的，那么所有引用到的对象一共只经历1个RTT的延迟（而不是像不带流水线的版本那样，每个引用到的对象都各有1个RTT的延迟）。另外，带流水线的持久连接中服务器空等请求的时间比较少。与非持久连接相比，持久连接（不论是否带流水线 ）除降低了 1个RTT的响应延迟外，缓启动延迟也比较小。其原因在于既然各个对象使用同一个TCP连接，服务器发出第一个对象后就

18、不必再以一开始的缓慢速率发送后续对象。 相反，服务器可以按 照第一个 对象发送完毕时的速率开始发送下一个对象。HTTP 消息格式HTTP规范1.0RPcl945和1.1RFC2616定义了 HTTP消息的格式。HTTP消息分为请求消 息 和响应稍息两类。下面我们分别进行介绍。HTTP 请求消息下面是一个典型的 HTTP 请求消息：GET/somedir/page.htmlHTTP/1.1Host：Connection：closeUser-agent：Mozilla/4.0 Accept-language：zh-cn （额外的回车符和换行符 ）仔细检查这个简单的请求消息， 我们可从中学到不少东西

19、。 首先，这个消息是用普通的 ASCII 文本书写的。其次，这个消息共有5行（每行以一个回车符和一个换行符结束），最后一行后面还有额外的一个回车特和换行符。 当然， 一个请求消息可以不止这么多行， 也可以仅 仅只有 行。该请求消息的第一行称为请求行（request line），后续各行都称为头部行（ header） 。请求行有3个宁段：方法字段、URL字段、HTTP版本宇段。方法字段有若干个值可供选择，包括 GET POST和HEAD。HTTP请求消息绝大多数使用GET方法，这是浏览器用来请求对象的 方法 ， 所请 求的对象就在 URL 字 段中标识。 本例表明浏览器在请求对象 /somedi

20、r/page.html 。版本字段是不言自明的 ;本例中浏览器实现的是HTTP/1.1 版本。现在看下本例中的各个头部行。头部行 Host： 定存放所请求对象的主 机。请 求消息中包含头部 Connection： close 是在告知服务器本浏览器不想使用持久连接;服务器发出所请求的对象后应关闭连接。尽管产生这个请求消息的浏览器实现的是HTTP/1.1 版本，它还是不想使用持久连接。User-agent头部行指定用户代理，也就是产生当前请求的浏览器的类 型。本例的用户代理是Mozilla/4.0，它是Nelscape浏览器的一个版本。这个头部行很有用，因为 服务器实际上可以给不同类型的用户代理

21、发送同个对象的不同版本（这些不同版本位用同一个URL寻址）。最后，Accept-languag:头部行指出要是所请求对象有简体中文 版 本，那么用户宁愿接收这个版本;如果没有这个语言版本，那么服务器应该发送其默认版本。Accept-languag:仅仅是HTTP的众多内容协商头部之一。我们接着看下下图所示的请求消息的般格式。叮图2HTTP请求格式上面的请求消息例子符合这个格式，不过一般格式中还有一个位于各个头部（及额外的回车符和换行符）之后的“附属体”（毗叮body）。附属体不在GET方法中使用，而是在POST方 法中使用。POST方法适用于需由用户填写表单的场合，如往google搜索引擎中填

22、入待搜索的词。用户提交表单后，浏览器就像用户点击了超链接那样仍然从服务器请求一个Web页面，不过该页面的具体内容却取决于用户填写在表单各个字段中的值。如果浏览器使用POST方法提 出该请求，那么请求消息附属体中包含的是用户填写在表单各个字段中的值。与GET方法类似的是HEAD方法，两者的差别只是服务器在对HEAD方法的响应消息中去掉了所请求的对象，其他内容则与对 GET方法的响应消息一样。HEAD方法通常用于HTTP服 务器软件开发人员进行调试。HTTP 响应消息下面是一个典型的 HTTP 响应消息：HTTP/1.1 200 0KConnection: closeDate: Thu, 13 O

23、ct 2005 03:17:33 GMTServer: Apache/2.0.54 （Unix）Last Nodified:Mo n,22 Jun 1998 09;23;24 GMTCo ntent Len gth:682lContentType:text/html（数据数据数据数据数据,）这个响应消息分为3部分：1个起始的状态行（status line） ,6个头部行、1个包含所请求对象 本身的附属体。状态行有3个字段:协议版本字段、状态码字段、原因短语字段。本例的状态行表明，服务器使用HTTP/1.1版本，响应过程完全正常（也就是说服务器找到了所请求的对 象，并正在发送）。现在看一下本例中

24、的各个头部行。服务器使用Connectlon:close头部行告知客户自己将在发送完本消息后关闭 TCP连接。Date:头部行指出服务器创建并发送本响应消息的日期和时间。注意，这并不是对象本身的创建时间或最后修改时间， 而是服务器把该对象从其文件 系统中取出，插入响应消息中发送出去的时间。Server :头部行指出本消息是由Apache服务器产生的；它与HTTP请求消息中的User-age nt:头部行类似。Last Nodified:头部行指出对象 本身 的创建或最后修改日期或时间。Last Nodified:头部对于对象的高速缓存至关重要，且不论这种高速缓存是发生在本地客户主机上还是发生在

25、网络高速缓存服务器主机（也就是代理服务器主机）上。Content Length:头部行指出所发送对象的字节数。Content Type:头部行 指出包含在附属体中的对象是HTML文本。对象的类型是由Content Type :头部而不是由文件扩展名正式指出的。注意，如果服务器收到一个 HTTP/1.0 的请求，那么它即使是一个 HTTP/1.1 服务器，也 不会使 用持久连接。相反，这样的HTTP/1.1服务器会在发出所请求的对象后关闭TCP连接。这么做是必要 的，因为HTTP/1.0客户期待服务器马上关闭连接。我们接着看一下如下图所示的响应消息的一般格式。 前面的响应消息例子完全符合这个 格

26、式。 响应消息中的状态码和原因短语指示相应请求的处理结果， 下面列出了一些常见的状 态码和相应的原 因短语：图3响应消息的一般格式200 0K;请求成功，所请求信息在响应消息中返回。301 Moved Permanently:所请求的对象己永久性迁移；新的URL在本响应消息的Locatio n:头部指出。客户软件会自动请求这个新的URL。400 Bad Request;表示服务器无法理解相应请求的普通错误的状态码404 Not Fou nd:服务器上不存在所请求的文档。HTTP Version Not Support:服务器不支持所请求的HTTP协议版本。你想如何看到一个真实的H仃P应答消息呢

27、？这非常简单。可以使用nc工具连接到你喜欢的服务器（nc/netcat是一个黑客很喜欢用的工具，可以方便在主机之间建立TCP连接），然例如，如果你可以输入以下指后输入一行请求消息，用来请求位于该服务器上的某个对象 令: 80GET /index.shtml HTTP/1.0（在输入第二行之后，敲两次回车 ），这就打开了一个到主机 的端口 80 的TCP连接，然后发送HTTP GET命令。你应该能看到包含着YESK主页的基本HTML文件的应苔消息。如果你想只看到HTTP消息行而不接收该对象本身，那么就把上面的GET换成HEAD,最后，看一下能得到什么样的应答消息。在这里我们讨论了大量能够在HTT

28、P请求和应答消息中使用的头部行。 HTTP规范（尤其是HTTP/1.1症义了更多可以由浏览器、Web服务器和网络缓冲服务器插入的头部行。我们可以便用 nc 工具完全控制在请求消息中包含哪些头部，那么浏览器如何决定该在 请求消息 个包含哪些头部呢 ?Web 服务器又是如何决定该在响应消息中包含哪些头部?浏览器是根据自己的用户代理类型、所支持的HTTP版本（HTTP/1.0版本的浏览器自然不会产生HTTP/1.1版本的头部）、用户对浏览器的配置（如所偏爱的语言）等因素生成请求消息中的各个 头 部的。web服务器有类似的情形：它们有不同的产品、版本和配置，所有这些因素都会影响在响应消 息中包含哪些头

29、部。本文讨论过的和即将讨论的用于 HTTP请求消息和响应消息中的头部仅仅是很小的一部 分，HTTP规范中定义了更多可用的头部，可以查阅相关的RFC文档进行更详细的了解。用户服务器交互身份认证和 cookie我们已经知道HTTP服务器是无状态的。这样的处理可以简化服务器程序的设计，以便开发出更 高性能的Web服务器软件。然而，一个Web站点往往有标识其用户的需求，因为其web服务器可 能希望限制用户的访问，也可能想要根据用户的身份来提供内容。HTTP提供了两种帮助服务器标识用户的机制 ：身份认证和 cookle 。身份认证许多 web 站点要求用户提供一个用户名口令对才能访问存放在其服务器中 的

30、文档。 这种要求称为身份认证（authentication）。HTTP提供特殊的状态码和头部来帮助Web站点执行身份认证。 我们通过查看一个例子来领会这些特殊的状态码和头部如何工作。假设有个客户在请求来自某个服务器的一个对象，而该服务器要求用户授予权限。客户首先发送一个不合特殊头部的普通请求消息。服务器以空的附属体和一个“ 401Authorization Required ”状态码作为响应。服务器还在这个响应消息中包含个 WWW- Authenticate： 头部，说明具体如何执行身份认证。这个头部的典型值是指出用户需要 提供一个用户名 口令对。客户收到这个响应消息后提示用户输入用户名和口令

31、， 然后重新发送请求消息。 这一回 客户在请求消息中包含了一个 Authorization： 头部，其中包含有用户输入的用户名和口令。取得第一个对象后， 客户在同为请求该服务器上对象的后续请求中继续发送这个用户名 口令 对。 这个做法一般将持续到用户关闭浏览器为止。 在浏览器未被关闭之前， 这个用户 名口令对是 高速缓存着的， 因此浏览器不会每请求一个对象就提示用户输入一次用户名和 口令。通过上述方式， 要求用户授权的 Web 站点就能标识出每个请求的用户了。我们需要知道， HTTP 执行的是一种相当脆弱的身份认证方式，不难攻破。现代有很多 更为安全 的认证方式，我们会在以后介绍。cookie

32、是一种可让Web站点用来跟踪用户的候选机制，定义在RFC2109中。有些Web站点使 用cookie，其他Web站点则不用。下面查看一个例子。假设一个客户首次联系一个使用cookie的 web站点。服务器会在其响应中包含一个Set Cookie:头部。该头部的值可以是一个由 Web 服务器产生的客户标识数 .例如 :Set-Cookie:1678453客户收到这个响应消息，看到其中的Set-Cookie:头部和标识数后，会在存放在客户主机中的某个特殊的cookie文件中添加一行。这一行一般包含服务器主机的主机名和这个与用户关联的标 识数。在一段时间 （如一个星期 ）之后请求同一个服务器时，由同

33、一个用户启动的 新客户会在请求 消息中包含一个cookie头部，其值为早先由该服务器产生的标识数，例如:Cookie:1678453。在这种 方式中，服务器并不知道提出请求的用户的用户名，但是它确实 知道该用户与一个星期前提出请求的 用户是同一个。Web 服务器有多个使用 coohe 的目的 :如果服务器要求身份认证，但又不想在同一用户每次访问本Web 站点时都麻烦他输入用户名和口令，那么可以设置一个 cookie。如果服务器想要记住用户的偏好， 以便在他们后续访问期间有目的地提供广告， 那么 可以设 置一个 cookie。如果 web站点提供购物服务，那么服务器可以使用cookie跟踪用户购

34、买的物品，就是建立一 个虚拟的购物车。需指出的是，cookie不适用于会从不同主机访问同一web站点的游动用户。这种情况下，该 web 站点会把同一个用户在不同主机上的使用看成是由新的用户执行的。带条件的 GETWeb 高速缓存技术通过就近存取先前取得的对象来降低对象检索延迟，减少因特网上 的 web 流 量。 Web 的高速缓存既可以驻留在客户主机中，也可以驻留在中间网络高速缓存 服务器主机中。我 们将在稍后讨论网络高速缓存，这里只关注客户的高速缓存。Web 高速缓存在降低用户可感知的响应时间的同时，却引入了一个新的问题高速缓存中存放的对象的拷贝可能是过期的。换句话说，存放在web服务器中的

35、对象可能己在客户高速缓 存下它的一个拷贝之后被修改了。幸运的是， HTTP 提供一个专门的机制，使得 在允许客户进行高速 缓存的同时， 仍确保传递给浏览器的所有对象都是最新的。 这个机制称 为带条件的 OET（conditionalGET)。满足条件使用GET方法和包含lf-Modified-S1 nee:头部的HTTP请求消息就是所谓的带条 件的Get 消息。我们通过查看一个例子来说明带条件的GET如何工作，向服务器请求一个尚未高速缓存的对象 :GET /fruit/kiwi.gif HTTP/1.0Useragent: Mozilla/4.0接着， web 服务器把带这个对象的一个响应消息

36、发送给客户HTTP/1.0 200 OKDate: Thu, 13 Oct 2005 05:33:47 GMTServer: Apache/2.0.54 (Unix)Last-Modified:Thu, 13 Oct 2005 02:32:47 GMTContent-Type:image/gif(数据数据数据数据数据,)客户把这个对象显示给用户，同时把它保存在自己的本地高速缓存中客户还随该对象本身高速缓存最后修改日期与时间。一个星期之后，同一个用户请求同一个对象，而该对象仍然存放在高速缓存中。既然web服务器中的该对象有可能已在最近一个星期被修改过，是浏览器发出 个带条件的GET消息，执行判定

37、高速缓存的对象拷贝是否为最新的检查GET /fruit/kiwi.gif HTTP/1.0Useragent: Mozilla/4.0 lfModlfied Since:Thu, 13 Oct 2005 02:32:47 GMT其中，If Modified Since:头部的值就等于一个星期前由服务器发送的Last-Modified:头部的值。这个带条件的GET消息告知服务器，只有在该对象自所指定的时间以来被修改了的前提下才发送它。 假设该对象在这段时间内未曾被修改过， 那么服务器将发送个附属 体为空 的响应消息给客户 ;HTTP/1.0 304 Not ModifiedDate: Thu, 20 Oct 2005 05:33:47 GMTServer: Apache/2.0.54 (Unix)我们看到，web服务器仍然发送一一个响应消息作为带条件的GET消息的响应，不过其中不 包含所请求的对象。 包含该对象只会浪费带宽， 并延长用户可感知的响应时间， 特别 是在该对象很 大的时候。注意，这个响应消息的状态为“ 304 Not Modified ”，它告知客户可 以放心使用所请求对 象的高速缓存版本。