了解WWW服務(wù)和HTTP協(xié)議

1、了解WWW服務(wù)和HTTP協(xié)議歷史上，先后問世了多個具有重大社會影響的電子通信技術(shù)。第一個這樣的技術(shù)是19世紀70年代發(fā)明的電話。電話使得不在同一物理位置的兩人得以實時地口頭交流。它對社會有重大的影響有好的也有壞的。下一個電子通信技術(shù)是20世紀20年代及30年代問世的廣播收音機/電視機。廣播收音機/電視機使得人們能收聽收視大量的音頻和視頻信息。它對社會同樣有重大的影響有好的也有壞的。改變了人們的生活與工作方式的第三個重大通信技術(shù)是web。web最吸引用戶的也許是它的隨選(on demand)操作性。用戶只在想要時收到所要的東西。這一點不同于廣播收音機/電視機。廣播收音機/電視機的用戶是在其內(nèi)容供

2、應(yīng)商播出內(nèi)容期間被迫收聽收視。除了隨選操作性，Web還有許多大家喜愛的其他精彩特性。任何個人都可以極其容易地在Web上公布任何信息;任何人都可能以極低的成本成為發(fā)行人。超鏈接和搜索引擎幫助我們在Web站點的海洋中導(dǎo)航。圖形和動畫刺激著我們的感官。表單、Java小應(yīng)用程序、Activex控件以及其他許多設(shè)備使得我們能與Web頁面和站點交互。Web還越來越普遍地提供存放在因特網(wǎng)中的、可隨選訪問(即點播)的大量音頻和視頻材料的菜單接口。HTTP概貌Web的應(yīng)用層協(xié)議HTTP是Web的核心。HTTP在Web的客戶程序和服務(wù)器程序中得以實現(xiàn)。運行在不同端系統(tǒng)上的客戶程序和服務(wù)器程序通過交換HTTP消息彼

3、此交流。HTTP定義這些消息的結(jié)構(gòu)以及客戶和服務(wù)器如何交換這些消息。在詳細解釋HTTP之前，我們先來回顧一些web中的術(shù)語。Web頁面(web page，也稱為文檔)由多個對象構(gòu)成。對象(object)僅僅是可由單個URL尋址的文件，例如HTML文件、JPG圖像、GIF圖像、JAVA小應(yīng)用程序、語音片段等。大多數(shù)Web頁面由單個基本HIML文件和若干個所引用的對象構(gòu)成。例如，如果一個Web頁面包含HTML文本和5個JPEG圖像，那么它由6個對象構(gòu)成，即基本H1ML文件加5個圖像。基本HTML文件使用相應(yīng)的URL來引用本頁面的其他對象。每個URL由存放該對象的服務(wù)器主機名和該對象的路徑名兩部分構(gòu)

4、成。例如，在如下的URL中:圖1 HTTP請求與響應(yīng)行為HTTP/1.0和HTTP/1.1都把TCP作為底層的傳輸協(xié)議。HTTP客戶首先發(fā)起建立與服務(wù)器TCP連接。一旦建立連接，瀏覽器進程和服務(wù)器進程就可以通過各自的套接字來訪問TCP。如前所述，客戶端套接字是客戶進程和TCP連接之間的“門”，服務(wù)器端套接字是服務(wù)器進程和同一TCP連接之間的“門”?？蛻敉约旱奶捉幼职l(fā)送HTTP請求消息，也從自己的套接字接收HTTP響應(yīng)消息。類似地，服務(wù)器從自己的套接字接收HTTP請求消息，也往自己的套接字發(fā)送HTTP響應(yīng)消息。客戶或服務(wù)器一旦把某個消息送入各自的套接字，這個消息就完全落入TCP的控制之中。TC

