眾所周知，Internet的基本協(xié)議是TCP/IP協(xié)議，目前廣泛采用的FTP、Archie Gopher等是建立在TCP/IP協(xié)議之上的應(yīng)用層協(xié)議，不同的協(xié)議對(duì)應(yīng)著不同的應(yīng)用。?
?
WWW 服務(wù)器使用的主要協(xié)議是HTTP協(xié)議，即超文體傳輸協(xié)議。由于HTTP協(xié)議支持的服務(wù)不限于WWW，還可以是其它服務(wù)，因而HTTP協(xié)議允許用 戶在統(tǒng)一的界面下，采用不同的協(xié)議訪問不同的服務(wù)，如FTP、Archie、SMTP、NNTP等。另外，HTTP協(xié)議還可用于名字服務(wù)器和分布式對(duì)象管 理。?
?
HTTP的早期版本為HTTP/0.9，它適用于各種數(shù)據(jù)信息的簡(jiǎn)潔快速協(xié)議，但是其遠(yuǎn)不能滿足日益發(fā)展各種應(yīng)用的需要。但 HTTP/0.9作為HTTP 協(xié)議具有典型的無狀態(tài)性：每個(gè)事務(wù)都是獨(dú)立進(jìn)行處理的，當(dāng)一個(gè)事務(wù)開始就在客戶與服務(wù)器之間建立一個(gè)連接，當(dāng)事務(wù)結(jié)束時(shí)就釋放這個(gè)連接。HTTP/0.9 包含Simple-Request&Simple-Responsed的報(bào)文結(jié)構(gòu)。但是客戶無法使用內(nèi)容協(xié)商，所以服務(wù)器也無法返回實(shí)體的媒體類 型。??
?
1982年，Tim Berners-Lee提出了HTTP/1.0，在此后的不斷豐富和發(fā)展中，HTTP/1.0成為最重要的面向事務(wù)的應(yīng)用層協(xié)議。該協(xié)議對(duì)每一次請(qǐng)求/響 應(yīng)，建立并拆除一次連接。其特點(diǎn)是簡(jiǎn)單、易于管理，所以它符合了大家的需要，得到了廣泛的應(yīng)用。其缺點(diǎn)是仍會(huì)發(fā)生下列問題：對(duì)用戶請(qǐng)求響應(yīng)慢、網(wǎng)絡(luò)擁塞嚴(yán) 重、安全性等。??
?
1997年形成的HTTP/1.1，也就是現(xiàn)在普遍使用的協(xié)議，在持續(xù)連接操作機(jī)制中實(shí)現(xiàn)流水方式，即客戶端需要 對(duì)同一服務(wù)器發(fā)出多個(gè)請(qǐng)求時(shí)，其實(shí)現(xiàn) 在多數(shù)的網(wǎng)頁都是有多部分組成（比如多張圖片），可用流水線方式加快速度，流水機(jī)制就是指連續(xù)發(fā)出多個(gè)請(qǐng)求并等到這些請(qǐng)求發(fā)送完畢，再等待響應(yīng)。這樣就大 大節(jié)省了單獨(dú)請(qǐng)求對(duì)響應(yīng)的等待時(shí)間，使我們得到更快速的瀏覽。??
?
另外，HTTP/1.1服務(wù)器端處理請(qǐng)求時(shí)按照收到的順序進(jìn)行,這就保證了傳輸?shù)恼_性。當(dāng)然，服務(wù)器端在發(fā)生連接中斷時(shí)，會(huì)自動(dòng)的重傳請(qǐng)求，保證數(shù)據(jù)的完整性。??
?
HTTP/1.1 還提供了身份認(rèn)證、狀態(tài)管理和Cache緩存等機(jī)制。這里，我想特別提一下關(guān)于HTTP/1.1中的Cache緩存機(jī)制對(duì)HTTP /1.0的不足之處的改進(jìn)，它嚴(yán)格全面，既可以減少時(shí)間延遲、又節(jié)省了帶寬。HTTP/1.1采用了內(nèi)容協(xié)商機(jī)制，選擇最合適的用戶的內(nèi)容表現(xiàn)形式。??
?
2.1　HTTP協(xié)議簡(jiǎn)介?
?
HTTP 是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡(jiǎn)捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過幾年的使用與發(fā)展，得到 不斷地完善和擴(kuò)展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進(jìn)行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經(jīng)提出。?
?
HTTP協(xié)議的主要特點(diǎn)可概括如下：?
?
1.支持客戶/服務(wù)器模式。?
2.簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。?
由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。?
3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。?
4.無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。?
5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。?
?
2.2　HTTP協(xié)議的幾個(gè)重要概念?
?
1.連接(Connection)：一個(gè)傳輸層的實(shí)際環(huán)流，它是建立在兩個(gè)相互通訊的應(yīng)用程序之間。?
2.消息(Message)：HTTP通訊的基本單位，包括一個(gè)結(jié)構(gòu)化的八元組序列并通過連接傳輸。?
3.請(qǐng)求(Request)：一個(gè)從客戶端到服務(wù)器的請(qǐng)求信息包括應(yīng)用于資源的方法、資源的標(biāo)識(shí)符和協(xié)議的版本號(hào)?
4.響應(yīng)(Response)：一個(gè)從服務(wù)器返回的信息包括HTTP協(xié)議的版本號(hào)、請(qǐng)求的狀態(tài)(例如"成功"或"沒找到")和文檔的MIME類型。?
5.資源(Resource)：由URI標(biāo)識(shí)的網(wǎng)絡(luò)數(shù)據(jù)對(duì)象或服務(wù)。?
6.實(shí)體(Entity)：數(shù)據(jù)資源或來自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個(gè)請(qǐng)求或響應(yīng)信息中。一個(gè)實(shí)體包括實(shí)體頭信息和實(shí)體的本身內(nèi)容。?
7.客戶機(jī)(Client)：一個(gè)為發(fā)送請(qǐng)求目的而建立連接的應(yīng)用程序。?
8.用戶代理(User agent)：初始化一個(gè)請(qǐng)求的客戶機(jī)。它們是瀏覽器、編輯器或其它用戶工具。?
9.服務(wù)器(Server)：一個(gè)接受連接并對(duì)請(qǐng)求返回信息的應(yīng)用程序。?
10.源服務(wù)器(Origin server)：是一個(gè)給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。?
11.代理(Proxy)：一個(gè)中間程序，它可以充當(dāng)一個(gè)服務(wù)器，也可以充當(dāng)一個(gè)客戶機(jī)，為其它客戶機(jī)建立請(qǐng)求。請(qǐng)求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務(wù)器中。一個(gè)代理在發(fā)送請(qǐng)求信息之前，必須解釋并且如果可能重寫它。?
代理經(jīng)常作為通過防火墻的客戶機(jī)端的門戶，代理還可以作為一個(gè)幫助應(yīng)用來通過協(xié)議處理沒有被用戶代理完成的請(qǐng)求。?
12.網(wǎng)關(guān)(Gateway)：一個(gè)作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請(qǐng)求就好象對(duì)被請(qǐng)求的資源來說它就是源服務(wù)器；發(fā)出請(qǐng)求的客戶機(jī)并沒有意識(shí)到它在同網(wǎng)關(guān)打交道。?
網(wǎng)關(guān)經(jīng)常作為通過防火墻的服務(wù)器端的門戶，網(wǎng)關(guān)還可以作為一個(gè)協(xié)議翻譯器以便存取那些存儲(chǔ)在非HTTP系統(tǒng)中的資源。?
13. 通道(Tunnel)：是作為兩個(gè)連接中繼的中介程序。一旦激活，通道便被認(rèn)為不屬于HTTP通訊，盡管通道可能是被一個(gè)HTTP請(qǐng)求初始化 的。當(dāng)被中繼的連接兩端關(guān)閉時(shí)，通道便消失。當(dāng)一個(gè)門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時(shí)通道被經(jīng)常使 用。?
14.緩存(Cache)：反應(yīng)信息的局域存儲(chǔ)。?
?
2.3　HTTP協(xié)議的運(yùn)作方式?
?
HTTP協(xié)議是 基于請(qǐng)求／響應(yīng)范式的。一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為，統(tǒng)一資源標(biāo)識(shí)符、協(xié)議版本號(hào)，后邊是 MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤 的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。?
?
許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請(qǐng)?jiān)谠捶?wù)器上資源的請(qǐng)求。最簡(jiǎn)單的情況可能是在用戶代理(UA)和源服務(wù)器(O)之間通過一個(gè)單獨(dú)的連接來完成(見圖2-1)。?
?
圖2-1?
?
當(dāng) 一個(gè)或多個(gè)中介出現(xiàn)在請(qǐng)求／響應(yīng)鏈中時(shí)，情況就變得復(fù)雜一些。中介由三種：代理(Proxy)、網(wǎng)關(guān)(Gateway)和通道(Tunnel)。一 個(gè)代理根據(jù)URI(Uniform Resource Identifier)的絕對(duì)格式來接受請(qǐng)求，重寫全部或部分消息，通過URI的標(biāo)識(shí)把已格式化過的請(qǐng)求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個(gè)接收代理，作為一些其它 服務(wù)器的上層，并且如果必須的話，可以把請(qǐng)求翻譯給下層的服務(wù)器協(xié)議。一個(gè)通道作為不改變消息的兩個(gè)連接之間的中繼點(diǎn)。當(dāng)通訊需要通過一個(gè)中介(例如：防 火墻等)或者是中介不能識(shí)別消息的內(nèi)容時(shí)，通道經(jīng)常被使用。??
?
圖2-2?
?
上面的圖2-2表明了在用戶代理 (UA)和源服務(wù)器(O)之間有三個(gè)中介(A,B和C)。一個(gè)通過整個(gè)鏈的請(qǐng)求或響應(yīng)消息必須經(jīng)過四個(gè)連接段。這個(gè)區(qū) 別是重要的，因?yàn)橐恍〩TTP通訊選擇可能應(yīng)用于最近的連接、沒有通道的鄰居，應(yīng)用于鏈的終點(diǎn)或應(yīng)用于沿鏈的所有連接。盡管圖2-2是線性的，每個(gè)參與者 都可能從事多重的、并發(fā)的通訊。例如，B可能從許多客戶機(jī)接收請(qǐng)求而不通過A，并且／或者不通過C把請(qǐng)求送到A，在同時(shí)它還可能處理A的請(qǐng)求。?
?
任何針對(duì)不作為通道的匯聚可能為處理請(qǐng)求啟用一個(gè)內(nèi)部緩存。緩存的效果是請(qǐng)求／響應(yīng)鏈被縮短，條件是沿鏈的參與者之一具有一個(gè)緩存的響應(yīng)作用于那個(gè)請(qǐng)求。下圖說明結(jié)果鏈，其條件是針對(duì)一個(gè)未被UA或A加緩存的請(qǐng)求，B有一個(gè)經(jīng)過C來自O(shè)的一個(gè)前期響應(yīng)的緩存拷貝。?
?
圖2-3?
?
在Internet上，HTTP通訊通常發(fā)生在TCP/IP連接之上。缺省端口是TCP 80，但其它的端口也是可用的。但這并不預(yù)示著HTTP協(xié)議在Internet或其它網(wǎng)絡(luò)的其它協(xié)議之上才能完成。HTTP只預(yù)示著一個(gè)可靠的傳輸。?
?
以上簡(jiǎn)要介紹了HTTP協(xié)議的宏觀運(yùn)作方式，下面介紹一下HTTP協(xié)議的內(nèi)部操作過程。?
?
首先，簡(jiǎn)單介紹基于HTTP協(xié)議的客戶/服務(wù)器模式的信息交換過程，如圖2-4所示，它分四個(gè)過程，建立連接、發(fā)送請(qǐng)求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。?
?
圖2-4?
?
在WWW中，"客戶"與"服務(wù)器"是一個(gè)相對(duì)的概念，只存在于一個(gè)特定的連接期間，即在某個(gè)連接中的客戶在另一個(gè)連接中可能作為服務(wù)器。WWW服務(wù)器運(yùn)行時(shí)，一直在TCP80端口(WWW的缺省端口)監(jiān)聽，等待連接的出現(xiàn)。?
?
下面，討論HTTP協(xié)議下客戶/服務(wù)器模式中信息交換的實(shí)現(xiàn)。 　　?
?
1.建立連接??
連接的建立是通過申請(qǐng)?zhí)捉幼?Socket)實(shí)現(xiàn)的。客戶打開一個(gè)套接字并把它約束在一個(gè)端口上，如果成功，就相當(dāng)于建立了一個(gè)虛擬文件。以后就可以在該虛擬文件上寫數(shù)據(jù)并通過網(wǎng)絡(luò)向外傳送。?
?
2.發(fā)送請(qǐng)求?
打開一個(gè)連接后，客戶機(jī)把請(qǐng)求消息送到服務(wù)器的停留端口上，完成提出請(qǐng)求動(dòng)作。?
HTTP/1.0　　請(qǐng)求消息的格式為：?
請(qǐng)求消息=請(qǐng)求行(通用信息|請(qǐng)求頭|實(shí)體頭) CRLF[實(shí)體內(nèi)容]?
請(qǐng)求行=方法　請(qǐng)求URL　HTTP版本號(hào)　CRLF?
方法=GET|HEAD|POST|擴(kuò)展方法?
URL=協(xié)議名稱+宿主名+目錄與文件名?
請(qǐng)求行中的方法描述指定資源中應(yīng)該執(zhí)行的動(dòng)作，常用的方法有GET、HEAD和POST。不同的請(qǐng)求對(duì)象對(duì)應(yīng)GET的結(jié)果是不同的，對(duì)應(yīng)關(guān)系如下：?
對(duì)象　　　　　　GET的結(jié)果?
文件　　　　　　文件的內(nèi)容?
程序　　　　　　該程序的執(zhí)行結(jié)果?
數(shù)據(jù)庫查詢　　　查詢結(jié)果?
HEAD--要求服務(wù)器查找某對(duì)象的元信息，而不是對(duì)象本身。?
POST--從客戶機(jī)向服務(wù)器傳送數(shù)據(jù)，在要求服務(wù)器和CGI做進(jìn)一步處理時(shí)會(huì)用到POST方法。POST主要用于發(fā)送HTML文本中FORM的內(nèi)容，讓CGI程序處理。?
一個(gè)請(qǐng)求的例子為：?
GET?http://networking.zju.edu.cn/zju/index.htm?HTTP/1.0?
頭信息又稱為元信息，即信息的信息，利用元信息可以實(shí)現(xiàn)有條件的請(qǐng)求或應(yīng)答 。?
請(qǐng)求頭--告訴服務(wù)器怎樣解釋本次請(qǐng)求，主要包括用戶可以接受的數(shù)據(jù)類型、壓縮方法和語言等。?
實(shí)體頭--實(shí)體信息類型、長(zhǎng)度、壓縮方法、最后一次修改時(shí)間、數(shù)據(jù)有效期等。?
實(shí)體--請(qǐng)求或應(yīng)答對(duì)象本身。?
?
3.發(fā)送響應(yīng)?
服務(wù)器在處理完客戶的請(qǐng)求之后，要向客戶機(jī)發(fā)送響應(yīng)消息。?
HTTP/1.0的響應(yīng)消息格式如下：?
響應(yīng)消息=狀態(tài)行(通用信息頭|響應(yīng)頭|實(shí)體頭)　CRLF　〔實(shí)體內(nèi)容〕?
狀 態(tài) 行=HTTP版本號(hào)　狀態(tài)碼　原因敘述?
狀態(tài)碼表示響應(yīng)類型?
1××　　保留?
2××　　表示請(qǐng)求成功地接收?
3××　　為完成請(qǐng)求客戶需進(jìn)一步細(xì)化請(qǐng)求?
4××　　客戶錯(cuò)誤?
5××　　服務(wù)器錯(cuò)誤??
響應(yīng)頭的信息包括：服務(wù)程序名，通知客戶請(qǐng)求的URL需要認(rèn)證，請(qǐng)求的資源何時(shí)能使用。?
?
4.關(guān)閉連接?
客戶和服務(wù)器雙方都可以通過關(guān)閉套接字來結(jié)束TCP/IP對(duì)話?
?
二．http協(xié)議請(qǐng)求頭格式分析?
?
http協(xié)議的請(qǐng)求頭分為10個(gè)部分。?
?
1.From:?
以internet郵件的形式，這一字段給出了正在請(qǐng)求的用戶的名字。這一字段也許被用來登陸和一種存取保護(hù)的不安全形式。這一字段的解釋是代表被給定用戶的要求正在被執(zhí)行，這個(gè)用戶接受被執(zhí)行方法的回應(yīng)。?
這一字段里的因特網(wǎng)郵件地址并非一定要對(duì)發(fā)出請(qǐng)求的主機(jī)回應(yīng).例如，當(dāng)一個(gè)請(qǐng)求正通過一個(gè)網(wǎng)關(guān)時(shí)，開始的發(fā)布者的地址應(yīng)該被使用。?
假如能的話，郵件地址應(yīng)該時(shí)一個(gè)有效的郵件地址而不管它實(shí)際上是否是一個(gè)internet郵件地址。?
?
2.Accept:?
這一字段包含了一個(gè)分隔的請(qǐng)求方案列表，它將在這個(gè)請(qǐng)求的回應(yīng)中被接受。這一字段可能會(huì)根據(jù)RCFC822被包裝成幾行，并且這個(gè)字段不僅僅一次的發(fā)生也是被接受的，好像所有的入口已經(jīng)在一個(gè)域種了。列表中每個(gè)入口的模式如下：?
<field> = ? Accept: <entry> *[ , <entry> ]?
<entry> = ? <content type> *[ ; <param> ]?
<param> = ? <attr> = <float>?
<attr> ? = ? q / mxs / mxb?
<float> = ? <ANSI-C floating point text represntation>?
注意在上述語法中分號(hào)的優(yōu)先級(jí)高于逗號(hào)，這是為了符合多用途的忘記郵件擴(kuò)充協(xié)議。?
記入沒有Accept字段出現(xiàn)，那么假定無格式正文和html正文被接受。?
Example?
Accept: text/plain, text/html?
Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c?
為 了節(jié)省時(shí)間，并且也允許客戶接受他們可能不會(huì)意識(shí)到的content type一個(gè)星號(hào)也許被使用在下面的地方，either the second half of the content-type value, or both halves。這僅僅被應(yīng)用于Accept，而且不是對(duì)于content-type field of course的。?
Example?
Accept: *.*, q=0.1?
Accept: audio/*, q=0.2?
Accept: audio/basic q=1?
上面的例子可以這樣解釋：假如你有基本音頻，那么傳送它，否則傳送給我一些其他的聲音，或者不能那樣作，那么僅僅給我你所得到的。?
Type parameters?
? 在（content type）中參數(shù)對(duì)于描述決議，顏色深度等等是特別重要的。他們將允許一個(gè)客戶來在Accept字段中指定它的設(shè)備的決議。這也許允許server在傳輸 時(shí)通過減少一個(gè)圖片的resultion來大大的節(jié)約。并且使一個(gè)更適合的用戶時(shí)間的黑白圖象被選中而不是給客戶一個(gè)彩色圖片來轉(zhuǎn)換成單色的。?
These parameters are to be specified when types are registered.. @@ TBS.Sugestions include the following. Please feed back any references to existing improved abbreviations for these:?
下面這些參數(shù)是當(dāng)類型被注冊(cè)時(shí)而被具體詳細(xì)說明的。?
? Dpi?
? Dots per inch: pixels per inch [cm?!]??
? pxmax??
? Maximum width in pixels (image or video)??
? pymax??
? Maximum height in pixels??
? bits??
? Bits per sample (sound) or pixels (graphics)??
? mchrome??
? Grayscale or black and white (no value)??
? sps??
? Samples (sound) or frames (video) per second??
? Length??
? Total size of object in bytes [bits?]??
?
3.Accept-Encoding:?
和Accept一樣，但是僅列出了在響應(yīng)中是可接受的Content-Encoding types?
<field> = ? Accept-Encoding: <entry> *[ , <entry> ]?
<entry> = ? <content transfer encoding> *[ , <param> ]?
Example：?
Accept-Encoding: x-compress; x-zip?
?
4。Accept-Language:?
和Accept一樣但是列出了在響應(yīng)中更好的Language values。在一個(gè)未詳細(xì)說明的語言中一個(gè)響應(yīng)不是非法的。?
?
5．User-Agent：?
假如存在的話，這一行給出了被原始用戶使用的軟件程序。這是為了統(tǒng)計(jì)和protocol violations的追蹤而給出的。第一個(gè)白色空格劃定了單詞必須是軟件產(chǎn)品名有一個(gè)可選的斜線和版本說明。其他形成了用戶代理的部分產(chǎn)品也許被作為分開的單詞被安排。?
<field> ? = ? User-Agent: <product>+?
<product> = ? <word> [/<version>]?
<version> = ? <word>?
Example:?
User-Agent: LII-Cello/1.0 libwww/2.5?
?
6．Referer:?
這個(gè)可選的header field允許客戶詳細(xì)說明，為了server的好處，文檔的地址或者文檔中的元素，URI通過文檔的地址或者文檔中的元素在請(qǐng)求中被獲得。?
這允許一個(gè)服務(wù)器來產(chǎn)生向后對(duì)文檔的鏈接，它允許壞鏈接為了維護(hù)而被跟蹤。?
假如一個(gè)部分的URI被給出那么它應(yīng)該被解析到相應(yīng)的請(qǐng)求對(duì)象的URI。?
Example:?
Referer:?http://www.w3.org/hypertext/DataSources/Overview.html?
?
7．Authorization:?
假如這一行存在的話它包含了授權(quán)信息。格式也是被指定的。這一字段的格式是在可擴(kuò)展的形式。第一個(gè)單詞是一個(gè)使用中的被授權(quán)的系統(tǒng)的規(guī)范。?
Basic?
Specification for current one implemented by AL Sep 1993.?
? PGP/PEM Encryption（pgp/增強(qiáng)的加密電子郵件 密碼術(shù)）?
? People at NCSA are designing a PGP/PEM based protection system.?
? User/Password scheme?
? Authorization: user fred:mypassword?
? 設(shè)計(jì)名是"user"。第二個(gè)單詞是一個(gè)用戶名，有一個(gè)被冒號(hào)分開的可選的密碼，就好像在ftp的URL語法一樣。沒有密碼的話這提供了一個(gè)非常低級(jí)的安全保證，有了密碼，它提供了一個(gè)低級(jí)安全保證作為未定義的FTP,Telnet等等。?
? Koreros?
? Authorization: kerberos kerberos authentications parameters?
? Kerberos的確認(rèn)參數(shù)格式被具體指定。?
?
? 8．ChargeTo:?
? 假如這一行存在地話，它包括了被請(qǐng)求的方法的程序的帳戶信息。格式是TBS?
? （To Be Specified）這個(gè)字段的格式必須是在擴(kuò)展模式的。第一個(gè)單詞以一個(gè)namespaces的說明開始。這和擴(kuò)展URLㄒ搴芟瘛５鼻懊揮衝amespaces被定義。Namespaces見被隨著注冊(cè)確認(rèn)而注冊(cè)。?
? 這行的其余部分的格式是一個(gè)系統(tǒng)有關(guān)的函數(shù)但是它被推薦這包含了一個(gè)被用戶確認(rèn)得本次事務(wù)的最大花費(fèi)和一個(gè)花費(fèi)單元。?
? If-Modified-Since: date?
? 這個(gè)請(qǐng)求頭被隨著get方法使用使之有條件。假如請(qǐng)求文檔直到被定義還沒改變得花那么文檔不會(huì)被發(fā)送，但是會(huì)有一個(gè)Not Modified 304 回應(yīng)。?
? 這個(gè)字段的格式和日期的一樣。?
???
? 9.Pragma:?
? 語法和其它的http中的多值字段一樣，就像Accept字段，名以上是一個(gè)冒號(hào)分開的入口列表對(duì)他來說可選的參數(shù)是被漢歐摯摹??
? Pragma 指示應(yīng)該被服務(wù)器理解，對(duì)它來說是相對(duì)的，例如，一個(gè)代理服務(wù)器當(dāng)前僅僅一個(gè)pragma被定義：no-cache??
? 當(dāng)當(dāng)前的代理不應(yīng)該從緩存返回一個(gè)文檔時(shí)，即使它還沒有被到期，但是它總應(yīng)該從實(shí)際存在地服務(wù)器請(qǐng)求文檔。?
? Pragma應(yīng)該被通過代理實(shí)現(xiàn)，甚至他們也許對(duì)代理本身有意義。當(dāng)請(qǐng)求不得不通過許多代理時(shí)，這在事件中是必須的，而且pragma應(yīng)該隊(duì)所有的他們有效。?
?
以下是用jetcar在亦多下載網(wǎng)絡(luò)吸血鬼的信息?
?
Thu Mar 14 14:36:56 2002 正在連接 202.113.29.120 [IP=202.113.29.120:80]?
//正在連接主機(jī)，解析ip地址?
Thu Mar 14 14:36:57 2002 已連接.?
Thu Mar 14 14:36:57 2002 GET /index.dhtml?op=download&ino=2941&type=file HTTP/1.1 //請(qǐng)求行，表示用get方式取得文件，并且是HTTP1.1版本?
Thu Mar 14 14:36:57 2002 HOST: 202.113.29.120 //主機(jī)名?
Thu Mar 14 14:36:57 2002 ACCEPT: */* ? //accept字段，接受的數(shù)據(jù)類型?
Thu Mar 14 14:36:57 2002 Referer:?http://202.113.29.120//從該網(wǎng)址轉(zhuǎn)發(fā)而來?
Thu Mar 14 14:36:57 2002 User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)//客戶端標(biāo)識(shí)?
Thu Mar 14 14:36:57 2002 Pragma: no-cache //參數(shù)，表示與以前的服務(wù)器兼容?
Thu Mar 14 14:36:57 2002 Cache-Control: no-cache //不使用緩存?
Thu Mar 14 14:36:57 2002 Connection: close //表示非持續(xù)性連接。?
以下為response字段?
Thu Mar 14 14:36:58 2002 HTTP/1.1 302 Found?
服務(wù)器使用HTTP/1.0協(xié)議，狀態(tài)值（Status Code）為200，狀態(tài)為OK，表示文件可以讀取?
Thu Mar 14 14:36:58 2002 Date: Thu, 14 Mar 2002 06:52:16 GMT//現(xiàn)在的時(shí)間，用格林威治時(shí)間表示?
Thu Mar 14 14:36:58 2002 Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1?
//服務(wù)器類型?
Thu Mar 14 14:36:58 2002 X-Powered-By: PHP/4.0.4pl1?
Thu Mar 14 14:36:58 2002 Set-Cookie: PHPSESSID=6cf938f3c6ce551971c787ac8b3c0f5b; path=/?
Thu Mar 14 14:36:58 2002 Expires: Thu, 19 Nov 1981 08:52:00 GMT//請(qǐng)求文檔過期時(shí)間?
Thu Mar 14 14:36:58 2002 Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0?
Thu Mar 14 14:36:58 2002 Pragma: no-cache?
Thu Mar 14 14:36:58 2002 Content-Disposition: inline; filename=netvampire33.zip?
Thu Mar 14 14:36:58 2002 Location:?ftp://202.113.29.120/pub/Dos_Windows/Internet/Client/Download/Net?Vampire/3.3/netvampire33.zip?
Thu Mar 14 14:36:58 2002 Connection: close?
Thu Mar 14 14:36:58 2002 Transfer-Encoding: chunked?
Thu Mar 14 14:36:58 2002 Content-Type: text/html?
?
備注：服務(wù)器返回的各類錯(cuò)誤?
當(dāng)服務(wù)器響應(yīng)時(shí)，其狀態(tài)行的信息為HTTP的版本號(hào)，狀態(tài)碼，及解釋狀態(tài)碼的簡(jiǎn)單說明。現(xiàn)將5類狀態(tài)碼詳細(xì)列出：??
① 客戶方錯(cuò)誤??
100　 繼續(xù)??
101　 交換協(xié)議??
② 成功??
200 　OK??
201 　已創(chuàng)建??
202　 接收??
203　 非認(rèn)證信息??
204　 無內(nèi)容??
205 　重置內(nèi)容??
206　 部分內(nèi)容??
③ 重定向??
300 　多路選擇??
301　 永久轉(zhuǎn)移??
302　 暫時(shí)轉(zhuǎn)移??
303　 參見其它??
304 　未修改（Not Modified）??
305　 使用代理??
④ 客戶方錯(cuò)誤??
400　 錯(cuò)誤請(qǐng)求（Bad Request）??
401 　未認(rèn)證??
402 　需要付費(fèi)??
403　 禁止（Forbidden）??
404　 未找到（Not Found）??
405　 方法不允許??
406　 不接受??
407　 需要代理認(rèn)證??
408　 請(qǐng)求超時(shí)??
409　 沖突??
410 　失敗??
411 　需要長(zhǎng)度??
412　 條件失敗??
413 　請(qǐng)求實(shí)體太大??
414 　請(qǐng)求URI太長(zhǎng)??
415 　不支持媒體類型??
⑤ 服務(wù)器錯(cuò)誤??
500　 服務(wù)器內(nèi)部錯(cuò)誤??
501　 未實(shí)現(xiàn)（Not Implemented）??
502　 網(wǎng)關(guān)失敗??
504 　網(wǎng)關(guān)超時(shí)??

505 　HTTP版本不支持 ?

出處：http://52fhy.cnblogs.com/

總結(jié)

以上是生活随笔為你收集整理的[转]HTTP协议及其请求头分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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