http:互聯網上應用最為廣泛的一種網絡協議-中文百科頻道

協議基礎

HTTP（HyperText Transport Protocol）是超文本傳輸協議的縮寫，它用于傳送WWW方式的數據，關于HTTP協議的詳細内容請參考RFC2616。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URL、協議版本、以及包含請求修飾符、客戶信息和内容的類似于MIME的消息結構。服務器以一個狀态行作為響應，響應的内容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體内容。

通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個指示頭域結束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒号（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。

通用頭域

通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Contro

l、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般将會作為實體頭域處理。下面簡單介紹幾個在UPnP消息中使用的通用頭域：

1.Cache-Control頭域

Cache-Control指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置Cache-Control并不會修改另一個消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義如下：

Public指示響應可被任何緩存區緩存。

Private指示對于單個用戶的整個或部分響應消息，不能被共享緩存處理。這允許服務器僅僅描述當用戶

的部分響應消息，此響應消息對于其他用戶的請求無效。

no-cache指示請求或響應消息不能緩存

no-store用于防止重要的信息被無意的發布。在請求消息中發送将使得請求和響應消息都不使用緩存。

max-age指示客戶機可以接收生存期不大于指定時間（以秒為單位）的響應。

min-fresh指示客戶機可以接收響應時間小于當前時間加上指定時間的響應。

max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那麼客戶機可以接收超出超時期指定值之内的響應消息。

HTTP Keep-Alive

Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上的大部分Web服務器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對于提供靜态内容的網站來說，這個功能通常很有用。但是，對于負擔較重的網站來說，這裡存在另外一個問題：雖然為客戶保留打開的連接有一定的好處，但它同樣影響了性能，因為在處理暫停期間，本來可以釋放的資源仍舊被占用。當Web服務器和應用服務器在同一台機器上運行時，Keep- Alive功能對資源利用的影響尤其突出。

KeepAliveTime 值控制 TCP/IP 嘗試驗證空閑連接是否完好的頻率。如果這段時間内沒有活動，則會發送保持活動信号。如果網絡工作正常，而且接收方是活動的，它就會響應。如果需要對丢失接收方敏感，換句話說，需要更快地發現丢失了接收方，請考慮減小這個值。如果長期不活動的空閑連接出現次數較多，而丢失接收方的情況出現較少，您可能會要提高該值以減少開銷。缺省情況下，如果空閑連接 7200000 毫秒（2 小時）内沒有活動，Windows 就發送保持活動的消息。通常，1800000 毫秒是首選值，從而一半的已關閉連接會在 30 分鐘内被檢測到。 KeepAliveInterval 值定義了如果未從接收方收到保持活動消息的響應，TCP/IP 重複發送保持活動信号的頻率。當連續發送保持活動信号、但未收到響應的次數超出 TcpMaxDataRetransmissions 的值時，會放棄該連接。如果期望較長的響應時間，您可能需要提高該值以減少開銷。如果需要減少花在驗證接收方是否已丢失上的時間，請考慮減小該值或 TcpMaxDataRetransmissions 值。缺省情況下，在未收到響應而重新發送保持活動的消息之前，Windows 會等待 1000 毫秒（1 秒）。 KeepAliveTime 根據你的需要設置就行，比如10分鐘，注意要轉換成MS。 XXX代表這個間隔值得大小。

2.Date頭域

Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界标準時，換算成本地時間，需要知道用戶所在的時區。

3.Pragma頭域

Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache-Control:no-cache相同。

請求消息

請求消息的第一行為下面的格式：

MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對于Request-URI完成的方法，這個字段是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應該被所有的通用WEB服務器支持，其他所有方法的實現是可選的。GET方法取回由Request-URI标識的信息。HEAD方法也是取回由Request-URI标識的信息，隻是可以在響應時，不返回消息體。POST方法可以請求服務器接收包含在請求中的實體信息，可以用于提交表單，向新聞組、BBS、郵件群組和數據庫發送消息。