5、P給HTTP提供一個可靠的數(shù)據(jù)傳輸服務(wù);這意味著由客戶發(fā)出的每個HTTP請求消息最終將無損地到達服務(wù)器，由服務(wù)器發(fā)出的每個HTTP響應(yīng)消息最終也將無損地到達客戶。我們可從中看到分層網(wǎng)絡(luò)體系結(jié)構(gòu)的一個明顯優(yōu)勢HTTP不必擔(dān)心數(shù)據(jù)會丟失，也無需關(guān)心TCP如何從數(shù)據(jù)的丟失和錯序中恢復(fù)出來的細節(jié)。這些是TCP和協(xié)議棧中更低協(xié)議層的任務(wù)。TCP還使用一個擁塞控制機制。該機制迫使每個新的TCP連接一開始以相對緩慢的速率傳輸數(shù)據(jù)，然而只要網(wǎng)絡(luò)不擁塞，每個連接可以迅速上升到相對較高的速率。這個慢速傳輸?shù)某跏茧A段稱為緩啟動(slow start)。需要注意的是，在向客戶發(fā)送所請求文件的同時，服務(wù)器并沒有存儲關(guān)于

6、該客戶的任何狀態(tài)信息。即便某個客戶在幾秒鐘內(nèi)再次請求同一個對象，服務(wù)器也不會響應(yīng)說:自己剛剛給它發(fā)送了這個對象。相反，服務(wù)器重新發(fā)送這個對象，因為它已經(jīng)徹底忘記早先做過什么。既然HTTP服務(wù)器不維護客戶的狀態(tài)信息，我們于是說HTTP是一個無狀態(tài)的協(xié)議(stateless protocol)。非持久連接和持久連接HTTP既可以使用非持久連接(nonpersistent connection)，也可以使用持久連接(persistent connection)。HTTP/1.0使用非持久連接，HTTP/1.1默認使用持久連接。非持久連接2.HTTP客戶經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字發(fā)出個HTTP

7、請求消息。這個消息中包含路徑名/somepath/index.html。3.HTTP服務(wù)器經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字接收這個請求消息，再從服務(wù)器主機的內(nèi)存或硬盤中取出對象/somepath/index.html，經(jīng)由同一個套接字發(fā)出包含該對象的響應(yīng)消息。4.HTTP服務(wù)器告知TCP關(guān)閉這個TCP連接(不過TCP要到客戶收到剛才這個響應(yīng)消息之后才會真正終止這個連接)。5.HTTP客戶經(jīng)由同一個套接字接收這個響應(yīng)消息。TCP連接隨后終止。該消息標(biāo)明所封裝的對象是一個HTML文件?？蛻魪闹腥〕鲞@個文件，加以分析后發(fā)現(xiàn)其中有10個JPEG對象的引用。6.給每一個引用到的JPEG對象重復(fù)步騾1-

8、4。瀏覽器在接收web頁面的同時把它顯示給用戶。不同的瀏覽器可能會以略有不同的方式解釋(也就是向用戶顯示)同一個web頁面。HTTP與客戶如何解釋W(xué)eb頁面沒有任何關(guān)系，其規(guī)范(RFC 1945和RFC 2616I)僅僅定義HTTP客戶程序和服務(wù)器程序之間的通信協(xié)議。上述步驟之所以稱為使用非持久連接，原因是每次服務(wù)器發(fā)出一個對象后，相應(yīng)的TCP連接就被關(guān)閉，也就是說每個連接都沒有持續(xù)到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應(yīng)消息。就上述例子而言，用戶每請求一次那個web頁面，就產(chǎn)生11個TCP連接。在上述步騾中，我們有意不說清客戶是通過10個串行的TCP連接先后取得所

9、有JPEG對象，還是通過并行的TCP連接同時取得其中某些JPEG對象。實際上，現(xiàn)今的瀏覽器允許用戶通過配置來控制并行連接的程度。大多數(shù)瀏覽器默認可以打開5到10個并行的TCP連接，每個連接處理一個請求響應(yīng)事務(wù)。用戶要是喜歡，可以把最大并行連接數(shù)設(shè)為l，那樣的話這10個連接是串行地建立的。我們將在第3章看到，使用并行連接可以縮短響應(yīng)時間。 繼續(xù)介紹之前，先估算一下從客戶請求基本HTML文件到它收到該文件所經(jīng)歷的時間。為此我們定義往返時間(round trip time，簡稱RTT)，它是一個小分組從客戶主機游動到服務(wù)器主機再返回客戶主機所花的時間。RTT包括分組傳播延遲、在中間路由器和交換機土的

