HTTP協定及其請求頭分析

HTTP協定及其請求頭分析

HTTP協定及其請求頭分析 

衆所周知，Internet的基本協定是TCP/IP協定，目前廣泛采用的FTP、Archie Gopher等是建立在TCP/IP協定之上的應用層協定，不同的協定對應着不同的應用。 

WWW伺服器使用的主要協定是HTTP協定，即超文體傳輸協定。由于HTTP協定支援的服務不限于WWW，還可以是其它服務，因而HTTP協定允許用 戶在統一的界面下，采用不同的協定通路不同的服務，如FTP、Archie、SMTP、NNTP等。另外，HTTP協定還可用于名字伺服器和分布式對象管 理。 

HTTP的早期版本為HTTP/0.9，它适用于各種資料資訊的簡潔快速協定，但是其遠不能滿足日益發展各種應用的需要。但HTTP/0.9作為HTTP 協定具有典型的無狀态性：每個事務都是獨立進行處理的，當一個事務開始就在客戶與伺服器之間建立一個連接配接，當事務結束時就釋放這個連接配接。HTTP/0.9 包含Simple-Request&Simple-Responsed的封包結構。但是客戶無法使用内容協商，是以伺服器也無法傳回實體的媒體類 型。  

1982年，Tim Berners-Lee提出了HTTP/1.0，在此後的不斷豐富和發展中，HTTP/1.0成為最重要的面向事務的應用層協定。該協定對每一次請求/響 應，建立并拆除一次連接配接。其特點是簡單、易于管理，是以它符合了大家的需要，得到了廣泛的應用。其缺點是仍會發生下列問題：對使用者請求響應慢、網絡擁塞嚴 重、安全性等。  

1997年形成的HTTP/1.1，也就是現在普遍使用的協定，在持續連接配接操作機制中實作流水方式，即用戶端需要對同一伺服器發出多個請求時，其實作 在多數的網頁都是有多部分組成（比如多張圖檔），可用流水線方式加快速度，流水機制就是指連續發出多個請求并等到這些請求發送完畢，再等待響應。這樣就大 大節省了單獨請求對響應的等待時間，使我們得到更快速的浏覽。  

另外，HTTP/1.1伺服器端處理請求時按照收到的順序進行,這就保證了傳輸的正确性。當然，伺服器端在發生連接配接中斷時，會自動的重傳請求，保證資料的完整性。  

HTTP/1.1還提供了身份認證、狀态管理和Cache緩存等機制。這裡，我想特别提一下關于HTTP/1.1中的Cache緩存機制對HTTP /1.0的不足之處的改進，它嚴格全面，既可以減少時間延遲、又節省了帶寬。HTTP/1.1采用了内容協商機制，選擇最合适的使用者的内容表現形式。  

2.1　HTTP協定簡介 

HTTP是一個屬于應用層的面向對象的協定，由于其簡捷、快速的方式，适用于分布式超媒體資訊系統。它于1990年提出，經過幾年的使用與發展，得到 不斷地完善和擴充。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。 

HTTP協定的主要特點可概括如下： 

1.支援客戶/伺服器模式。 

2.簡單快速：客戶向伺服器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯系的類型不同。 

由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快。 

3.靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以标記。 

4.無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。 

5.無狀态：HTTP協定是無狀态協定。無狀态是指協定對于事務處理沒有記憶能力。缺少狀态意味着如果後續處理需要前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。 

2.2　HTTP協定的幾個重要概念 

1.連接配接(Connection)：一個傳輸層的實際環流，它是建立在兩個互相通訊的應用程式之間。 

2.消息(Message)：HTTP通訊的基本機關，包括一個結構化的八元組序列并通過連接配接傳輸。 

3.請求(Request)：一個從用戶端到伺服器的請求資訊包括應用于資源的方法、資源的辨別符和協定的版本号 

4.響應(Response)：一個從伺服器傳回的資訊包括HTTP協定的版本号、請求的狀态(例如"成功"或"沒找到")和文檔的MIME類型。 

5.資源(Resource)：由URI辨別的網絡資料對象或服務。 