SP表示空格。Request-URI遵循URI格式，在此字段為星号（*）時，說明請求并不用于某個特定的資源地址，而是用于服務器本身。HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。CRLF表示換行回車符。請求頭域允許客戶端向服務器傳遞關于請求或者關于客戶機的附加信

息。請求頭域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴展要求通訊雙方都支持，如果存在不支持的請求頭域，一般将會作為實體頭域處理。

典型的請求消息：

Host: download.*******.de

Accept: */*

Pragma: no-cache

Cache-Control: no-cache

User-Agent: Mozilla/4.04[en](Win95;I;Nav)

Range: bytes=554554-

上例第一行表示HTTP客戶端（可能是浏覽器、下載程序）通過GET方法獲得指定URL下的文件。棕色的部分表示請求頭域的信息，綠色的部分表示通用頭部分。

1.Host頭域

Host頭域指定請求資源的Intenet主機和端口号，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀态碼返回。

2.Referer頭域

Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鍊表，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由于維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發送。如果指定的是部分uri地址，則此地址應該是一個相對地址。

3.Range頭域

Range頭域可以請求實體的一個或者多個子範圍。例如，

表示頭500個字節：bytes=0-499

表示第二個500字節：bytes=500-999

表示最後500個字節：bytes=-500

表示500字節以後的範圍：bytes=500-

第一個和最後一個字節：bytes=0-0,-1

同時指定幾個範圍：bytes=500-600,601-999

但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀态碼206（PartialContent）返回而不是以200（OK）。

4.User-Agent頭域

User-Agent頭域的内容包含發出請求的用戶信息。

響應消息

響應消息的第一行為下面的格式：

HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF

HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。Status-Code是一個三個數字的結果代碼。Reason-Phrase給Status-Code提供一個簡單的文本描述。Status-Code主要用于機器自動識别，Reason-Phrase主要用于幫助用戶理解。Status-Code的第一個數字定義響應的類别，後兩個數字沒有分類的作用。第一個數字可能取5個不同的值：

1xx:信息響應類，表示接收到請求并且繼續處理

2xx:處理成功響應類，表示動作被成功接收、理解和接受

3xx:重定向響應類，為了完成指定的動作，必須接受進一步處理

4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正确執行

5xx:服務端錯誤，服務器不能正确執行一個正确的請求

響應頭域允許服務器傳遞不能放在狀态行的附加信息，這些域主要描述服務器的信息和Request-URI進一步的信息。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支持，如果存在不支持的響應頭域，一般将會作為實體頭域處理。

典型的響應消息：

HTTP/1.0200OK

Date:Mon,31Dec200104:25:57GMT

Server:Apache/1.3.14(Unix)

Content-type:text/html

Last-modified:Tue,17Apr200106:46:28GMT

Etag:"a030f020ac7c01:1e9f"

Content-length:39725426

Content-range:bytes55******/40279980

上例第一行表示HTTP服務端響應一個GET方法。棕色的部分表示響應頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的信息。

1.Location響應頭

Location響應頭用于重定向接收者到一個新URI地址。

2.Server響應頭

Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個産品标識和注釋，産品标識一般按照重要性排序。

實體信息

請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關于實體的原信息，實體頭包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允許客戶端定義新的實體頭，但是這些域可能無法被接受方識别。實體可以是一個經過編碼的字節流，它的編碼方式由Content-Encoding或Content-Type定義，它的長度由Content-Length或Content-Range定義。

1.Content-Type實體頭

Content-Type實體頭用于向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型

2.Content-Range實體頭

Content-Range實體頭用于指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應複蓋的範圍和整個實體長度。一般格式：

Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth

例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的字節數。

3.Last-modified實體頭

Last-modified實體頭指定服務器上保存内容的最後修訂時間。

發展簡史

理論提出