10、分組排隊延遲以及分組處理延遲。下面考慮用戶點擊某個超鏈接時會發(fā)生什么。用戶的點擊導(dǎo)致瀏覽器發(fā)起建立一個與Web服務(wù)器的TCP連接;這里涉及·次“三次握手”過程首先是客戶向服務(wù)器發(fā)送一個小的冗余消息，接著是服務(wù)器向客戶確認并響應(yīng)以一個小的TCP消息，最后是客戶向服務(wù)器回確認。三次握手過程的前兩次結(jié)束時，流逝的時間為1個RTT。此時客戶把HTTP請求消息發(fā)送到TCP連接中，客戶接著把三次握手過程最后一次中的確認捎帶在包含這個消息的數(shù)據(jù)分節(jié)中發(fā)送以去。服務(wù)器收到來自TCP連接的請求消息后，把相應(yīng)的HTML文件發(fā)送到TCP連接中，服務(wù)器接著把對早先收到的客戶請求的確認捎帶在包含該HTML文件

11、的數(shù)據(jù)分節(jié)中發(fā)送出去。這個HTTP請求順應(yīng)交互也花去1個RTT時間。因此，總的響應(yīng)時間粗略地算是2個RTT加上服務(wù)器發(fā)送這個HTMI文件的時間。持久連接非持久連接有些缺點。首先，客戶得為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接，TCP得在客戶端和服務(wù)器端分配TCP緩沖區(qū)，并維持TCP變量。對于有可能同時為來自數(shù)百個不同客戶的請求提供服務(wù)的web服務(wù)器來說，這會嚴重增加其負擔(dān)。其次，如前所述，每個對象都有2個RTT的響應(yīng)延長一個RTT用于建立TCP連接，另個RTT用于請求和接收對象。最后，每個對象都遭受TCP緩啟動，因為每個TCP連接都起始于緩啟動階段。不過并行TCP連接的使用

12、能夠部分減輕RTT延遲和緩啟動延遲的影響。 在持久連接情況下，服務(wù)器在發(fā)出響應(yīng)后讓TCP連接繼續(xù)打開著。同一對客戶/服務(wù)器之間的后續(xù)請求和響應(yīng)可以通過這個連接發(fā)送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發(fā)送:甚至存放在同一個服務(wù)器中的多個web頁面也可以通過單個持久TCP連接發(fā)送。通常，HTTP服務(wù)器在某個連接閑置一段特定時間后關(guān)閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的

13、響應(yīng)后才發(fā)出新的請求。這種情況下，web頁面所引用的每個對象(上例中的10個圖像)都經(jīng)歷1個RTT的延遲，用于請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應(yīng)延遲。不帶流水線版本的另一個缺點是，服務(wù)器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務(wù)器資源便閑置了。HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發(fā)出一個請求，因而HTTP客戶可以一個接一個緊挨著發(fā)出各個引用對象的請求。服務(wù)器收到這些請求后，也可以一個接一個緊挨著發(fā)出各個對象。如果所有

14、的請求和響應(yīng)都是緊挨著發(fā)送的，那么所有引用到的對象一共只經(jīng)歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務(wù)器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應(yīng)延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個TCP連接，服務(wù)器發(fā)出第一個對象后就不必再以一開始的緩慢速率發(fā)送后續(xù)對象。相反，服務(wù)器可以按照第一個對象發(fā)送完畢時的速率開始發(fā)送下一個對象。HTTP消息格式HTTP規(guī)范1.0RPcl945和1.1RFC 2616定義了HTTP消息的格式。HTTP消息分為請求消息和響

15、應(yīng)稍息兩類。下面我們分別進行介紹。HTTP請求消息下面是一個典型的HTTP請求消息:GET /somedir/page.html H7TP/1.1Connection:closeUser-agent:Mozilla/4.0Accept-language:zh-cn(額外的回車符和換行符)仔細檢查這個簡單的請求消息，我們可從中學(xué)到不少東西。首先，這個消息是用普通的ASCII文本書寫的。其次，這個消息共有5行(每行以一個回車符和一個換行符結(jié)束)，最后一行后面還有額外的一個回車特和換行符。當(dāng)然，一個請求消息可以不止這么多行，也可以僅僅只有一行。該請求消息的第一行稱為請求行(request line)

