轉載： http://hi.baidu.com/yanxionglu/blog/item/0ea9171e6c3da88087d6b6ac.html

歷史上，先后問世了多個具有重大社會影響的電子通信技術。第一個這樣的技術是19世紀70年代發明的電話。電話使得不在同一物理位置的兩人得以實時地口頭交流。它對社會有重大的影響——有好的也有壞的。下一個電子通信技術是20世紀20年代及30年代問世的廣播收音機/電視機。廣播收音機/電視機使得人們能收聽收視大量的音頻和視頻信息。它對社會同樣有重大的影響——有好的也有壞的。改變了人們的生活與工作方式的第三個重大通信技術是web。web 最吸引用戶的也許是它的隨選(on demand)操作性。用戶只在想要時收到所要的東西。這一點不同于廣播收音機/電視機。廣播收音機/電視機的用戶是在其內容供應商播出內容期間被迫收聽收視。除了隨選操作性，Web還有許多大家喜愛的其他精彩特性。任何個人都可以極其容易地在Web上公布任何信息;任何人都可能以極低的成本成為發行人。超鏈接和搜索引擎幫助我們在Web站點的海洋中導航。圖形和動畫刺激著我們的感官。表單、Java小應用程序、Activex控件以及其他許多設備使得我們能與Web頁面和站點交互。Web還越來越普遍地提供存放在因特網中的、可隨選訪問(即點播)的大量音頻和視頻材料的菜單接口。

HTTP概貌

HTTP的發展是萬維網協會（World Wide Web Consortium）和Internet工作小組（Internet Engineering Task Force）合作的結果，（他們）最終發布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協議的我們今天普遍使用的一個版本——HTTP 1.1。

HTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口為80）的HTTP請求。我們稱這個客戶端叫用戶代理（user agent）。應答的服務器上存儲著（一些）資源，比如HTML文件和圖像。（我們稱）這個應答服務器為源服務器（origin server）。在用戶代理和源服務器中間可能存在多個中間層，比如代理，網關，或者隧道（tunnels）。盡管TCP/IP協議是互聯網上最流行的應用，HTTP協議并沒有規定必須使用它和（基于）它支持的層。事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。

Web的應用層協議HTTP是Web的核心。HTTP在Web的客戶程序和服務器程序中得以實現。運行在不同端系統上的客戶程序和服務器程序通過交換HTTP消息彼此交流。HTTP定義這些消息的結構以及客戶和服務器如何交換這些消息。在詳細解釋HTTP之前，我們先來回顧一些web中的術語。

Web頁面(web page，也稱為文檔)由多個對象構成。對象(object)僅僅是可由單個URL尋址的文件，例如HTML文件、JPG圖像、GIF圖像、JAVA小應用程序、語音片段等。大多數Web頁面由單個基本HTML文件和若干個所引用的對象構成。例如，如果一個Web頁面包含HTML文本和5個JPEG圖像，那么它由6個對象構成，即基本HTML文件加5個圖像。基本HTML文件使用相應的URL來引用本頁面的其他對象。每個URL由存放該對象的服務器主機名和該對象的路徑名兩部分構成。例如，在如下的URL中:
www.cnpaf.net/picture.gif

www.cnpaf.net是一個主機名，/picture.gif是一個路徑名。瀏覽器是web的用戶代理，它顯示所請求的Web頁面，并提供大量的導航與配置特性。Web瀏覽器還實現HTTP的客戶端，因此在web上下文中，我們會從進程意義上互換使用“瀏覽器”和“客戶端”兩詞。流行的Web瀏覽器有Netscape Communicator，firefox和微軟的IE等。Web服務器存放可由URL尋址的Web對象。web服務器還實現HTTP的服務器端。流行的 Web服務器有Apache、微軟的IIS以及Netscape Enterprise Server。Netcraft提供了web服務器的概要剖析[Netcrft 2000]。

