轉(zhuǎn)載： http://hi.baidu.com/yanxionglu/blog/item/0ea9171e6c3da88087d6b6ac.html

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

HTTP概貌

HTTP的發(fā)展是萬(wàn)維網(wǎng)協(xié)會(huì)（World Wide Web Consortium）和Internet工作小組（Internet Engineering Task Force）合作的結(jié)果，（他們）最終發(fā)布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協(xié)議的我們今天普遍使用的一個(gè)版本——HTTP 1.1。

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

Web的應(yīng)用層協(xié)議HTTP是Web的核心。HTTP在Web的客戶程序和服務(wù)器程序中得以實(shí)現(xiàn)。運(yùn)行在不同端系統(tǒng)上的客戶程序和服務(wù)器程序通過交換HTTP消息彼此交流。HTTP定義這些消息的結(jié)構(gòu)以及客戶和服務(wù)器如何交換這些消息。在詳細(xì)解釋HTTP之前，我們先來回顧一些web中的術(shù)語(yǔ)。

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

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

HTTP定義Web客戶(即瀏覽器)如何從web服務(wù)器請(qǐng)求Web頁(yè)面，以及服務(wù)器如何把Web頁(yè)面?zhèn)魉徒o客戶。當(dāng)用戶請(qǐng)求一個(gè)Web頁(yè)面(譬如說點(diǎn)擊某個(gè)超鏈接)時(shí)，瀏覽器把請(qǐng)求該頁(yè)面中各個(gè)對(duì)象的HTTP請(qǐng)求消息發(fā)送給服務(wù)器。服務(wù)器收到請(qǐng)求后，以運(yùn)送含有這些對(duì)象HTTP響應(yīng)消息作為響應(yīng)。到1997年底，基本上所有的瀏覽器和Web服務(wù)器軟件都實(shí)現(xiàn)了在RFC 1945中定義的HTTP/1.0版本。1998年初，一些Web服務(wù)器軟件和瀏覽器軟件開始實(shí)現(xiàn)在RFC 2616中定義的HTTP/1.1版本。H1TP/1.1與HTTP/1.0后向兼容;運(yùn)行1.1版本的web服務(wù)器可以與運(yùn)行1.0版本的瀏覽器“對(duì)話”，運(yùn)行1.1版本的瀏覽器也可以與運(yùn)行1.0版本的Web服務(wù)器“對(duì)話”。

HTTP/1.0和HTTP/1.1都把TCP作為底層的傳輸協(xié)議。HTTP客戶首先發(fā)起建立與服務(wù)器TCP連接。一旦建立連接，瀏覽器進(jìn)程和服務(wù)器進(jìn)程就可以通過各自的套接字來訪問TCP。如前所述，客戶端套接字是客戶進(jìn)程和TCP連接之間的“門”，服務(wù)器端套接字是服務(wù)器進(jìn)程和同一TCP連接之間的“門”。客戶往自己的套接字發(fā)送HTTP請(qǐng)求消息，也從自己的套接字接收HTTP響應(yīng)消息。類似地，服務(wù)器從自己的套接字接收HTTP請(qǐng)求消息，也往自己的套接字發(fā)送HTTP響應(yīng)消息。客戶或服務(wù)器一旦把某個(gè)消息送入各自的套接字，這個(gè)消息就完全落入TCP的控制之中。TCP給HTTP提供一個(gè)可靠的數(shù)據(jù)傳輸服務(wù);這意味著由客戶發(fā)出的每個(gè)HTTP請(qǐng)求消息最終將無(wú)損地到達(dá)服務(wù)器，由服務(wù)器發(fā)出的每個(gè)HTTP響應(yīng)消息最終也將無(wú)損地到達(dá)客戶。我們可從中看到分層網(wǎng)絡(luò)體系結(jié)構(gòu)的一個(gè)明顯優(yōu)勢(shì)——HTTP不必?fù)?dān)心數(shù)據(jù)會(huì)丟失，也無(wú)需關(guān)心TCP如何從數(shù)據(jù)的丟失和錯(cuò)序中恢復(fù)出來的細(xì)節(jié)。這些是TCP和協(xié)議棧中更低協(xié)議層的任務(wù)。