16、，后續(xù)各行都稱為頭部行(header)。請求行有3個寧段:方法字段、URL字段、HTTP版本宇段。方法字段有若干個值可供選擇，包括GET、POST和HEAD。HTTP請求消息絕大多數(shù)使用GET方法，這是瀏覽器用來請求對象的方法，所請求的對象就在URL字段中標(biāo)識。本例表明瀏覽器在請求對象/somedir/page.html。版本字段是不言自明的;本例中瀏覽器實現(xiàn)的是HTTP/1.1版本。我們接著看一下下圖所示的請求消息的一般格式。圖2:HTTP請求格式上面的請求消息例子符合這個格式，不過一般格式中還有一個位于各個頭部(及額外的回車符和換行符)之后的“附屬體”(毗叮body)。附屬體不在GET方法

17、中使用，而是在POST方法中使用。POST方法適用于需由用戶填寫表單的場合，如往google搜索引擎中填入待搜索的詞。用戶提交表單后，瀏覽器就像用戶點擊了超鏈接那樣仍然從服務(wù)器請求一個Web頁面，不過該頁面的具體內(nèi)容卻取決于用戶填寫在表單各個字段中的值。如果瀏覽器使用POST方法提出該請求，那么請求消息附屬體中包含的是用戶填寫在表單各個字段中的值。與GET方法類似的是HEAD方法，兩者的差別只是服務(wù)器在對HEAD方法的響應(yīng)消息中去掉了所請求的對象，其他內(nèi)容則與對GET方法的響應(yīng)消息一樣。HEAD方法通常用于HTTP服務(wù)器軟件開發(fā)人員進行調(diào)試。下面是一個典型的HTTP響應(yīng)消息:LastNodif

18、ied:Mon,22 Jun 1998 09;23;24 GMTContentLength:682lContentType:text/html(數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù))這個響應(yīng)消息分為3部分：1個起始的狀態(tài)行(status line)，6個頭部行、1個包含所請求對象本身的附屬體。狀態(tài)行有3個字段:協(xié)議版本字段、狀態(tài)碼字段、原因短語字段。本例的狀態(tài)行表明，服務(wù)器使用HTTP/1.1版本，響應(yīng)過程完全正常(也就是說服務(wù)器找到了所請求的對象，并正在發(fā)送)?，F(xiàn)在看一下本例中的各個頭部行。服務(wù)器使用Connectlon:close頭部行告知客戶自己將在發(fā)送完本消息后關(guān)閉TCP連接。Date:頭部行

19、指出服務(wù)器創(chuàng)建并發(fā)送本響應(yīng)消息的日期和時間。注意，這并不是對象本身的創(chuàng)建時間或最后修改時間，而是服務(wù)器把該對象從其文件系統(tǒng)中取出，插入響應(yīng)消息中發(fā)送出去的時間。Server:頭部行指出本消息是由Apache服務(wù)器產(chǎn)生的;它與HTTP請求消息中的User-agent:頭部行類似。LastNodified:頭部行指出對象本身的創(chuàng)建或最后修改日期或時間。LastNodified:頭部對于對象的高速緩存至關(guān)重要，且不論這種高速緩存是發(fā)生在本地客戶主機上還是發(fā)生在網(wǎng)絡(luò)高速緩存服務(wù)器主機(也就是代理服務(wù)器主機)上。ContentLength:頭部行指出所發(fā)送對象的字節(jié)數(shù)。ContentType:頭部行指出