6.實體(Entity)：資料資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應資訊中。一個實體包括實體頭資訊和實體的本身内容。 

7.客戶機(Client)：一個為發送請求目的而建立連接配接的應用程式。 

8.使用者代理(User agent)：初始化一個請求的客戶機。它們是浏覽器、編輯器或其它使用者工具。 

9.伺服器(Server)：一個接受連接配接并對請求傳回資訊的應用程式。 

10.源伺服器(Origin server)：是一個給定資源可以在其上駐留或被建立的伺服器。 

11.代理(Proxy)：一個中間程式，它可以充當一個伺服器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在内部或經過傳遞到其它的伺服器中。一個代理在發送請求資訊之前，必須解釋并且如果可能重寫它。 

代理經常作為通過防火牆的客戶機端的門戶，代理還可以作為一個幫助應用來通過協定處理沒有被使用者代理完成的請求。 

12.網關(Gateway)：一個作為其它伺服器中間媒介的伺服器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源伺服器；送出請求的客戶機并沒有意識到它在同網關打交道。 

網關經常作為通過防火牆的伺服器端的門戶，網關還可以作為一個協定翻譯器以便存取那些存儲在非HTTP系統中的資源。 

13.通道(Tunnel)：是作為兩個連接配接中繼的中介程式。一旦激活，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化 的。當被中繼的連接配接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使 用。 

14.緩存(Cache)：反應資訊的局域存儲。 

2.3　HTTP協定的運作方式 

HTTP協定是基于請求／響應範式的。一個客戶機與伺服器建立連接配接後，發送一個請求給伺服器，請求方式的格式為，統一資源辨別符、協定版本号，後邊是 MIME資訊包括請求修飾符、客戶機資訊和可能的内容。伺服器接到請求後，給予相應的響應資訊，其格式為一個狀态行包括資訊的協定版本号、一個成功或錯誤 的代碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的内容。 

許多HTTP通訊是由一個使用者代理初始化的并且包括一個申請在源伺服器上資源的請求。最簡單的情況可能是在使用者代理(UA)和源伺服器(O)之間通過一個單獨的連接配接來完成(見圖2-1)。 

圖2-1 

當一個或多個中介出現在請求／響應鍊中時，情況就變得複雜一些。中介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)。一 個代理根據URI(Uniform Resource Identifier)的絕對格式來接受請求，重寫全部或部分消息，通過URI的辨別把已格式化過的請求發送到伺服器。網關是一個接收代理，作為一些其它 伺服器的上層，并且如果必須的話，可以把請求翻譯給下層的伺服器協定。一個通道作為不改變消息的兩個連接配接之間的中繼點。當通訊需要通過一個中介(例如：防 火牆等)或者是中介不能識别消息的内容時，通道經常被使用。  

圖2-2 

上面的圖2-2表明了在使用者代理(UA)和源伺服器(O)之間有三個中介(A,B和C)。一個通過整個鍊的請求或響應消息必須經過四個連接配接段。這個區 别是重要的，因為一些HTTP通訊選擇可能應用于最近的連接配接、沒有通道的鄰居，應用于鍊的終點或應用于沿鍊的所有連接配接。盡管圖2-2是線性的，每個參與者 都可能從事多重的、并發的通訊。例如，B可能從許多客戶機接收請求而不通過A，并且／或者不通過C把請求送到A，在同時它還可能處理A的請求。 

任何針對不作為通道的彙聚可能為處理請求啟用一個内部緩存。緩存的效果是請求／響應鍊被縮短，條件是沿鍊的參與者之一具有一個緩存的響應作用于那個請求。下圖說明結果鍊，其條件是針對一個未被UA或A加緩存的請求，B有一個經過C來自O的一個前期響應的緩存拷貝。 

圖2-3 

在Internet上，HTTP通訊通常發生在TCP/IP連接配接之上。預設端口是TCP 80，但其它的端口也是可用的。但這并不預示着HTTP協定在Internet或其它網絡的其它協定之上才能完成。HTTP隻預示着一個可靠的傳輸。 

以上簡要介紹了HTTP協定的宏觀運作方式，下面介紹一下HTTP協定的内部操作過程。 