TCP還使用一個(gè)擁塞控制機(jī)制。該機(jī)制迫使每個(gè)新的TCP連接一開始以相對(duì)緩慢的速率傳輸數(shù)據(jù)，然而只要網(wǎng)絡(luò)不擁塞，每個(gè)連接可以迅速上升到相對(duì)較高的速率。這個(gè)慢速傳輸?shù)某跏茧A段稱為緩啟動(dòng)(slow start)。

需要注意的是，在向客戶發(fā)送所請(qǐng)求文件的同時(shí)，服務(wù)器并沒有存儲(chǔ)關(guān)于該客戶的任何狀態(tài)信息。即便某個(gè)客戶在幾秒鐘內(nèi)再次請(qǐng)求同一個(gè)對(duì)象，服務(wù)器也不會(huì)響應(yīng)說:自己剛剛給它發(fā)送了這個(gè)對(duì)象。相反，服務(wù)器重新發(fā)送這個(gè)對(duì)象，因?yàn)樗呀?jīng)徹底忘記早先做過什么。既然HTTP服務(wù)器不維護(hù)客戶的狀態(tài)信息，我們于是說HTTP是一個(gè)無(wú)狀態(tài)的協(xié)議(stateless protocol)。

非持久連接和持久連接

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

非持久連接

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

下面是具體步騾:

1.HTTP客戶初始化一個(gè)與服務(wù)器主機(jī)www.cnpaf.net中的HTTP服務(wù)器的TCP連接。HTTP服務(wù)器使用默認(rèn)端口號(hào)80監(jiān)聽來自HTTP客戶的連接建立請(qǐng)求。
2.HTTP客戶經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字發(fā)出—個(gè)HTTP請(qǐng)求消息。這個(gè)消息中包含路徑名/somepath/index.html。
3.HTTP服務(wù)器經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字接收這個(gè)請(qǐng)求消息，再?gòu)姆?wù)器主機(jī)的內(nèi)存或硬盤中取出對(duì)象/somepath/index.html，經(jīng)由同一個(gè)套接字發(fā)出包含該對(duì)象的響應(yīng)消息。
4.HTTP服務(wù)器告知TCP關(guān)閉這個(gè)TCP連接(不過TCP要到客戶收到剛才這個(gè)響應(yīng)消息之后才會(huì)真正終止這個(gè)連接)。
5.HTTP客戶經(jīng)由同一個(gè)套接字接收這個(gè)響應(yīng)消息。TCP連接隨后終止。該消息標(biāo)明所封裝的對(duì)象是一個(gè)HTML文件。客戶從中取出這個(gè)文件，加以分析后發(fā)現(xiàn)其中有10個(gè)JPEG對(duì)象的引用。
6.給每一個(gè)引用到的JPEG對(duì)象重復(fù)步騾1-4。