20、包含在附屬體中的對象是HTML文本。對象的類型是由ContentType:頭部而不是由文件擴展名正式指出的。注意，如果服務(wù)器收到一個HTTP/1.0的請求，那么它即使是一個HTTP/1.1服務(wù)器，也不會使用持久連接。相反，這樣的HTTP/1.1服務(wù)器會在發(fā)出所請求的對象后關(guān)閉TCP連接。這么做是必要的，因為HTTP/1.0客戶期待服務(wù)器馬上關(guān)閉連接。我們接著看一下如下圖所示的響應(yīng)消息的一般格式。前面的響應(yīng)消息例子完全符合這個格式。響應(yīng)消息中的狀態(tài)碼和原因短語指示相應(yīng)請求的處理結(jié)果，下面列出了一些常見的狀態(tài)碼和相應(yīng)的原因短語:圖3:響應(yīng)消息的一般格式200 0K;請求成功，所請求信息在響應(yīng)消息中

21、返回。301 Moved Permanently:所請求的對象己永久性遷移;新的URL在本響應(yīng)消息的Location:頭部指出?？蛻糗浖詣诱埱筮@個新的URL。400 Bad Request;表示服務(wù)器無法理解相應(yīng)請求的普通錯誤的狀態(tài)碼404 Not Found:服務(wù)器上不存在所請求的文檔。HTTP Version Not Support:服務(wù)器不支持所請求的HTTP協(xié)議版本。你想如何看到一個真實的H1TP應(yīng)答消息呢?這非常簡單?？梢允褂胣c工具連接到你喜歡的服務(wù)器(nc/netcat是一個黑客很喜歡用的工具，可以方便在主機之間建立TCP連接)，然后輸入一行請求消息，用來請求位于該服務(wù)器上的

22、某個對象。例如，如果你可以輸入以下指令:GET /index.shtml HTTP/1.0在這里我們討論了大量能夠在HTTP請求和應(yīng)答消息中使用的頭部行。HTTP規(guī)范(尤其是HTTP/1.1)定義了更多可以由瀏覽器、Web服務(wù)器和網(wǎng)絡(luò)緩沖服務(wù)器插入的頭部行。 我們可以便用nc工具完全控制在請求消息中包含哪些頭部，那么瀏覽器如何決定該在請求消息個包含哪些頭部呢?Web服務(wù)器又是如何決定該在響應(yīng)消息中包含哪些頭部?瀏覽器是根據(jù)自己的用戶代理類型、所支持的HTTP版本(HTTP/1.0版本的瀏覽器自然不會產(chǎn)生HTTP/1.1版本的頭部)、用戶對瀏覽器的配置(如所偏愛的語言)等因素生成請求消息中的各個

23、頭部的。web服務(wù)器有類似的情形:它們有不同的產(chǎn)品、版本和配置，所有這些因素都會影響在響應(yīng)消息中包含哪些頭部。本文討論過的和即將討論的用于HTTP請求消息和響應(yīng)消息中的頭部僅僅是很小的一部分，HTTP規(guī)范中定義了更多可用的頭部，可以查閱相關(guān)的RFC文檔進行更詳細的了解。 用戶服務(wù)器交互身份認證和cookie我們已經(jīng)知道HTTP服務(wù)器是無狀態(tài)的。這樣的處理可以簡化服務(wù)器程序的設(shè)計，以便開發(fā)出更高性能的Web服務(wù)器軟件。然而，一個Web站點往往有標(biāo)識其用戶的需求，因為其web服務(wù)器可能希望限制用戶的訪問，也可能想要根據(jù)用戶的身份來提供內(nèi)容。HTTP提供了兩種幫助服務(wù)器標(biāo)識用戶的機制:身份認證和co

24、okle。身份認證許多web站點要求用戶提供一個用戶名口令對才能訪問存放在其服務(wù)器中的文檔。這種要求稱為身份認證(authentication)。HTTP提供特殊的狀態(tài)碼和頭部來幫助Web站點執(zhí)行身份認證。我們通過查看一個例子來領(lǐng)會這些特殊的狀態(tài)碼和頭部如何工作。假設(shè)有個客戶在請求來自某個服務(wù)器的一個對象，而該服務(wù)器要求用戶授予權(quán)限?？蛻羰紫劝l(fā)送一個不合特殊頭部的普通請求消息。服務(wù)器以空的附屬體和一個“401Authorization Required”狀態(tài)碼作為響應(yīng)。服務(wù)器還在這個響應(yīng)消息中包含“個WWW-Authenticate:頭部，說明具體如何執(zhí)行身份認證。這個頭部的典型值是指出用戶需

