時間
世間最可貴的就是“今”，最易喪失得也是“今”。因為它最容易喪失，所以更覺得它寶貴。

BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合

:: 管理

posts - 15, comments - 8, trackbacks - 0

<

2025年6月

>

日

一

二

三

四

五

六

25

26

27

28

29

30

31

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

1

2

3

4

5

常用鏈接

留言簿(8)

隨筆分類

隨筆檔案

文章分類

文章檔案

搜索

積分與排名

積分 - 63385
排名 - 838

閱讀排行榜

評論排行榜

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的。
Example
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。
Example:
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版本不支持

posted on 2008-06-23 22:47 lvq810 閱讀(4867) 評論(0) 編輯收藏所屬分類: Html/JavaScript/Ajax

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: [轉載]有關 JavaScript 的 10 件讓人費解的事情 [轉]HTML 5 預覽 [轉]來自Google的密碼強度Javascript驗證代碼圖片幻燈片切換特效手動幻燈圖片效果 JavaScript自動圖片切換 10款讓你震撼的圖片展示js代碼[轉] HTTP協議頭字段及分析 HTTP協議及其請求頭分析 JavaScript 網頁事件[轉]