HTTP定義Web客戶(即瀏覽器)如何從web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶。當用戶請求一個Web頁面(譬如說點擊某個超鏈接)時，瀏覽器把請求該頁面中各個對象的HTTP請求消息發送給服務器。服務器收到請求后，以運送含有這些對象HTTP響應消息作為響應。到1997年底，基本上所有的瀏覽器和Web服務器軟件都實現了在RFC 1945中定義的HTTP/1.0版本。1998年初，一些Web服務器軟件和瀏覽器軟件開始實現在RFC 2616中定義的HTTP/1.1版本。H1TP/1.1與HTTP/1.0后向兼容;運行1.1版本的web服務器可以與運行1.0版本的瀏覽器“對話”，運行1.1版本的瀏覽器也可以與運行1.0版本的Web服務器“對話”。

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連接一開始以相對緩慢的速率傳輸數據，然而只要網絡不擁塞，每個連接可以迅速上升到相對較高的速率。這個慢速傳輸的初始階段稱為緩啟動(slow start)。

需要注意的是，在向客戶發送所請求文件的同時，服務器并沒有存儲關于該客戶的任何狀態信息。即便某個客戶在幾秒鐘內再次請求同一個對象，服務器也不會響應說:自己剛剛給它發送了這個對象。相反，服務器重新發送這個對象，因為它已經徹底忘記早先做過什么。既然HTTP服務器不維護客戶的狀態信息，我們于是說HTTP是一個無狀態的協議(stateless protocol)。

非持久連接和持久連接

HTTP既可以使用非持久連接(nonpersistent connection)，也可以使用持久連接(persistent connection)。HTTP/1.0使用非持久連接，HTTP/1.1默認使用持久連接。

非持久連接

讓我們查看一下非持久連接情況下從服務器到客戶傳送一個Web頁面的步驟。假設該頁面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一臺服務器主機中。 再假設該基本HTML文件的URL為:www.cnpaf.net/index.html。

下面是具體步騾:

1.HTTP客戶初始化一個與服務器主機www.cnpaf.net中的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頁面沒有任何關系，其規范([RFC 1945]和[RFC 2616I)僅僅定義HTTP客戶程序和服務器程序之間的通信協議。

上述步驟之所以稱為使用非持久連接，原因是每次服務器發出一個對象后，相應的TCP連接就被關閉，也就是說每個連接都沒有持續到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生11個TCP連接。

在上述步騾中，我們有意不說清客戶是通過10個串行的TCP連接先后取得所有JPEG對象，還是通過并行的TCP連接同時取得其中某些JPEG 對象。實際上，現今的瀏覽器允許用戶通過配置來控制并行連接的程度。大多數瀏覽器默認可以打開5到10個并行的TCP連接，每個連接處理一個請求—響應事務。用戶要是喜歡，可以把最大并行連接數設為1，那樣的話這10個連接是串行地建立的。使用并行連接可以縮短響應時間。

繼續介紹之前，先估算一下從客戶請求基本HTML文件到它收到該文件所經歷的時間。為此我們定義往返時間(round trip time，簡稱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服務器在某個連接閑置一段特定時間后關閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線 (without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應后才發出新的請求。這種情況下，web頁面所引用的每個對象 (上例中的10個圖像)都經歷1個RTT的延遲，用于請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，服務器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務器資源便閑置了。

HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發出一個請求，因而HTTP客戶可以一個接一個緊挨著發出各個引用對象的請求。服務器收到這些請求后，也可以一個接一個緊挨著發出各個對象。如果所有的請求和響應都是緊挨著發送的，那么所有引用到的對象一共只經歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個TCP連接，服務器發出第一個對象后就不必再以一開始的緩慢速率發送后續對象。相反，服務器可以按照第一個對象發送完畢時的速率開始發送下一個對象。

HTTP消息格式：請求消息和相應消息

HTTP規范1.0[RPcl945]和1.1[RFC 2616]定義了HTTP消息的格式。HTTP消息分為請求消息和響應稍息兩類。下面我們分別進行介紹。

HTTP請求消息

下面是一個典型的HTTP請求消息:

GET /somedir/page.html HTTP/1.1
Host:www.cnpaf.net
Connection:close
User-agent:Mozilla/4.0
Accept-language:zh-cn
(額外的回車符和換行符)

仔細檢查這個簡單的請求消息，我們可從中學到不少東西。首先，這個消息是用普通的ASCII文本書寫的。其次，這個消息共有5行(每行以一個回車符和一個換行符結束)，最后一行后面還有額外的一個回車特和換行符。當然，一個請求消息可以不止這么多行，也可以僅僅只有一行。該請求消息的第一行稱為請求行(request line)，后續各行都稱為頭部行(header)。請求行有3個字段：方法字段、URL字段、HTTP版本宇段。方法字段有若干個值可供選擇，包括 GET、POST和HEAD。HTTP請求消息絕大多數使用GET方法，這是瀏覽器用來請求對象的方法，所請求的對象就在URL字段中標識。本例表明瀏覽器在請求對象/somedir/page.html。版本字段是不言自明的；本例中瀏覽器實現的是HTTP/1.1版本。

現在看一下本例中的各個頭部行。頭部行Host:www.cnpaf.net定存放所請求對象的主機。請求消息中包含頭部 Connection:close是在告知服務器本瀏覽器不想使用持久連接；服務器發出所請求的對象后應關閉連接。盡管產生這個請求消息的瀏覽器實現的是 HTTP/1.1版本，它還是不想使用持久連接。User-agent頭部行指定用戶代理，也就是產生當前請求的瀏覽器的類型。本例的用戶代理是 Mozilla/4.0，它是Nelscape瀏覽器的一個版本。這個頭部行很有用，因為服務器實際上可以給不同類型的用戶代理發送同一個對象的不同版本 (這些不同版本位用同一個URL尋址)。最后，Accept-languag頭部行指出要是所請求對象有簡體中文版本，那么用戶寧愿接收這個版本；如果沒有這個語言版本，那么服務器應該發送其默認版本。Accept-languag:僅僅是HTTP的眾多內容協商頭部之一。

一般格式中還有一個位于各個頭部(及額外的回車符和換行符)之后的“附屬體”(body)。附屬體不在GET方法中使用，而是在POST方法中使用。POST方法適用于需由用戶填寫表單的場合，如往google搜索引擎中填入待搜索的詞。用戶提交表單后，瀏覽器就像用戶點擊了超鏈接那樣仍然從服務器請求一個Web頁面，不過該頁面的具體內容卻取決于用戶填寫在表單各個字段中的值。如果瀏覽器使用POST方法提出該請求，那么請求消息附屬體中包含的是用戶填寫在表單各個字段中的值。與GET方法類似的是HEAD方法，兩者的差別只是服務器在對HEAD方法的響應消息中去掉了所請求的對象，其他內容則與對GET方法的響應消息一樣。HEAD方法通常用于HTTP服務器軟件開發人員進行調試。

HTTP協議中定義了八種方法（有時也叫“動作”）來表示對指定數據的操作。有些方法（比如HEAD, GET, OPTIONS, and TRACE) 被定義為安全方法，這些方法針對的只是信息的返回，并不會改變服務器的狀態（換句話說就是這些方法不會產生副作用）。不安全的方法（例如POST, PUT and DELETE) 應該用特殊的方式向用戶展示，通常是按鈕而不是鏈接，這樣就可以使用戶意識到可能要負的責任（例如一個按鈕帶來的資金交易。）

HEAD
（Head方法）要求響應與相應的GET請求的響應一樣，但是沒有響應體（response body）。這用來獲得響應頭（response header）中的元數據信息（meta-infomation）有（很大）幫助，（因為）它不需要傳輸所有的內容。

GET
（Get方法用來）請求指定的資源。它是目前網上最常用的方法。它不應該用于一些會造成副作用的操作中
（在網絡應用中用它來提交動作是一種常見的錯誤用法）。（細節請）參考后面的“安全方法”（這一節）。

POST
（POST方法用來）向指定的資源提交需要處理的數據。這些數據寫在請求的內容里。（POST請求）可以導致新資源的產生和已有資源的更新。

PUT
上傳指定資源

DELETE
刪除指定資源

TRACE
（Trace方法告訴服務器端）返回收到的請求。客戶端可以（通過此方法）察看在請求過程中中間服務器添加或者改變哪些內容。

OPTIONS
返回服務器（在指定URL上）支持的HTTP方法。通過請求“*”而不是指定的資源，這個方法可以用來檢查網絡服務器的功能。

CONNECT
將請求的連接轉換成透明的TCP/IP通道，通常用來簡化通過非加密的HTTP代理的SSL-加密通訊（HTTPS）。
HTTP服務器至少應該實現Get和Head方法，可能的話，也實現OPTIONS方法。

HTTP響應消息

下面是一個典型的HTTP響應消息:

HTTP/1.1 200 0K
Connectlon:close
Date: Thu, 13 Oct 2005 03:17:33 GMT
Server: Apache/2.0.54 (Unix)
Last—Nodified:Mon,22 Jun 1998 09;23;24 GMT
Content—Length:682l
Content—Type:text/html
(數據 數據 數據 數據 數據…………)

這個響應消息分為3部分：1個起始的狀態行(status line)，6個頭部行、1個包含所請求對象本身的附屬體。狀態行有3個字段：協議版本字段、狀態碼字段、原因短語字段。本例的狀態行表明，服務器使用 HTTP/1.1版本，響應過程完全正常(也就是說服務器找到了所請求的對象，并正在發送)。

現在看一下本例中的各個頭部行。服務器使用Connectlon:close頭部行告知客戶自己將在發送完本消息后關閉TCP連接。Date: 頭部行指出服務器創建并發送本響應消息的日期和時間。注意，這并不是對象本身的創建時間或最后修改時間，而是服務器把該對象從其文件系統中取出，插入響應消息中發送出去的時間。Server:頭部行指出本消息是由Apache服務器產生的；它與HTTP請求消息中的User-agent:頭部行類似。 Last—Nodified:頭部行指出對象本身的創建或最后修改日期或時間。Last—Nodified:頭部對于對象的高速緩存至關重要，且不論這種高速緩存是發生在本地客戶主機上還是發生在網絡高速緩存服務器主機(也就是代理服務器主機)上。Content—Length:頭部行指出所發送對象的字節數。Content—Type:頭部行指出包含在附屬體中的對象是HTML文本。對象的類型是由Content—Type:頭部而不是由文件擴展名正式指出的。

注意，如果服務器收到一個HTTP/1.0的請求，那么它即使是一個HTTP/1.1服務器，也不會使用持久連接。相反，這樣的HTTP/1.1服務器會在發出所請求的對象后關閉TCP連接。這么做是必要的，因為HTTP/1.0客戶期待服務器馬上關閉連接。

響應消息中的狀態碼和原因短語指示相應請求的處理結果。

●200 0K：請求成功，所請求信息在響應消息中返回。
●301 Moved Permanently：所請求的對象己永久性遷移；新的URL在本響應消息的Location:頭部指出。客戶軟件會自動請求這個新的URL。
●400 Bad Request;：表示服務器無法理解相應請求的普通錯誤的狀態碼
●404 Not Found：服務器上不存在所請求的文檔。
●HTTP Version Not Support：服務器不支持所請求的HTTP協議版本。

你想如何看到一個真實的HTTP應答消息呢?這非常簡單。可以使用nc工具連接到你喜歡的服務器(nc/netcat是一個黑客很喜歡用的工具，可以方便在主機之間建立TCP連接)，然后輸入一行請求消息，用來請求位于該服務器上的某個對象。例如，如果你可以輸入以下指令:

nc www.cnpaf.net 80
GET /index.shtml　HTTP/1.0

(在輸入第二行之后，敲兩次回車)，這就打開了一個到主機www.cnpaf.net的端口80的TCP連接，然后發送HTTP GET命令。你應該能看到包含著YESKY主頁的基本HTML文件的應答消息。如果你想只看到HTTP消息行而不接收該對象本身，那么就把上面的GET換成HEAD。最后，看一下能得到什么樣的應答消息。

在這里我們討論了大量能夠在HTTP請求和應答消息中使用的頭部行。HTTP規范(尤其是HTTP/1.1)定義了更多可以由瀏覽器、Web服務器和網絡緩沖服務器插入的頭部行。

我們可以便用nc工具完全控制在請求消息中包含哪些頭部，那么瀏覽器如何決定該在請求消息個包含哪些頭部呢?Web服務器又是如何決定該在響應消息中包含哪些頭部?瀏覽器是根據自己的用戶代理類型、所支持的HTTP版本(HTTP/1.0版本的瀏覽器自然不會產生HTTP/1.1版本的頭部)、用戶對瀏覽器的配置(如所偏愛的語言)等因素生成請求消息中的各個頭部的。web服務器有類似的情形:它們有不同的產品、版本和配置，所有這些因素都會影響在響應消息中包含哪些頭部。

本文討論過的和即將討論的用于HTTP請求消息和響應消息中的頭部僅僅是很小的一部分，HTTP規范中定義了更多可用的頭部，可以查閱相關的RFC文檔進行更詳細的了。

用戶—服務器交互

身份認證和cookie

我們已經知道HTTP服務器是無狀態的。這樣的處理可以簡化服務器程序的設計，以便開發出更高性能的Web服務器軟件。然而，一個Web站點往往有標識其用戶的需求，因為其web服務器可能希望限制用戶的訪問，也可能想要根據用戶的身份來提供內容。HTTP提供了兩種幫助服務器標識用戶的機制：身份認證和cookie。

身份認證許多web站點要求用戶提供一個用戶名—口令對才能訪問存放在其服務器中的文檔。這種要求稱為身份認證(authentication)。HTTP提供特殊的狀態碼和頭部來幫助Web站點執行身份認證。我們通過查看一個例子來領會這些特殊的狀態碼和頭部如何工作。假設有—個客戶在請求來自某個服務器的一個對象，而該服務器要求用戶授予權限。

客戶首先發送一個不合特殊頭部的普通請求消息。服務器以空的附屬體和一個“401Authorization Required”狀態碼作為響應。服務器還在這個響應消息中包含“個WWW-Authenticate:頭部，說明具體如何執行身份認證。這個頭部的典型值是指出用戶需要提供一個用戶名—口令對。

客戶收到這個響應消息后提示用戶輸入用戶名和口令，然后重新發送請求消息。這一回客戶在請求消息中包含了一個Authorization:頭部，其中包含有用戶輸入的用戶名和口令。

取得第一個對象后，客戶在同為請求該服務器上對象的后續請求中繼續發送這個用戶名—口令對。這個做法一般將持續到用戶關閉瀏覽器為止。在瀏覽器未被關閉之前，這個用戶名—口令對是高速緩存著的，因此瀏覽器不會每請求一個對象就提示用戶輸入一次用戶名和口令。通過上述方式，要求用戶授權的Web站點就能標識出每個請求的用戶了。

我們需要知道，HTTP執行的是一種相當脆弱的身份認證方式，不難攻破。現代有很多更為安全的認證方式，我們會在以后介紹。

cookie是一種可讓Web站點用來跟蹤用戶的候選機制，定義在RFC 2109中。有些Web站點使用cookie，其他Web站點則不用。下面查看一個例子。假設一個客戶首次聯系一個使用cookie的web站點。服務器會在其響應中包含一個Set—Cookie:頭部。該頭部的值可以是一個由Web服務器產生的客戶標識數.例如:

Set-Cookie:1678453

客戶收到這個響應消息，看到其中的Set-Cookie:頭部和標識數后，會在存放在客戶主機中的某個特殊的cookie文件中添加一行。這一行一般包含服務器主機的主機名和這個與用戶關聯的標識數。在一段時間(如一個星期)之后請求同一個服務器時，由同一個用戶啟動的新客戶會在請求消息中包含一個cookie頭部，其值為早先由該服務器產生的標識數，例如:Cookie:1678453

在這種方式中，服務器并不知道提出請求的用戶的用戶名，但是它確實知道該用戶與一個星期前提出請求的用戶是同一個。

Web服務器有多個使用coohe的目的:

●如果服務器要求身份認證，但又不想在同一用戶每次訪問本Web站點時都麻煩他輸入用戶名和口令，那么可以設置一個cookie。
●如果服務器想要記住用戶的偏好，以便在他們后續訪問期間有目的地提供廣告，那么可以設置一個cookie。
●如果web站點提供購物服務，那么服務器可以使用cookie跟蹤用戶購買的物品，就是建立一個虛擬的購物車。

需指出的是，cookie不適用于會從不同主機訪問同一web站點的游動用戶。這種情況下，該web站點會把同一個用戶在不同主機上的使用看成是由新的用戶執行的。

帶條件的GET

Web高速緩存技術通過就近存取先前取得的對象來降低對象檢索延遲，減少因特網上的web流量。Web的高速緩存既可以駐留在客戶主機中，也可以駐留在中間網絡高速緩存服務器主機中。我們將在稍后討論網絡高速緩存，這里只關注客戶的高速緩存。

Web高速緩存在降低用戶可感知的響應時間的同時，卻引入了一個新的問題——高速緩存中存放的對象的拷貝可能是過期的。換句話說，存放在web 服務器中的對象可能己在客戶高速緩存下它的一個拷貝之后被修改了。幸運的是，HTTP提供一個專門的機制，使得在允許客戶進行高速緩存的同時，仍確保傳遞給瀏覽器的所有對象都是最新的。這個機制稱為帶條件的GET(conditional GET)。滿足條件(1)使用GET方法和(2)包含If-Modified-Since:頭部的HTTP請求消息就是所謂的帶條件的Get消息。

我們通過查看一個例子來說明帶條件的GET如何工作，向服務器請求一個尚未高速緩存的對象:

GET /fruit/kiwi.gif HTTP/1.0
User—agent: Mozilla/4.0

接著，web服務器把帶這個對象的一個響應消息發送給客戶:

HTTP/1.0 200 OK
Date: Thu, 13 Oct 2005 05:33:47 GMT
Server: Apache/2.0.54 (Unix)
Last-Modified:Thu, 13 Oct 2005 02:32:47 GMT
Content-Type:image/gif
(數據 數據 數據 數據 數據……)

客戶把這個對象顯示給用戶，同時把它保存在自己的本地高速緩存中客戶還隨該對象本身高速緩存最后修改日期與時間。一個星期之后，同一個用戶請求同一個對象，而該對象仍然存放在高速緩存中。既然web服務器中的該對象有可能已在最近一個星期被修改過，于是瀏覽器發出一個帶條件的GET消息，執行判定高速緩存的對象拷貝是否為最新的檢查；

GET /fruit/kiwi.gif HTTP/1.0
User—agent: Mozilla/4.0
If—Modlfied—Since:Thu, 13 Oct 2005 02:32:47 GMT

其中，If—Modlfied—Since:頭部的值就等于一個星期前由服務器發送的Last-Modified:頭部的值。這個帶條件的 GET消息告知服務器，只有在該對象自所指定的時間以來被修改了的前提下才發送它。假設該對象在這段時間內未曾被修改過，那么服務器將發送一個附屬體為空的響應消息給客戶；

HTTP/1.0 304 Not Modified
Date: Thu, 20 Oct 2005 05:33:47 GMT
Server: Apache/2.0.54 (Unix)

我們看到，web服務器仍然發送—個響應消息作為帶條件的GET消息的響應，不過其中不包含所請求的對象。包含該對象只會浪費帶寬，并延長用戶可感知的響應時間，特別是在該對象很大的時候。注意，這個響應消息的狀態為“304 Not Modified”，它告知客戶可以放心使用所請求對象的高速緩存版本。

以上內容是作者在互聯網上搜索整理所得...?

總結

以上是生活随笔為你收集整理的HTTP协议--概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。