首先，簡單介紹基于HTTP協定的客戶/伺服器模式的資訊交換過程，如圖2-4所示，它分四個過程，建立連接配接、發送請求資訊、發送響應資訊、關閉連接配接。 

圖2-4 

在WWW中，"客戶"與"伺服器"是一個相對的概念，隻存在于一個特定的連接配接期間，即在某個連接配接中的客戶在另一個連接配接中可能作為伺服器。WWW伺服器運作時，一直在TCP80端口(WWW的預設端口)監聽，等待連接配接的出現。 

下面，讨論HTTP協定下客戶/伺服器模式中資訊交換的實作。 　　 

1.建立連接配接  

連接配接的建立是通過申請套接字(Socket)實作的。客戶打開一個套接字并把它限制在一個端口上，如果成功，就相當于建立了一個虛拟檔案。以後就可以在該虛拟檔案上寫資料并通過網絡向外傳送。 

2.發送請求 

打開一個連接配接後，客戶機把請求消息送到伺服器的停留端口上，完成提出請求動作。 

HTTP/1.0　　請求消息的格式為： 

請求消息=請求行(通用資訊|請求頭|實體頭) CRLF[實體内容] 

請求行=方法　請求URL　HTTP版本号　CRLF 

方法=GET|HEAD|POST|擴充方法 

URL=協定名稱+宿主名+目錄與檔案名 

請求行中的方法描述指定資源中應該執行的動作，常用的方法有GET、HEAD和POST。不同的請求對象對應GET的結果是不同的，對應關系如下： 

對象　　　　　　GET的結果 

檔案　　　　　　檔案的内容 

程式　　　　　　該程式的執行結果 

資料庫查詢　　　查詢結果 

HEAD--要求伺服器查找某對象的元資訊，而不是對象本身。 

POST--從客戶機向伺服器傳送資料，在要求伺服器和CGI做進一步處理時會用到POST方法。POST主要用于發送HTML文本中FORM的内容，讓CGI程式處理。 

一個請求的例子為： 

GET http://networking.zju.edu.cn/zju/index.htm HTTP/1.0 

頭資訊又稱為元資訊，即資訊的資訊，利用元資訊可以實作有條件的請求或應答 。 

請求頭--告訴伺服器怎樣解釋本次請求，主要包括使用者可以接受的資料類型、壓縮方法和語言等。 

實體頭--實體資訊類型、長度、壓縮方法、最後一次修改時間、資料有效期等。 

實體--請求或應答對象本身。 

3.發送響應 

伺服器在處理完客戶的請求之後，要向客戶機發送響應消息。 

HTTP/1.0的響應消息格式如下： 

響應消息=狀态行(通用資訊頭|響應頭|實體頭)　CRLF　〔實體内容〕 

狀 态 行=HTTP版本号　狀态碼　原因叙述 

狀态碼表示響應類型 

1××　　保留 

2××　　表示請求成功地接收 

3××　　為完成請求客戶需進一步細化請求 

4××　　客戶錯誤 

5××　　伺服器錯誤  

響應頭的資訊包括：服務程式名，通知客戶請求的URL需要認證，請求的資源何時能使用。 

4.關閉連接配接 

客戶和伺服器雙方都可以通過關閉套接字來結束TCP/IP對話 

二．http協定請求頭格式分析 

http協定的請求頭分為10個部分。 

1.From: 

以internet郵件的形式，這一字段給出了正在請求的使用者的名字。這一字段也許被用來登陸和一種存取保護的不安全形式。這一字段的解釋是代表被給定使用者的要求正在被執行，這個使用者接受被執行方法的回應。 

這一字段裡的網際網路郵件位址并非一定要對送出請求的主機回應.例如，當一個請求正通過一個網關時，開始的釋出者的位址應該被使用。 

假如能的話，郵件位址應該時一個有效的郵件位址而不管它實際上是否是一個internet郵件位址。 

2.Accept: 

這一字段包含了一個分隔的請求方案清單，它将在這個請求的回應中被接受。這一字段可能會根據RCFC822被包裝成幾行，并且這個字段不僅僅一次的發生也是被接受的，好像所有的入口已經在一個域種了。清單中每個入口的模式如下： 