瀏覽器在接收web頁(yè)面的同時(shí)把它顯示給用戶。不同的瀏覽器可能會(huì)以略有不同的方式解釋(也就是向用戶顯示)同一個(gè)web頁(yè)面。HTTP與客戶如何解釋W(xué)eb頁(yè)面沒有任何關(guān)系，其規(guī)范([RFC 1945]和[RFC 2616I)僅僅定義HTTP客戶程序和服務(wù)器程序之間的通信協(xié)議。

上述步驟之所以稱為使用非持久連接，原因是每次服務(wù)器發(fā)出一個(gè)對(duì)象后，相應(yīng)的TCP連接就被關(guān)閉，也就是說每個(gè)連接都沒有持續(xù)到可用于傳送其他對(duì)象。每個(gè)TCP連接只用于傳輸一個(gè)請(qǐng)求消息和一個(gè)響應(yīng)消息。就上述例子而言，用戶每請(qǐng)求一次那個(gè)web頁(yè)面，就產(chǎn)生11個(gè)TCP連接。

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

繼續(xù)介紹之前，先估算一下從客戶請(qǐng)求基本HTML文件到它收到該文件所經(jīng)歷的時(shí)間。為此我們定義往返時(shí)間(round trip time，簡(jiǎn)稱RTT)，它是一個(gè)小分組從客戶主機(jī)游動(dòng)到服務(wù)器主機(jī)再返回客戶主機(jī)所花的時(shí)間。RTT包括分組傳播延遲、在中間路由器和交換機(jī)上的分組排隊(duì)延遲以及分組處理延遲。下面考慮用戶點(diǎn)擊某個(gè)超鏈接時(shí)會(huì)發(fā)生什么。用戶的點(diǎn)擊導(dǎo)致瀏覽器發(fā)起建立一個(gè)與Web服務(wù)器的TCP連接；這里涉及—次“三次握手”過程——首先是客戶向服務(wù)器發(fā)送一個(gè)小的冗余消息，接著是服務(wù)器向客戶確認(rèn)并響應(yīng)以一個(gè)小的TCP消息，最后是客戶向服務(wù)器回確認(rèn)。三次握手過程的前兩次結(jié)束時(shí)，流逝的時(shí)間為1個(gè)RTT。此時(shí)客戶把HTTP請(qǐng)求消息發(fā)送到TCP連接中，客戶接著把三次握手過程最后一次中的確認(rèn)捎帶在包含這個(gè)消息的數(shù)據(jù)分節(jié)中發(fā)送以去。服務(wù)器收到來自TCP連接的請(qǐng)求消息后，把相應(yīng)的HTML文件發(fā)送到TCP連接中，服務(wù)器接著把對(duì)早先收到的客戶請(qǐng)求的確認(rèn)捎帶在包含該HTML文件的數(shù)據(jù)分節(jié)中發(fā)送出去。這個(gè)HTTP請(qǐng)求順應(yīng)交互也花去1個(gè)RTT時(shí)間。因此，總的響應(yīng)時(shí)間粗略地算是2個(gè)RTT加上服務(wù)器發(fā)送這個(gè)HTMI文件的時(shí)間。

持久連接

非持久連接有些缺點(diǎn)。首先，客戶得為每個(gè)待請(qǐng)求的對(duì)象建立并維護(hù)一個(gè)新的連接。對(duì)于每個(gè)這樣的連接，TCP得在客戶端和服務(wù)器端分配TCP緩沖區(qū)，并維持TCP變量。對(duì)于有可能同時(shí)為來自數(shù)百個(gè)不同客戶的請(qǐng)求提供服務(wù)的web服務(wù)器來說，這會(huì)嚴(yán)重增加其負(fù)擔(dān)。其次，如前所述，每個(gè)對(duì)象都有2個(gè) RTT的響應(yīng)延長(zhǎng)——一個(gè)RTT用于建立TCP連接，另—個(gè)RTT用于請(qǐng)求和接收對(duì)象。最后，每個(gè)對(duì)象都遭受TCP緩啟動(dòng)，因?yàn)槊總€(gè)TCP連接都起始于緩啟動(dòng)階段。不過并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動(dòng)延遲的影響。