25、要提供一個用戶名口令對?？蛻羰盏竭@個響應(yīng)消息后提示用戶輸入用戶名和口令，然后重新發(fā)送請求消息。這一回客戶在請求消息中包含了一個Authorization:頭部，其中包含有用戶輸入的用戶名和口令。 取得第一個對象后，客戶在同為請求該服務(wù)器上對象的后續(xù)請求中繼續(xù)發(fā)送這個用戶名口令對。這個做法一般將持續(xù)到用戶關(guān)閉瀏覽器為止。在瀏覽器未被關(guān)閉之前，這個用戶名口令對是高速緩存著的，因此瀏覽器不會每請求一個對象就提示用戶輸入一次用戶名和口令。通過上述方式，要求用戶授權(quán)的Web站點就能標(biāo)識出每個請求的用戶了。我們需要知道，HTTP執(zhí)行的是一種相當(dāng)脆弱的身份認證方式，不難攻破?，F(xiàn)代有很多更為安全的認證方式，我

26、們會在以后介紹。cookie是一種可讓W(xué)eb站點用來跟蹤用戶的候選機制，定義在RFC 2109中。有些Web站點使用cookie，其他Web站點則不用。下面查看一個例子。假設(shè)一個客戶首次聯(lián)系一個使用cookie的web站點。服務(wù)器會在其響應(yīng)中包含一個SetCookie:頭部。該頭部的值可以是一個由Web服務(wù)器產(chǎn)生的客戶標(biāo)識數(shù).例如:Set-Cookie:1678453客戶收到這個響應(yīng)消息，看到其中的Set-Cookie:頭部和標(biāo)識數(shù)后，會在存放在客戶主機中的某個特殊的cookie文件中添加一行。這一行一般包含服務(wù)器主機的主機名和這個與用戶關(guān)聯(lián)的標(biāo)識數(shù)。在一段時間(如一個星期)之后請求同一個服務(wù)

27、器時，由同一個用戶啟動的新客戶會在請求消息中包含一個cookie頭部，其值為早先由該服務(wù)器產(chǎn)生的標(biāo)識數(shù)，例如:Cookie:1678453在這種方式中，服務(wù)器并不知道提出請求的用戶的用戶名，但是它確實知道該用戶與一個星期前提出請求的用戶是同一個。Web服務(wù)器有多個使用coohe的目的:如果服務(wù)器要求身份認證，但又不想在同一用戶每次訪問本W(wǎng)eb站點時都麻煩他輸入用戶名和口令，那么可以設(shè)置一個cookie。如果服務(wù)器想要記住用戶的偏好，以便在他們后續(xù)訪問期間有目的地提供廣告，那么可以設(shè)置一個cookie。如果web站點提供購物服務(wù)，那么服務(wù)器可以使用cookie跟蹤用戶購買的物品，就是建立一個虛擬

28、的購物車。需指出的是，cookie不適用于會從不同主機訪問同一web站點的游動用戶。這種情況下，該web站點會把同一個用戶在不同主機上的使用看成是由新的用戶執(zhí)行的。 帶條件的GETWeb高速緩存技術(shù)通過就近存取先前取得的對象來降低對象檢索延遲，減少因特網(wǎng)上的web流量。Web的高速緩存既可以駐留在客戶主機中，也可以駐留在中間網(wǎng)絡(luò)高速緩存服務(wù)器主機中。我們將在稍后討論網(wǎng)絡(luò)高速緩存，這里只關(guān)注客戶的高速緩存。Web高速緩存在降低用戶可感知的響應(yīng)時間的同時，卻引入了一個新的問題高速緩存中存放的對象的拷貝可能是過期的。換句話說，存放在web服務(wù)器中的對象可能己在客戶高速緩存下它的一個拷貝之后被修改了。幸運的是，HTTP提供一個專門的機制，使得在允許客戶進行高速緩存的同時，仍確保傳遞給瀏覽器的所有對象都是最新的。這個機制稱為帶條件