<field> =   Accept: <entry> *[ , <entry> ] 

<entry> =   <content type> *[ ; <param> ] 

<param> =   <attr> = <float> 

<attr>   =   q / mxs / mxb 

<float> =   <ANSI-C floating point text represntation> 

注意在上述文法中分号的優先級高于逗号，這是為了符合多用途的忘記郵件擴充協定。 

記入沒有Accept字段出現，那麼假定無格式正文和html正文被接受。 

Example 

Accept: text/plain, text/html 

Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c 

為了節省時間，并且也允許客戶接受他們可能不會意識到的content type一個星号也許被使用在下面的地方，either the second half of the content-type value, or both halves。這僅僅被應用于Accept，而且不是對于content-type field of course的。 

Accept: *.*, q=0.1 

Accept: audio/*, q=0.2 

Accept: audio/basic q=1 

上面的例子可以這樣解釋：假如你有基本音頻，那麼傳送它，否則傳送給我一些其他的聲音，或者不能那樣作，那麼僅僅給我你所得到的。 

Type parameters 

  在（content type）中參數對于描述決議，顔色深度等等是特别重要的。他們将允許一個客戶來在Accept字段中指定它的裝置的決議。這也許允許server在傳輸 時通過減少一個圖檔的resultion來大大的節約。并且使一個更适合的使用者時間的黑白圖象被選中而不是給客戶一個彩色圖檔來轉換成單色的。 

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: 

下面這些參數是當類型被注冊時而被具體詳細說明的。 

  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一樣，但是僅列出了在響應中是可接受的Content-Encoding types 

<field> =   Accept-Encoding: <entry> *[ , <entry> ] 

<entry> =   <content transfer encoding> *[ , <param> ] 

Example： 

Accept-Encoding: x-compress; x-zip 

4。Accept-Language: 

和Accept一樣但是列出了在響應中更好的Language values。在一個未詳細說明的語言中一個響應不是非法的。 

5．User-Agent： 

假如存在的話，這一行給出了被原始使用者使用的軟體程式。這是為了統計和protocol violations的追蹤而給出的。第一個白色空格劃定了單詞必須是軟體産品名有一個可選的斜線和版本說明。其他形成了使用者代理的部分産品也許被作為分開的單詞被安排。 

<field>   =   User-Agent: <product>+ 

<product> =   <word> [/<version>] 

<version> =   <word> 

Example: 

User-Agent: LII-Cello/1.0 libwww/2.5 

6．Referer: 

這個可選的header field允許客戶詳細說明，為了server的好處，文檔的位址或者文檔中的元素，URI通過文檔的位址或者文檔中的元素在請求中被獲得。 

這允許一個伺服器來産生向後對文檔的連結，它允許壞連結為了維護而被跟蹤。 

假如一個部分的URI被給出那麼它應該被解析到相應的請求對象的URI。 

Referer: http://www.w3.org/hypertext/DataSources/Overview.html 

7．Authorization: 

假如這一行存在的話它包含了授權資訊。格式也是被指定的。這一字段的格式是在可擴充的形式。第一個單詞是一個使用中的被授權的系統的規範。 

Basic 

Specification for current one implemented by AL Sep 1993. 

  PGP/PEM Encryption（pgp/增強的加密電子郵件 密碼術） 

  People at NCSA are designing a PGP/PEM based protection system. 

  User/Password scheme 

  Authorization: user fred:mypassword 

  設計名是"user"。第二個單詞是一個使用者名，有一個被冒号分開的可選的密碼，就好像在ftp的URL文法一樣。沒有密碼的話這提供了一個非常低級的安全保證，有了密碼，它提供了一個低級安全保證作為未定義的FTP,Telnet等等。 

  Koreros 

  Authorization: kerberos kerberos authentications parameters 

  Kerberos的确認參數格式被具體指定。 

  8．ChargeTo: 

  假如這一行存在地話，它包括了被請求的方法的程式的帳戶資訊。格式是TBS 

  （To Be Specified）這個字段的格式必須是在擴充模式的。第一個單詞以一個namespaces的說明開始。這和擴充URLㄒ搴芟瘛５鼻懊揮衝amespaces被定義。Namespaces見被随着注冊确認而注冊。 

  這行的其餘部分的格式是一個系統有關的函數但是它被推薦這包含了一個被使用者确認得本次事務的最大花費和一個花費單元。 

  If-Modified-Since: date 

  這個請求頭被随着get方法使用使之有條件。假如請求文檔直到被定義還沒改變得花那麼文檔不會被發送，但是會有一個Not Modified 304 回應。 

  這個字段的格式和日期的一樣。 

  9.Pragma: 

  文法和其它的http中的多值字段一樣，就像Accept字段，名以上是一個冒号分開的入口清單對他來說可選的參數是被漢歐摯摹? 

  Pragma 訓示應該被伺服器了解，對它來說是相對的，例如，一個代理伺服器目前僅僅一個pragma被定義：no-cache  

  當目前的代理不應該從緩存傳回一個文檔時，即使它還沒有被到期，但是它總應該從實際存在地伺服器請求文檔。 

  Pragma應該被通過代理實作，甚至他們也許對代理本身有意義。當請求不得不通過許多代理時，這在事件中是必須的，而且pragma應該隊所有的他們有效。 

以下是用jetcar在亦多下載下傳網絡吸血鬼的資訊 

Thu Mar 14 14:36:56 2002 正在連接配接 202.113.29.120 [IP=202.113.29.120:80] 

//正在連接配接主機，解析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 //請求行，表示用get方式取得檔案，并且是HTTP1.1版本 

Thu Mar 14 14:36:57 2002 HOST: 202.113.29.120 //主機名 

Thu Mar 14 14:36:57 2002 ACCEPT: */*   //accept字段，接受的資料類型 