在持久連接情況下，服務(wù)器在發(fā)出響應(yīng)后讓TCP連接繼續(xù)打開著。同一對(duì)客戶/服務(wù)器之間的后續(xù)請(qǐng)求和響應(yīng)可以通過這個(gè)連接發(fā)送。整個(gè)Web頁(yè)面 (上例中為包含一個(gè)基本HTMLL文件和10個(gè)圖像的頁(yè)面)自不用說可以通過單個(gè)持久TCP連接發(fā)送：甚至存放在同一個(gè)服務(wù)器中的多個(gè)web頁(yè)面也可以通過單個(gè)持久TCP連接發(fā)送。通常，HTTP服務(wù)器在某個(gè)連接閑置一段特定時(shí)間后關(guān)閉它，而這段時(shí)間通常是可以配置的。持久連接分為不帶流水線 (without pipelining)和帶流水線(with pipelining)兩個(gè)版本。如果是不帶流水線的版本，那么客戶只在收到前一個(gè)請(qǐng)求的響應(yīng)后才發(fā)出新的請(qǐng)求。這種情況下，web頁(yè)面所引用的每個(gè)對(duì)象 (上例中的10個(gè)圖像)都經(jīng)歷1個(gè)RTT的延遲，用于請(qǐng)求和接收該對(duì)象。與非持久連接2個(gè)RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進(jìn)一步降低響應(yīng)延遲。不帶流水線版本的另一個(gè)缺點(diǎn)是，服務(wù)器送出一個(gè)對(duì)象后開始等待下一個(gè)請(qǐng)求，而這個(gè)新請(qǐng)求卻不能馬上到達(dá)。這段時(shí)間服務(wù)器資源便閑置了。

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

HTTP消息格式：請(qǐng)求消息和相應(yīng)消息

HTTP規(guī)范1.0[RPcl945]和1.1[RFC 2616]定義了HTTP消息的格式。HTTP消息分為請(qǐng)求消息和響應(yīng)稍息兩類。下面我們分別進(jìn)行介紹。

HTTP請(qǐng)求消息

下面是一個(gè)典型的HTTP請(qǐng)求消息:

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

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

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

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

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

HEAD
（Head方法）要求響應(yīng)與相應(yīng)的GET請(qǐng)求的響應(yīng)一樣，但是沒有響應(yīng)體（response body）。這用來獲得響應(yīng)頭（response header）中的元數(shù)據(jù)信息（meta-infomation）有（很大）幫助，（因?yàn)?#xff09;它不需要傳輸所有的內(nèi)容。

GET
（Get方法用來）請(qǐng)求指定的資源。它是目前網(wǎng)上最常用的方法。它不應(yīng)該用于一些會(huì)造成副作用的操作中
（在網(wǎng)絡(luò)應(yīng)用中用它來提交動(dòng)作是一種常見的錯(cuò)誤用法）。（細(xì)節(jié)請(qǐng)）參考后面的“安全方法”（這一節(jié)）。

POST
（POST方法用來）向指定的資源提交需要處理的數(shù)據(jù)。這些數(shù)據(jù)寫在請(qǐng)求的內(nèi)容里。（POST請(qǐng)求）可以導(dǎo)致新資源的產(chǎn)生和已有資源的更新。

PUT
上傳指定資源

DELETE
刪除指定資源

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

OPTIONS
返回服務(wù)器（在指定URL上）支持的HTTP方法。通過請(qǐng)求“*”而不是指定的資源，這個(gè)方法可以用來檢查網(wǎng)絡(luò)服務(wù)器的功能。

CONNECT
將請(qǐng)求的連接轉(zhuǎn)換成透明的TCP/IP通道，通常用來簡(jiǎn)化通過非加密的HTTP代理的SSL-加密通訊（HTTPS）。
HTTP服務(wù)器至少應(yīng)該實(shí)現(xiàn)Get和Head方法，可能的話，也實(shí)現(xiàn)OPTIONS方法。

HTTP響應(yīng)消息

下面是一個(gè)典型的HTTP響應(yīng)消息:

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
(數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù)…………)

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

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

注意，如果服務(wù)器收到一個(gè)HTTP/1.0的請(qǐng)求，那么它即使是一個(gè)HTTP/1.1服務(wù)器，也不會(huì)使用持久連接。相反，這樣的HTTP/1.1服務(wù)器會(huì)在發(fā)出所請(qǐng)求的對(duì)象后關(guān)閉TCP連接。這么做是必要的，因?yàn)镠TTP/1.0客戶期待服務(wù)器馬上關(guān)閉連接。

響應(yīng)消息中的狀態(tài)碼和原因短語(yǔ)指示相應(yīng)請(qǐng)求的處理結(jié)果。