超文本傳輸協議的前身是世外桃源(Xanadu)項目，超文本的概念是泰德˙納爾森(Ted Nelson)在1960年代提出的。進入哈佛大學後，納爾森一直緻力于超文本協議和該項目的研究，但他從未公開發表過資料。

程序開發

1989年，蒂姆˙伯納斯˙李(Tim Berners Lee)在CERN(歐洲原子核研究委員會 = European Organization for Nuclear Research)擔任軟件咨詢師的時候，開發了一套程序，奠定了萬維網的基礎。1990年12月，超文本在CERN首次上線。1991年夏天，繼Telnet等協議之後，超文本轉移協議成為互聯網諸多協議的一分子。

發展狀況

當時，Telnet協議解決了一台計算機和另外一台計算機之間一對一的控制型通信的要求。郵件協議解決了一個發件人向少量人員發送信息的通信要求。文件傳輸協議解決一台計算機從另外一台計算機批量獲取文件的通信要求，但是它不具備一邊獲取文件一邊顯示文件或對文件進行某種處理的功能。新聞傳輸協議解決了一對多新聞廣播的通信要求。而超文本要解決的通信要求是:在一台計算機上獲取并顯示存放在多台計算機裡的文本、數據、圖片和其他類型的文件;它包含兩大部分:超文本轉移協議和超文本标記語言(HTML)。HTTP、HTML以及浏覽器的誕生給互聯網的普及帶來了飛躍。

萬維網的工作過程

超文本傳輸協議，是我們浏覽網頁、看在線視頻、聽在線音樂等必須遵循的規則。正是在這樣的規則下，浏覽器(萬維網客戶)才能向萬維網服務器發送萬維網文檔請求，然後服務器會将請求的文檔發送回浏覽器。在浏覽器和服務器之間的請求和響應的交互，必須按照規定的格式和規則，這些格式和規則就構成了超文本傳輸協議。

萬維網的工作過程

計算機系統中有一個專門為HTTP開放的80端口，主要用于萬維網傳輸信息的協議。每個萬維網網點(可以是計算機)都有一個服務器進程來監聽TCP的80端口，一旦發現浏覽器向它發出連接建立請求，繼而建立TCP連接，浏覽器就向萬維網服務器發出浏覽某個網頁的請求，服務器就接着返回所請求的頁面作為響應。最後，TCP連接被釋放。

需要說明的是，HTTP協議是無狀态的，也就是說同一個客戶第二次訪問同一個服務器上面的頁面時，服務器的響應與第一次訪問時的相同。服務器并不知道曾經訪問過此客戶，更不會記得此客戶曾經被服務過多少次了。但是，在實際工作中一些萬維網站點還是希望能夠識别用戶的。比如，你在某個購物網站上将某個産品加入購物車後，希望繼續浏覽并選購其它商品，這時服務器就需要記住用戶的身份以便所有的商品可以一起結賬。

HTTP中的Cookie提供了這種功能。Cookie是這樣工作的:當用戶(代号為User)訪問某個使用Cookie的網站時，該網站就會為User産生一個唯一的識别碼并以此作為索引在服務器的後端數據庫中産生一個項目。接着在給User的HTTP響應報文(關于HTTP的報文結構附錄會有介紹，讀者可以先看那部分内容)中添加Set-cookie的首部行。這裡的"首部字段名"為"Set-cookie"，後面的"值"就是賦予該用戶的"識别碼"。例如這個首部行為:Set-cookie:09876543。

當User收到這個響應時，其浏覽器就在它管理的特定Cookie文件中添加一行，其中包括這個服務器的主機名和Set-cookie後面給出的識别碼。當User繼續浏覽這個網站時，每發送一個HTTP請求報文，其浏覽器就會從其Cookie文件中取出這個網站的識别碼并放到HTTP請求報文的Cookie首部行中:Cookie:09876543。于是這個網站就能夠跟蹤User在這個網站的活動，也就能夠實現購買的商品一起付費了。服務器和用戶的交集僅僅在于這個識别碼，服務器不知道User的其它任何信息。