Thu Mar 14 14:36:57 2002 Referer: http://202.113.29.120//從該網址轉發而來 

Thu Mar 14 14:36:57 2002 User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)//用戶端辨別 

Thu Mar 14 14:36:57 2002 Pragma: no-cache //參數，表示與以前的伺服器相容 

Thu Mar 14 14:36:57 2002 Cache-Control: no-cache //不使用緩存 

Thu Mar 14 14:36:57 2002 Connection: close //表示非持續性連接配接。 

以下為response字段 

Thu Mar 14 14:36:58 2002 HTTP/1.1 302 Found 

伺服器使用HTTP/1.0協定，狀态值（Status Code）為200，狀态為OK，表示檔案可以讀取 

Thu Mar 14 14:36:58 2002 Date: Thu, 14 Mar 2002 06:52:16 GMT//現在的時間，用格林威治時間表示 

Thu Mar 14 14:36:58 2002 Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1 

//伺服器類型 

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//請求文檔過期時間 

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 

備注：伺服器傳回的各類錯誤 

當伺服器響應時，其狀态行的資訊為HTTP的版本号，狀态碼，及解釋狀态碼的簡單說明。現将5類狀态碼詳細列出：  

① 客戶方錯誤  

100　 繼續  

101　 交換協定  

② 成功  

200 　OK  

201 　已建立  

202　 接收  

203　 非認證資訊  

204　 無内容  

205 　重置内容  

206　 部分内容  

③ 重定向  

300 　多路選擇  

301　 永久轉移  

302　 暫時轉移  

303　 參見其它  

304 　未修改（Not Modified）  

305　 使用代理  

④ 客戶方錯誤  

400　 錯誤請求（Bad Request）  

401 　未認證  

402 　需要付費  

403　 禁止（Forbidden）  

404　 未找到（Not Found）  

405　 方法不允許  

406　 不接受  

407　 需要代理認證  

408　 請求逾時  

409　 沖突  

410 　失敗  

411 　需要長度  

412　 條件失敗  

413 　請求實體太大  

414 　請求URI太長  

415 　不支援媒體類型  

⑤ 伺服器錯誤  

500　 伺服器内部錯誤  

501　 未實作（Not Implemented）  

502　 網關失敗  

504 　網關逾時  

505 　HTTP版本不支援