本節書摘來華章計算機《計算機網絡：自頂向下方法（原書第6版）》一書中的第2章 ，第2.2節，（美）james f.kurose keith w.ross 著 陳 鳴 譯 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
20世紀90年代以前，網際網路的主要使用者還是研究人員、學者和大學生，他們登入遠端主機，在本地主機和遠端主機之間傳輸檔案，收發新聞，收發電子郵件。盡管這些應用非常有用（并且繼續如此），但是網際網路基本上不為學術界和研究界之外所知。到了20世紀90年代初期，一個主要的新型應用即網際網路（world wide web）登上了舞台［berners-lee 1994］。web是一個引起公衆注意的網際網路應用，它極大地改變了人們與工作環境内外交流的方式。它将網際網路從隻是很多資料網之一的地位提升為僅有的一個資料網。
也許對大多數使用者來說，最具有吸引力的就是web的按需操作。當使用者需要時，就能得到所想要的内容。這不同于無線電廣播和電視，迫使使用者隻能收聽、收看内容提供者提供的節目。除了可以按需操作以外，web還有很多讓人們喜歡和珍愛的特性。任何人使資訊在web上可用都非常簡單，即隻需要極低的費用就能成為出版人。超連結和搜尋引擎幫助我們在web站點的海洋裡導航。圖形化的界面刺激着我們的感官。表單、java小程式和很多其他的裝置，使我們可以與web頁面和站點進行互動。并且web為許多在2003年以後出現的招人喜愛的應用提供了平台，這些應用包括youtube、gmail和face book(臉譜)。
web的應用層協定是超文本傳輸協定（hypertext transfer protocol,http），它是web的核心，在［rfc 1945］和［rfc 2616］中進行了定義。http由兩個程式實作：一個客戶程式和一個伺服器程式。客戶程式和伺服器程式運作在不同的端系統中，通過交換http封包進行會話。http定義了這些封包的結構以及客戶和伺服器進行封包交換的方式。在詳細解釋http之前，應當回顧某些web術語。
http定義了web客戶向web伺服器請求web頁面的方式，以及伺服器向客戶傳送web頁面的方式。我們稍後詳細讨論客戶和伺服器的互動過程，而其基本思想在圖2-6中進行了圖示。當使用者請求一個web頁面（如點選一個超連結）時，浏覽器向伺服器發出對該頁面中所包含對象的http請求封包，伺服器接收到請求并用包含這些對象的http響應封包進行響應。
http使用tcp作為它的支撐運輸協定（而不是在udp上運作）。http客戶首先發起一個與伺服器的tcp連接配接。一旦連接配接建立，該浏覽器和伺服器程序就可以通過套接字接口通路tcp。如同在2.1節中描述的那樣，用戶端的套接字接口是客戶程序與tcp連接配接之間的門，在伺服器端的套接字接口則是伺服器程序與tcp連接配接之間的門。客戶向它的套接字接口發送http請求封包并從它的套接字接口接收http響應封包。類似地，伺服器從它的套接字接口接收http請求封包和向它的套接字接口發送http響應封包。一旦客戶向它的套接字接口發送了一個請求封包，該封包就脫離了客戶控制并進入tcp的控制。2.1節講過，tcp為http提供可靠資料傳輸服務。這意味着，一個客戶程序發出的每個http請求封包最終能完整地到達伺服器；類似地，伺服器程序發出的每個http響應封包最終能完整地到達客戶。這裡我們看到了分層體系結構最大的優點，即http協定不用擔心資料丢失，也不關注tcp從網絡的資料丢失和亂序故障中恢複的細節。那是tcp以及協定棧較低層協定的工作。
注意到下列現象很重要：伺服器向客戶發送被請求的檔案，而不存儲任何關于該客戶的狀态資訊。假如某個特定的客戶在短短的幾秒鐘内兩次請求同一個對象，伺服器并不會因為剛剛為該客戶提供了該對象就不再做出反應，而是重新發送該對象，就像伺服器已經完全忘記不久之前所做過的事一樣。因為http伺服器并不儲存關于客戶的任何資訊，是以我們說http是一個無狀态協定（stateless protocol）。我們同時也注意到web使用了客戶-伺服器應用程式體系結構（如2.1節所述）。web伺服器總是打開的，具有一個固定的ip位址，且它服務于可能來自數以百萬計的不同浏覽器的請求。
在許多網際網路應用程式中，客戶和伺服器在一個相當長的時間範圍内通信，其中客戶發出一系列請求并且伺服器對每個請求進行響應。依據應用程式以及該應用程式的使用方式，這一系列請求可以以規則的間隔周期性地或者間斷性地一個接一個發出。當這種客戶-伺服器的互動是經tcp進行的，應用程式的研制者就需要做一個重要決定，即每個請求/響應對是經一個單獨的tcp連接配接發送，還是所有的請求及其響應經相同的tcp連接配接發送呢？采用前一種方法，該應用程式被稱為使用非持續連接配接（non-persistent connection）；采用後一種方法，該應用程式被稱為使用持續連接配接（persistent connection）。為了深入地了解該設計問題，我們研究在特定的應用程式即http的情況下持續連接配接的優點和缺點，http既能夠使用非持續連接配接，也能夠使用持續連接配接。盡管http在其預設方式下使用持續連接配接，http客戶和伺服器也能配置成使用非持續連接配接。
1.采用非持續連接配接的http
我們看看發生了什麼情況：
http客戶程序在端口号80發起一個到伺服器www.someschool.edu的tcp連接配接，該端口号是http的預設端口。在客戶和伺服器上分别有一個套接字與該連接配接相關聯。
http客戶經它的套接字向該伺服器發送一個http請求封包。請求封包中包含了路徑名/somedepartment/home.index（後面我們會詳細讨論http封包）。
http伺服器程序經它的套接字接收該請求封包，從其存儲器（ram或磁盤）中檢索出對象www.someschool.edu/somedepartment/home.index，在一個http響應封包中封裝對象，并通過其套接字向客戶發送響應封包。
http伺服器程序通知tcp斷開該tcp連接配接。（但是直到tcp确認客戶已經完整地收到響應封包為止，它才會實際中斷連接配接。）
http客戶接收響應封包，tcp連接配接關閉。該封包指出封裝的對象是一個html檔案，客戶從響應封包中提取出該檔案，檢查該html檔案，得到對10個jpeg圖形的引用。
對每個引用的jpeg圖形對象重複前4個步驟。
當浏覽器收到web頁面後，顯示給使用者。兩個不同的浏覽器也許會以不同的方式解釋（即向使用者顯示）該頁面。http與客戶如何解釋一個web頁面毫無關系。http規範（［rfc 1945］和［rfc 2616］）僅定義了在http客戶程式與http伺服器程式之間的通信協定。
上面的步驟舉例說明了非持續連接配接的使用，其中每個tcp連接配接在伺服器發送一個對象後關閉，即該連接配接并不為其他的對象而持續下來。值得注意的是每個tcp連接配接隻傳輸一個請求封包和一個響應封包。是以在本例中，當使用者請求該web頁面時，要産生11個tcp連接配接。
在上面描述的步驟中，我們有意沒有明确客戶獲得這10個jpeg圖形對象是使用10個串行的tcp連接配接，還是某些jpeg對象使用了一些并行的tcp連接配接。事實上，使用者能夠配置現代浏覽器以控制并行度。在預設方式下，大部分浏覽器打開5～10個并行的tcp連接配接，而每條連接配接處理一個請求響應事務。如果使用者願意，最大并行連接配接數可以設定為1，這樣10條連接配接就會串行建立。我們在下一章會看到，使用并行連接配接可以縮短響應時間。
在繼續讨論之前，我們來簡單估算一下從客戶請求html基本檔案起到該客戶收到整個檔案止所花費的時間。為此，我們給出往返時間（round-trip time，rtt）的定義，該時間是指一個短分組從客戶到伺服器然後再傳回客戶所花費的時間。rtt包括分組傳播時延、分組在中間路由器和交換機上的排隊時延以及分組處理時延（這些在1.4節已經讨論過）。現在考慮當使用者點選超連結時會發生什麼現象。如圖2-7所示，這引起浏覽器在它和web伺服器之間發起一個tcp連接配接；這涉及一次“三次握手”過程，即客戶向伺服器發送一個小tcp封包段，伺服器用一個小tcp封包段做出确認和響應，最後，客戶向伺服器傳回确認。三次握手中前兩個部分所耗費的時間占用了一個rtt。完成了三次握手的前兩個部分後，客戶結合三次握手的第三部分（确認）向該tcp連接配接發送一個http請求封包。一旦該請求封包到達伺服器，伺服器就在該tcp連接配接上發送html檔案。該http請求/響應用去了另一個rtt。是以，粗略地講，總的響應時間就是兩個rtt加上伺服器傳輸html檔案的時間。
2.采用持續連接配接的http
非持續連接配接有一些缺點。首先，必須為每一個請求的對象建立和維護一個全新的連接配接。對于每個這樣的連接配接，在客戶和伺服器中都要配置設定tcp的緩沖區和保持tcp變量，這給web伺服器帶來了嚴重的負擔，因為一台web伺服器可能同時服務于數以百計不同的客戶的請求。第二，就像我們剛描述的那樣，每一個對象經受兩倍rtt的傳遞時延，即一個rtt用于建立tcp，另一個rtt用于請求和接收一個對象。
在采用持續連接配接的情況下，伺服器在發送響應後保持該tcp連接配接打開。在相同的客戶與伺服器之間的後續請求和響應封包能夠通過相同的連接配接進行傳送。特别是，一個完整的web頁面（上例中的html基本檔案加上10個圖形）可以用單個持續tcp連接配接進行傳送。更有甚者，位于同一台伺服器的多個web頁面在從該伺服器發送給同一個客戶時，可以在單個持續tcp連接配接上進行。可以一個接一個地發出對對象的這些請求，而不必等待對未決請求（流水線）的回答。一般來說，如果一條連接配接經過一定時間間隔（一個可配置的逾時間隔）仍未被使用，http伺服器就關閉該連接配接。http的預設模式是使用帶流水線的持續連接配接。我們把量化比較持續連接配接和非持續連接配接性能的任務留作第2、3章的課後習題。鼓勵讀者閱讀文獻［heidemann 1997；nielsen 1997］。
http規範［rfc 1945；rfc 2616］包含了對http封包格式的定義。http封包有兩種：請求封包和響應封包。下面讨論這兩種封包。
1.http請求封包
下面提供了一個典型的http請求封包：
通過仔細觀察這個簡單的請求封包，我們就能知道很多東西。首先，我們看到該封包是用普通的ascii文本書寫的，這樣有一定計算機知識的人都能夠閱讀它。其次，我們看到該封包由5行組成，每行由一個回車和換行符結束。最後一行後再附加一個回車換行符。雖然這個特定的封包僅有5行，但一個請求封包能夠具有更多的行或者至少為一行。http請求封包的第一行叫做請求行（request line），其後繼的行叫做首部行（header line）。請求行有3個字段：方法字段、url字段和http版本字段。方法字段可以取幾種不同的值，包括get、post、head、put和delete。絕大部分的http請求封包使用get方法。當浏覽器請求一個對象時，使用get方法，在url字段帶有請求對象的辨別。在本例中，該浏覽器正在請求對象/somedir/page.html。其版本字段是自解釋的；在本例中，浏覽器實作的是http/1.1版本。
現在我們看看本例的首部行。首部行host:www.someschool.edu指明了對象所在的主機。你也許認為該首部行是不必要的，因為在該主機中已經有一條tcp連接配接存在了。但是，如我們将在2.2.5節中所見，該首部行提供的資訊是web代理高速緩存所要求的。通過包含connection:close首部行，該浏覽器告訴伺服器不希望麻煩地使用持續連接配接，它要求伺服器在發送完被請求的對象後就關閉這條連接配接。user-agent:首部行用來指明使用者代理，即向伺服器發送請求的浏覽器的類型。這裡浏覽器類型是mozilla/5.0，即firefox浏覽器。這個首部行是有用的，因為伺服器可以有效地為不同類型的使用者代理實際發送相同對象的不同版本。（每個版本都由相同的url尋址。）最後，accept-language:首部行表示使用者想得到該對象的法語版本（如果伺服器中有這樣的對象的話）；否則，伺服器應當發送它的預設版本。accept-language:首部行僅是http中可用的衆多内容協商首部之一。
看過一個例子之後，我們再來看看如圖2-8所示的一個請求封包的通用格式。我們看到該通用格式與我們前面的例子密切對應。然而，你可能已經注意到了在首部行（和附加的回車和換行）後有一個“實體體”（entity body）。使用get方法時實體體為空，而使用post方法時才使用該實體體。當使用者送出表單時，http客戶常常使用post方法，例如當使用者向搜尋引擎提供搜尋關鍵詞時。使用post封包時，使用者仍可以向伺服器請求一個web頁面，但web頁面的特定内容依賴于使用者在表單字段中輸入的内容。如果方法字段的值為post時，則實體體中包含的就是使用者在表單字段中的輸入值。
當然，如果不提“用表單生成的請求封包不是必須使用post方法”這一點，那将是失職。html表單經常使用get方法，并在（表單字段中）所請求的url中包括輸入的資料。例如，一個表單使用get方法，它有兩個字段，分别填寫的是“monkeys”和“bananas”，這樣，該url結構為www.somesite.com/animalsearch?monkeys&bananas。在日複一日的網上沖浪中，你也許已經留意到了這種擴充的url。
head方法類似于get方法。當伺服器收到使用head方法的請求時，将會用一個http封包進行響應，但是并不傳回請求對象。應用程式開發者常用head方法進行調試跟蹤。put方法常與web發行工具聯合使用，它允許使用者上傳對象到指定的web伺服器上指定的路徑（目錄）。put方法也被那些需要向web伺服器上傳對象的應用程式使用。delete方法允許使用者或者應用程式删除web伺服器上的對象。
2.http響應封包
下面我們提供了一條典型的http響應封包。該響應封包可以是對剛剛讨論的例子中請求封包的響應。
我們仔細看一下這個響應封包。它有三個部分：一個初始狀态行（status line），6個首部行（header line），然後是實體體（entity body）。實體體部分是封包的主要部分，即它包含了所請求的對象本身（表示為data data data data…）。狀态行有3個字段：協定版本字段、狀态碼和相應狀态資訊。在這個例子中，狀态行訓示伺服器正在使用http/1.1，并且一切正常（即伺服器已經找到并正在發送所請求的對象）。
我們現在來看看首部行。伺服器用connection: close首部行告訴客戶，發送完封包後将關閉該tcp連接配接。date:首部行訓示伺服器産生并發送該響應封包的日期和時間。值得一提的是，這個時間不是指對象建立或者最後修改的時間；而是伺服器從它的檔案系統中檢索到該對象，插入到響應封包，并發送該響應封包的時間。server:首部行訓示該封包是由一台apache web伺服器産生的，它類似于http請求封包中的user-agent:首部行。last-modified:首部行訓示了對象建立或者最後修改的日期和時間。last-modified:首部行對既可能在本地客戶也可能在網絡緩存伺服器上的對象緩存來說非常重要。我們将很快詳細地讨論緩存伺服器（也叫代理伺服器）。content-length:首部行訓示了被發送對象中的位元組數。content-type:首部行訓示了實體體中的對象是html文本。（該對象類型應該正式地由content-type:首部行而不是用檔案擴充名來訓示。）
看過一個例子後，我們再來檢視響應封包的通用格式（如圖2-9所示）。該通用格式能夠與前面例子中的響應封包對應起來。我們補充說明一下狀态碼和它們對應的短語。狀态碼及其相應的短語訓示了請求的結果。一些常見的狀态碼和相關的短語包括：
200 ok:請求成功，資訊在傳回的響應封包中。
301 moved permanently:請求的對象已經被永久轉移了，新的url定義在響應封包的location:首部行中。客戶軟體将自動擷取新的url。
400 bad request:一個通用差錯代碼，訓示該請求不能被伺服器了解。
404 not found:被請求的文檔不在伺服器上。
505 http version not supported:伺服器不支援請求封包使用的http協定版本。
你想看一下真實的http響應封包嗎？這正是我們高度推薦的事，而且也很容易做到。首先用telnet登入到你喜歡的web伺服器上，接下來輸入一個隻有一行的請求封包去請求放在該伺服器上的某些對象。例如，假設你看到指令提示，鍵入：
（在輸入最後一行後連續按兩次回車。）這就打開一個到主機cis.poly.edu的80端口的tcp連接配接，并發送一個http請求封包。你将會看到一個攜帶包括ross教授首頁的html基本檔案的響應封包。如果你隻是想看一下http協定的封包行，而不是擷取對象本身的話，那麼可以用head代替get。最後，用/~banana/代替/~ross/，看看你得到什麼類型的響應封包。
在本節中，我們讨論了http請求封包和響應封包中的一些首部行。http規範中定義了很多可以被浏覽器、web伺服器和web緩存伺服器插入的首部行。我們隻提到了全部首部行中的少數幾個，在2.2.5節中我們讨論網絡web緩存時還會涉及其他幾個。一本可讀性很強的文獻是［krishnamurty 2001］，它對http協定（包括它的首部行和狀态碼）進行了廣泛讨論。
浏覽器是如何決定在一個請求封包中包含哪些首部行的呢？web伺服器又是如何決定在一個響應封包中包含哪些首部行呢？浏覽器産生的首部行與很多因素有關，包括浏覽器的類型和協定版本（例如，http/1.0浏覽器将不會産生任何1.1版本的首部行）、浏覽器的使用者配置（如喜好的語言）、浏覽器目前是否有一個緩存的但是可能超期的對象版本。web伺服器的表現也類似：在産品、版本和配置上都有差異，所有這些都會影響響應封包中包含的首部行。
我們前面提到了http伺服器是無狀态的。這簡化了伺服器的設計，并且允許工程師們去開發可以同時處理數以千計的tcp連接配接的高性能web伺服器。然而一個web站點通常希望能夠識别使用者，可能是因為伺服器希望限制使用者的通路，或者因為它希望把内容與使用者身份聯系起來。為此，http使用了cookie。cookie在［rfc 6265］中定義，它允許站點對使用者進行跟蹤。目前大多數商務web站點都使用了cookie。
如圖2-10所示，cookie技術有4個元件：①在http響應封包中的一個cookie首部行；②在http請求封包中的一個cookie首部行；③在使用者端系統中保留有一個cookie檔案，并由使用者的浏覽器進行管理；④位于web站點的一個後端資料庫。使用圖2-10，我們通過一個典型的例子看看cookie的工作過程。假設susan總是從家中pc使用internet explorer上網，她首次與amazon.com聯系。我們假定過去她已經通路過ebay站點。當請求封包到達該amazon web伺服器時，該web站點将産生一個唯一識别碼，并以此作為索引在它的後端資料庫中産生一個表項。接下來amazon web伺服器用一個包含set-cookie:首部的http響應封包對susan的浏覽器進行響應，其中set-cookie:首部含有該識别碼。例如，該首部行可能是
當susan的浏覽器收到了該http響應封包時，它會看到該set-cookie:首部。該浏覽器在它管理的特定cookie檔案中添加一行，該行包含伺服器的主機名和在set-cookie:首部中的識别碼。值得注意的是該cookie檔案已經有了用于ebay的表項，因為susan過去通路過該站點。當susan繼續浏覽amazon網站時，每請求一個web頁面，其浏覽器就會從該cookie檔案中擷取她對這個網站的識别碼，并放到http請求封包中包括識别碼的cookie首部行中。特别是，發往該amazon伺服器的每個http請求封包都包括以下首部行：
在這種方式下，amazon伺服器可以跟蹤susan在amazon站點的活動。盡管amazon web站點不必知道susan的名字，但它确切地知道使用者1678按照什麼順序、在什麼時間、通路了哪些頁面！amazon使用cookie來提供它的購物車服務，即amazon能夠維護susan希望購買的物品清單，這樣在susan結束會話時可以一起為它們付費。
如果susan再次通路amazon站點，比如說一個星期後，她的浏覽器會在其請求封包中繼續放入首部行cookie:1678。amazon将根據susan過去在amazon通路的網頁向她推薦産品。如果susan也在amazon注冊過，即提供了她的全名、電子郵件位址、郵政位址和信用卡賬号，則amazon能在其資料庫中包括這些資訊，将她的全名與識别碼相關聯（以及她在過去通路過的所有頁面）。這就解釋了amazon和其他一些電子商務網站實作“點選購物”（one-click shopping）的道理，即當susan在後繼的通路中選擇購買某個物品時，她不必重新輸入姓名、信用卡賬号或者位址等資訊了。
從上述讨論中我們看到，cookie可以用于辨別一個使用者。使用者首次通路一個站點時，可能需要提供一個使用者辨別（可能是名字）。在後繼會話中，浏覽器向伺服器傳遞一個cookie首部，進而向該伺服器辨別了使用者。是以cookie可以在無狀态的http之上建立一個使用者會話層。例如，當使用者向一個基于web的電子郵件系統（如hotmail）注冊時，浏覽器向伺服器發送cookie資訊，允許該伺服器在使用者與應用程式會話的過程中辨別該使用者。
盡管cookie常常能簡化使用者的網際網路購物活動，但是它的使用仍具有争議，因為它們被認為是對使用者隐私的一種侵害。如我們剛才所見，結合cookie和使用者提供的賬戶資訊，web站點可以知道許多有關使用者的資訊，并可能将這些資訊賣給第三方。cookie central ［cookie central 2012］包括了對cookie争論的廣泛資訊。
浏覽器建立一個到web緩存器的tcp連接配接，并向web緩存器中的對象發送一個http請求。
web緩存器進行檢查，看看本地是否存儲了該對象副本。如果有，web緩存器就向客戶浏覽器用http響應封包傳回該對象。
如果web緩存器中沒有該對象，它就打開一個與該對象的初始伺服器（如www.someschool.edu）的tcp連接配接。web緩存器則在這個緩存器到伺服器的tcp連接配接上發送一個對該對象的http請求。在收到該請求後，初始伺服器向該web緩存器發送具有該對象的http響應。
當web緩存器接收到該對象時，它在本地存儲空間存儲一份副本，并向客戶的浏覽器用http響應封包發送該副本（通過現有的客戶浏覽器和web緩存器之間的tcp連接配接）。
值得注意的是web緩存器是伺服器同時又是客戶。當它接收浏覽器的請求并發回響應時，它是一個伺服器。當它向初始伺服器送出請求并接收響應時，它是一個客戶。
web緩存器通常由isp購買并安裝。例如，一所大學可能在它的校園網上安裝一台緩存器，并且将所有校園網上的使用者浏覽器配置為指向它。或者，一個主要的住宅isp（例如aol）可能在它的網絡上安裝一台或多台web緩存器，并且預先配置其配套的浏覽器指向這些緩存器。
在網際網路上部署web緩存器有兩個原因。首先，web緩存器可以大大減少對客戶請求的響應時間，特别是當客戶與初始伺服器之間的瓶頸帶寬遠低于客戶與web緩存器之間的瓶頸帶寬時更是如此。如果在客戶與web緩存器之間有一個高速連接配接（情況常常如此），并且如果使用者所請求的對象在web緩存器上，則web緩存器可以迅速将該對象傳遞給使用者。其次，如我們馬上用例子說明的那樣，web緩存器能夠大大減少一個機構的接傳入連結路到網際網路的通信量。通過減少通信量，該機構（如一家公司或者一所大學）就不必急于增加帶寬，是以降低了費用。此外，web緩存器能從整體上大大減低網際網路上的web流量，進而改善了所有應用的性能。
圖2-12 一個機構網絡與網際網路之間的瓶頸為了深入了解緩存器帶來的好處，我們考慮在圖2-12場景下的一個例子。該圖顯示了兩個網絡，即機構（内部）網絡和公共網際網路的一部分。機構網絡是一個高速的區域網路，它的一台路由器與網際網路上的一台路由器通過一條15mbps的鍊路連接配接。這些初始伺服器與網際網路相連但位于全世界各地。假設對象的平均長度為1mb，從機構内的浏覽器對這些初始伺服器的平均通路速率為每秒15個請求。假設http請求封包小到可以忽略，因而不會在網絡中以及接傳入連結路（從機構内部路由器到網際網路路由器）上産生什麼通信量。我們還假設在圖2-12中從網際網路接傳入連結路一側的路由器轉發http請求封包（在一個ip資料報中）開始，到它收到其響應封包（通常在多個ip資料報中）為止的時間平均為2秒。我們非正式地将該持續時延稱為“網際網路時延”。
總的響應時間，即從浏覽器請求一個對象到接收到該對象為止的時間，是區域網路時延、接入時延（即兩台路由器之間的時延）和網際網路時延之和。我們來粗略地估算一下這個時延。區域網路上的流量強度（參見1.4.2節）為
（15個請求/s）×（1mb/請求）/（100mbps）=0.15
然而接傳入連結路上的流量強度（從網際網路路由器到機構路由器）為
（15個請求/s）×（1mb/請求）/（15mbps）=1
區域網路上強度為0.15的通信量最多導緻數十毫秒的時延，是以我們可以忽略區域網路時延。然而，如在1.4.2節讨論的那樣，如果流量強度接近1（就像在圖2-12中接傳入連結路的情況那樣），鍊路上的時延會變得非常大并且無限增長。是以，滿足請求的平均響應時間将在分鐘的量級上。顯然，必須想辦法來改進時間響應特性。
一個可能的解決辦法就是增加接傳入連結路的速率，如從15mbps增加到100mbps。這可以将接傳入連結路上的流量強度減少到0.15，這樣一來，兩台路由器之間的鍊路時延也可以忽略了。這時，總的響應時間将大約為2秒鐘，即為網際網路時延。但這種解決方案也意味着該機構必須将它的接傳入連結路由15mbps更新為100mbps，這是一種代價很高的方案。
現在來考慮另一種解決方案，即不更新鍊路帶寬而是在機構網絡中安裝一個web緩存器。這種解決方案如圖2-13所示。實踐中的命中率（即由一個緩存器所滿足的請求的比率）通常在0.2～0.7之間。為了便于闡述，我們假設該機構的緩存命中率為0.4。因為客戶和緩存連接配接在一個相同的高速區域網路上，這樣40%的請求将幾乎立即會由緩存器得到響應，時延約在10ms以内。然而，剩下的60%的請求仍然要由初始伺服器來滿足。但是隻有60%的被請求對象通過接傳入連結路，在接傳入連結路上的流量強度從1.0減小到0.6。一般而言，在15mbps鍊路上，當流量強度小于0.8時對應的時延較小，約為幾十毫秒。這個時延與2秒網際網路時延相比是微不足道的。考慮這些之後，平均時延是以為0.4×（0.010秒）+0.6×（2.01秒） 圖2-13 為機構網絡添加一台緩存器這略大于1.2秒。是以，第二種解決方案提供的響應時延甚至比第一種解決方案更低，也不需要該機構更新它到網際網路的鍊路。該機構理所當然地要購買和安裝web緩存器。除此之外其成本較低，很多緩存器使用了運作在廉價pc上的公共域軟體。
通過使用内容分發網絡（content distribution network，cdn），web緩存器正在網際網路中發揮着越來越重要的作用。cdn公司在網際網路上安裝了許多地理上分散的緩存器，因而使大量流量實作了本地化。有多個共享的cdn（例如akamai和limelight）和專用的cdn（例如谷歌和微軟）。我們将在第7章中更為詳細地讨論cdn。
盡管高速緩存能減少使用者感受到的響應時間，但也引入了一個新的問題，即存放在緩存器中的對象副本可能是陳舊的。換句話說，儲存在伺服器中的對象自該副本緩存在客戶上以後可能已經被修改了。幸運的是，http協定有一種機制，允許緩存器證明它的對象是最新的。這種機制就是條件get（conditional get）方法。如果：①請求封包使用get方法；并且②請求封包中包含一個“if-modified-since:”首部行。那麼，這個http請求封包就是一個條件get請求封包。
為了說明get方法的操作方式，我們看一個例子。首先，一個代理緩存器（proxy cache）代表一個請求浏覽器，向某web伺服器發送一個請求封包：
其次，該web伺服器向緩存器發送具有被請求的對象的響應封包：
該緩存器在将對象轉發到請求的浏覽器的同時，也在本地緩存了該對象。重要的是，緩存器在存儲該對象時也存儲了最後修改日期。第三，一個星期後，另一個使用者經過該緩存器請求同一個對象，該對象仍在這個緩存器中。由于在過去的一個星期中位于web伺服器上的該對象可能已經被修改了，該緩存器通過發送一個條件get執行最新檢查。具體說來，該緩存器發送：
值得注意的是if-modified-since:首部行的值正好等于一星期前伺服器發送的響應封包中的last-modified:首部行的值。該條件get封包告訴伺服器，僅當自指定日期之後該對象被修改過，才發送該對象。假設該對象自2011年9月7日09:23:24後沒有被修改。接下來的第四步，web伺服器向該緩存器發送一個響應封包：
我們看到，作為對該條件get方法的響應，該web伺服器仍發送一個響應封包，但并沒有在該響應封包中包含所請求的對象。包含該對象隻會浪費帶寬，并增加使用者感受到的響應時間，特别是如果該對象很大的時候更是如此。值得注意的是在最後的響應封包中，狀态行中為304 not modified，它告訴緩存器可以使用該對象，能向請求的浏覽器轉發它（該代理緩存器）緩存的該對象副本。
我們現在完成了對http的讨論，這是我們詳細學習的第一個網際網路協定（應用層協定）。我們已經學習了http封包的格式，學習了當發送和接收這些封包時web客戶和伺服器所采取的動作。我們還學習了一點web應用程式基礎設施，包括緩存、cookie和後端資料庫，所有這些都以某種方式與http協定有關。