●200 0K：請(qǐng)求成功，所請(qǐng)求信息在響應(yīng)消息中返回。
●301 Moved Permanently：所請(qǐng)求的對(duì)象己永久性遷移；新的URL在本響應(yīng)消息的Location:頭部指出。客戶軟件會(huì)自動(dòng)請(qǐng)求這個(gè)新的URL。
●400 Bad Request;：表示服務(wù)器無(wú)法理解相應(yīng)請(qǐng)求的普通錯(cuò)誤的狀態(tài)碼
●404 Not Found：服務(wù)器上不存在所請(qǐng)求的文檔。
●HTTP Version Not Support：服務(wù)器不支持所請(qǐng)求的HTTP協(xié)議版本。

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

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

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

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

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

本文討論過的和即將討論的用于HTTP請(qǐng)求消息和響應(yīng)消息中的頭部?jī)H僅是很小的一部分，HTTP規(guī)范中定義了更多可用的頭部，可以查閱相關(guān)的RFC文檔進(jìn)行更詳細(xì)的了。

用戶—服務(wù)器交互

身份認(rèn)證和cookie

我們已經(jīng)知道HTTP服務(wù)器是無(wú)狀態(tài)的。這樣的處理可以簡(jiǎn)化服務(wù)器程序的設(shè)計(jì)，以便開發(fā)出更高性能的Web服務(wù)器軟件。然而，一個(gè)Web站點(diǎn)往往有標(biāo)識(shí)其用戶的需求，因?yàn)槠鋡eb服務(wù)器可能希望限制用戶的訪問，也可能想要根據(jù)用戶的身份來提供內(nèi)容。HTTP提供了兩種幫助服務(wù)器標(biāo)識(shí)用戶的機(jī)制：身份認(rèn)證和cookie。

身份認(rèn)證許多web站點(diǎn)要求用戶提供一個(gè)用戶名—口令對(duì)才能訪問存放在其服務(wù)器中的文檔。這種要求稱為身份認(rèn)證(authentication)。HTTP提供特殊的狀態(tài)碼和頭部來幫助Web站點(diǎn)執(zhí)行身份認(rèn)證。我們通過查看一個(gè)例子來領(lǐng)會(huì)這些特殊的狀態(tài)碼和頭部如何工作。假設(shè)有—個(gè)客戶在請(qǐng)求來自某個(gè)服務(wù)器的一個(gè)對(duì)象，而該服務(wù)器要求用戶授予權(quán)限。

客戶首先發(fā)送一個(gè)不合特殊頭部的普通請(qǐng)求消息。服務(wù)器以空的附屬體和一個(gè)“401Authorization Required”狀態(tài)碼作為響應(yīng)。服務(wù)器還在這個(gè)響應(yīng)消息中包含“個(gè)WWW-Authenticate:頭部，說明具體如何執(zhí)行身份認(rèn)證。這個(gè)頭部的典型值是指出用戶需要提供一個(gè)用戶名—口令對(duì)。

客戶收到這個(gè)響應(yīng)消息后提示用戶輸入用戶名和口令，然后重新發(fā)送請(qǐng)求消息。這一回客戶在請(qǐng)求消息中包含了一個(gè)Authorization:頭部，其中包含有用戶輸入的用戶名和口令。

取得第一個(gè)對(duì)象后，客戶在同為請(qǐng)求該服務(wù)器上對(duì)象的后續(xù)請(qǐng)求中繼續(xù)發(fā)送這個(gè)用戶名—口令對(duì)。這個(gè)做法一般將持續(xù)到用戶關(guān)閉瀏覽器為止。在瀏覽器未被關(guān)閉之前，這個(gè)用戶名—口令對(duì)是高速緩存著的，因此瀏覽器不會(huì)每請(qǐng)求一個(gè)對(duì)象就提示用戶輸入一次用戶名和口令。通過上述方式，要求用戶授權(quán)的Web站點(diǎn)就能標(biāo)識(shí)出每個(gè)請(qǐng)求的用戶了。

我們需要知道，HTTP執(zhí)行的是一種相當(dāng)脆弱的身份認(rèn)證方式，不難攻破。現(xiàn)代有很多更為安全的認(rèn)證方式，我們會(huì)在以后介紹。

cookie是一種可讓W(xué)eb站點(diǎn)用來跟蹤用戶的候選機(jī)制，定義在RFC 2109中。有些Web站點(diǎn)使用cookie，其他Web站點(diǎn)則不用。下面查看一個(gè)例子。假設(shè)一個(gè)客戶首次聯(lián)系一個(gè)使用cookie的web站點(diǎn)。服務(wù)器會(huì)在其響應(yīng)中包含一個(gè)Set—Cookie:頭部。該頭部的值可以是一個(gè)由Web服務(wù)器產(chǎn)生的客戶標(biāo)識(shí)數(shù).例如:

Set-Cookie:1678453

客戶收到這個(gè)響應(yīng)消息，看到其中的Set-Cookie:頭部和標(biāo)識(shí)數(shù)后，會(huì)在存放在客戶主機(jī)中的某個(gè)特殊的cookie文件中添加一行。這一行一般包含服務(wù)器主機(jī)的主機(jī)名和這個(gè)與用戶關(guān)聯(lián)的標(biāo)識(shí)數(shù)。在一段時(shí)間(如一個(gè)星期)之后請(qǐng)求同一個(gè)服務(wù)器時(shí)，由同一個(gè)用戶啟動(dòng)的新客戶會(huì)在請(qǐng)求消息中包含一個(gè)cookie頭部，其值為早先由該服務(wù)器產(chǎn)生的標(biāo)識(shí)數(shù)，例如:Cookie:1678453

在這種方式中，服務(wù)器并不知道提出請(qǐng)求的用戶的用戶名，但是它確實(shí)知道該用戶與一個(gè)星期前提出請(qǐng)求的用戶是同一個(gè)。

Web服務(wù)器有多個(gè)使用coohe的目的:

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

需指出的是，cookie不適用于會(huì)從不同主機(jī)訪問同一web站點(diǎn)的游動(dòng)用戶。這種情況下，該web站點(diǎn)會(huì)把同一個(gè)用戶在不同主機(jī)上的使用看成是由新的用戶執(zhí)行的。

帶條件的GET

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

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

我們通過查看一個(gè)例子來說明帶條件的GET如何工作，向服務(wù)器請(qǐng)求一個(gè)尚未高速緩存的對(duì)象:

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

接著，web服務(wù)器把帶這個(gè)對(duì)象的一個(gè)響應(yīng)消息發(fā)送給客戶:

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
(數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù) 數(shù)據(jù)……)

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

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:頭部的值就等于一個(gè)星期前由服務(wù)器發(fā)送的Last-Modified:頭部的值。這個(gè)帶條件的 GET消息告知服務(wù)器，只有在該對(duì)象自所指定的時(shí)間以來被修改了的前提下才發(fā)送它。假設(shè)該對(duì)象在這段時(shí)間內(nèi)未曾被修改過，那么服務(wù)器將發(fā)送一個(gè)附屬體為空的響應(yīng)消息給客戶；

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

我們看到，web服務(wù)器仍然發(fā)送—個(gè)響應(yīng)消息作為帶條件的GET消息的響應(yīng)，不過其中不包含所請(qǐng)求的對(duì)象。包含該對(duì)象只會(huì)浪費(fèi)帶寬，并延長(zhǎng)用戶可感知的響應(yīng)時(shí)間，特別是在該對(duì)象很大的時(shí)候。注意，這個(gè)響應(yīng)消息的狀態(tài)為“304 Not Modified”，它告知客戶可以放心使用所請(qǐng)求對(duì)象的高速緩存版本。

以上內(nèi)容是作者在互聯(lián)網(wǎng)上搜索整理所得...?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。