HTTP概述

超文本傳輸協(xié)議(HTTP，HyperText Transfer Protocol)

是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。

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)站。通過(guò)使用Web瀏覽器、網(wǎng)絡(luò)爬蟲(chóng)或者其它的工具，客戶端發(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é)議并沒(méi)有規(guī)定必須使用它和（基于）它支持的層。 事實(shí)上，HTTP可以在任何其他互聯(lián)網(wǎng)協(xié)議上，或者在其他網(wǎng)絡(luò)上實(shí)現(xiàn)。HTTP只假定（其下層協(xié)議提供）可靠的傳輸，任何能夠提供這種保證的協(xié)議都可以被其使用。

通常，由HTTP客戶端發(fā)起一個(gè)請(qǐng)求，建立一個(gè)到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接。HTTP服務(wù)器則在那個(gè)端口監(jiān)聽(tīng)客戶端發(fā)送過(guò)來(lái)的請(qǐng)求。一旦收到請(qǐng)求，服務(wù)器（向客戶端）發(fā)回一個(gè)狀態(tài)行，比如"HTTP/1.1 200 OK"，和（響應(yīng)的）消息，消息的消息體可能是請(qǐng)求的文件、錯(cuò)誤消息、或者其它一些信息。

HTTP使用TCP而不是UDP的原因在于（打開(kāi)一個(gè)）一個(gè)網(wǎng)頁(yè)必須傳送很多數(shù)據(jù)，而TCP協(xié)議提供傳輸控制，按順序組織數(shù)據(jù)，和錯(cuò)誤糾正。具體細(xì)節(jié)請(qǐng)參考‘TCP和UDP的不同’。

通過(guò)HTTP或者HTTPS協(xié)議請(qǐng)求的資源由統(tǒng)一資源定位器（Uniform Resource Identifiers）（或者，更準(zhǔn)確一些，URLs）來(lái)標(biāo)識(shí)。

2、請(qǐng)求信息Request Message

發(fā)出的請(qǐng)求信息包括以下幾個(gè)

請(qǐng)求行，例如GET /images/logo.gif HTTP/1.1，表示從/images 目錄下請(qǐng)求logo.gif 這個(gè)文件。
（請(qǐng)求）頭，例如Accept-Language: en

空行

可選的消息體

請(qǐng)求行和標(biāo)題必須以<CR><LF> 作為結(jié)尾（也就是，回車然后換行）。空行內(nèi)必須只有<CR><LF>而無(wú)其他空格。在HTTP/1.1 協(xié)議中，所有的請(qǐng)求頭，除Host外，都是可選的。

3、請(qǐng)求方法

HTTP/1.1協(xié)議中共定義了八種方法（有時(shí)也叫“動(dòng)作”）來(lái)表明Request-URI指定的資源的不同操作方式：

OPTIONS

返回服務(wù)器針對(duì)特定資源所支持的HTTP請(qǐng)求方法。也可以利用向Web服務(wù)器發(fā)送'*'的請(qǐng)求來(lái)測(cè)試服務(wù)器的功能性。

HEAD

向服務(wù)器索要與GET請(qǐng)求相一致的響應(yīng)，只不過(guò)響應(yīng)體將不會(huì)被返回。這一方法可以在不必傳輸整個(gè)響應(yīng)內(nèi)容的情況下，就可以獲取包含在響應(yīng)消息頭中的元信息。

GET

向特定的資源發(fā)出請(qǐng)求。注意：GET方法不應(yīng)當(dāng)被用于產(chǎn)生“副作用”的操作中，例如在Web Application中。其中一個(gè)原因是GET可能會(huì)被網(wǎng)絡(luò)蜘蛛等隨意訪問(wèn)。參見(jiàn)安全方法

POST

向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。

PUT

向指定資源位置上傳其最新內(nèi)容。

DELETE

刪除指定資源。

TRACE

回顯服務(wù)器收到的請(qǐng)求。

CONNECT

HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

方法名稱是區(qū)分大小寫(xiě)的。當(dāng)某個(gè)請(qǐng)求所針對(duì)的資源不支持對(duì)應(yīng)的請(qǐng)求方法的時(shí)候，服務(wù)器應(yīng)當(dāng)返回狀態(tài)碼405(Method Not Allowed)；當(dāng)服務(wù)器不認(rèn)識(shí)或者不支持對(duì)應(yīng)的請(qǐng)求方法的時(shí)候，應(yīng)當(dāng)返回狀態(tài)碼501(Not Implemented)。

HTTP服務(wù)器至少應(yīng)該實(shí)現(xiàn)GET和HEAD方法，其他方法都是可選的。當(dāng)然，所有的方法支持的實(shí)現(xiàn)都應(yīng)當(dāng)符合下述的方法各自的語(yǔ)義定義。此外，除了上述方法，特定的HTTP服務(wù)器還能夠擴(kuò)展自定義的方法。
安全及冪等方法

安全方法

開(kāi)發(fā)者應(yīng)當(dāng)意識(shí)到他們的軟件代表了用戶在因特網(wǎng)上進(jìn)行交互，并且應(yīng)當(dāng)告知用戶，他們正在進(jìn)行的操作可能對(duì)他們自身或者其他人有未曾預(yù)料的重要影響。

特別地，對(duì)于GET和HEAD方法而言，除了進(jìn)行獲取資源信息外，這些請(qǐng)求不應(yīng)當(dāng)再有任何其他意義。也就是說(shuō)，這些方法應(yīng)當(dāng)被認(rèn)為是“安全的”。客戶端應(yīng)當(dāng)使用其他“非安全”方法，例如POST，PUT及DELETE來(lái)以特殊的方式（通常是按鈕而不是超鏈接）使得客戶能夠意識(shí)到可能要負(fù)的責(zé)任（例如一個(gè)按鈕帶來(lái)的資金交易）或者被告知正在請(qǐng)求的操作可能是不安全的（例如某個(gè)文件將被上傳或刪除）。

但是，不能想當(dāng)然地認(rèn)為服務(wù)器不會(huì)在處理某個(gè)GET請(qǐng)求時(shí)不會(huì)產(chǎn)生任何副作用。事實(shí)上，很多動(dòng)態(tài)資源會(huì)把這作為其特性。這里重要的區(qū)別在于用戶并沒(méi)有請(qǐng)求這一副作用，因此不應(yīng)由用戶為這些副作用承擔(dān)責(zé)任。

冪等方法

假如在不考慮諸如錯(cuò)誤或者過(guò)期等問(wèn)題的情況下，若干次請(qǐng)求的副作用與單次請(qǐng)求相同或者根本沒(méi)有副作用，那么這些請(qǐng)求方法就能夠被視作“冪等”的。GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由于根據(jù)協(xié)議，OPTIONS，TRACE都不應(yīng)有副作用，因此也理所當(dāng)然也是冪等的。

假如某個(gè)由若干個(gè)請(qǐng)求做成的請(qǐng)求序列產(chǎn)生的結(jié)果在重復(fù)執(zhí)行這個(gè)請(qǐng)求序列或者其中任何一個(gè)或多個(gè)請(qǐng)求后仍沒(méi)有發(fā)生變化，則這個(gè)請(qǐng)求序列便是“冪等”的。但是，可能出現(xiàn)若干個(gè)請(qǐng)求做成的請(qǐng)求序列是“非冪等”的，即使這個(gè)請(qǐng)求序列中所有執(zhí)行的請(qǐng)求方法都是冪等的。例如，這個(gè)請(qǐng)求序列的結(jié)果依賴于某個(gè)會(huì)在下次執(zhí)行這個(gè)序列的過(guò)程中被修改的變量。

4、協(xié)議版本號(hào)

超文本傳輸協(xié)議已經(jīng)演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本號(hào)的用法。客戶端在請(qǐng)求的開(kāi)始告訴服務(wù)器它采用的協(xié)議版本號(hào)，而后者則在響應(yīng)中采用相同或者更早的協(xié)議版本。
0.9

已過(guò)時(shí)。只接受 GET 一種請(qǐng)求方法，沒(méi)有在通訊中指定版本號(hào)，且不支持請(qǐng)求頭。由于該版本不支持 POST 方法，所以客戶端無(wú)法向服務(wù)器傳遞太多信息。

HTTP/1.0

這是第一個(gè)在通訊中指定版本號(hào)的 HTTP 協(xié)議版本，至今仍被廣泛采用，特別是在代理服務(wù)器中。

HTTP/1.1

當(dāng)前版本。持久連接被默認(rèn)采用，并能很好地配合代理服務(wù)器工作。還支持以管道方式在同時(shí)發(fā)送多個(gè)請(qǐng)求，以便降低線路負(fù)載，提高傳輸速度。

HTTP/1.1相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在：

緩存處理

帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用

錯(cuò)誤通知的管理

消息在網(wǎng)絡(luò)中的發(fā)送

互聯(lián)網(wǎng)地址的維護(hù)

安全性及完整性

5、狀態(tài)行

參見(jiàn)：HTTP狀態(tài)碼

所有 HTTP 響應(yīng)的第一行都是狀態(tài)行, 依次是當(dāng)前 HTTP 版本號(hào)，3位數(shù)字組成的狀態(tài)代碼，以及描述狀態(tài)的短語(yǔ)，彼此由空格分隔。

狀態(tài)代碼的第一個(gè)數(shù)字代表當(dāng)前響應(yīng)的類型：

1xx 消息——請(qǐng)求已被服務(wù)器接收，繼續(xù)處理

2xx 成功——請(qǐng)求已成功被服務(wù)器接收、理解、并接受

3xx 重定向——需要后續(xù)操作才能完成這一請(qǐng)求

4xx 請(qǐng)求錯(cuò)誤——請(qǐng)求含有詞法錯(cuò)誤或者無(wú)法被執(zhí)行

5xx 服務(wù)器錯(cuò)誤——服務(wù)器在處理某個(gè)正確請(qǐng)求時(shí)發(fā)生錯(cuò)誤

雖然 RFC 2616 中已經(jīng)推薦了描述狀態(tài)的短語(yǔ)，例如"200 OK"，"404 Not Found"，但是 WEB 開(kāi)發(fā)者仍然能夠自行決定采用何種短語(yǔ)，用以顯示本地化的狀態(tài)描述或者自定義信息。

HTTP是什么?

當(dāng)我們想瀏覽一個(gè)網(wǎng)站的時(shí)候，只要在瀏覽器的地址欄里輸入網(wǎng)站的地址就可以了，例如www.baidu.com,但是在瀏覽器的地址欄里面出現(xiàn)的卻是：http://www.baidu.com ,你知道為什么會(huì)多出一個(gè)“http”嗎？

我們?cè)跒g覽器的地址欄里輸入的網(wǎng)站地址叫做URL (Uniform Resource Locator，統(tǒng)一資源定位符)。就像每家每戶都有一個(gè)門(mén)牌地址一樣，每個(gè)網(wǎng)頁(yè)也都有一個(gè)Internet地址。當(dāng)你在瀏覽器的地址框中輸入一個(gè)URL或是單擊一個(gè)超級(jí)鏈接時(shí)，URL就確定了要瀏覽的地址。瀏覽器通過(guò)超文本傳輸協(xié)議(HTTP)，將Web服務(wù)器上站點(diǎn)的網(wǎng)頁(yè)代碼提取出來(lái)，并翻譯成漂亮的網(wǎng)頁(yè)。因此，在我們認(rèn)識(shí)HTTP之前，有必要先弄清楚URL的組成,例如：http://www.baidu.com/china/index.htm。它的含義如下：

1. http://：代表超文本傳輸協(xié)議，通知baidu.com服務(wù)器顯示W(wǎng)eb頁(yè)，通常不用輸入；

2. www：代表一個(gè)Web（萬(wàn)維網(wǎng)）服務(wù)器；

3. baidu.com/：這是裝有網(wǎng)頁(yè)的服務(wù)器的域名，或站點(diǎn)服務(wù)器的名稱；

4. China/：為該服務(wù)器上的子目錄，就好像我們的文件夾；

5. Index.htm：index.htm是文件夾中的一個(gè)HTML文件（網(wǎng)頁(yè)）。

我們知道，Internet的基本協(xié)議是TCP/IP協(xié)議，然而在TCP/IP模型最上層的是應(yīng)用層（Application layer），它包含所有高層的協(xié)議。高層協(xié)議有：文件傳輸協(xié)議FTP、電子郵件傳輸協(xié)議SMTP、域名系統(tǒng)服務(wù)DNS、網(wǎng)絡(luò)新聞傳輸協(xié)議NNTP和HTTP協(xié)議等。

HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。這就是你為什么在瀏覽器中看到的網(wǎng)頁(yè)地址都是以http://開(kāi)頭的原因。

自WWW誕生以來(lái)，一個(gè)多姿多彩的資訊和虛擬的世界便出現(xiàn)在我們眼前，可是我們?cè)趺茨軌蚋尤菀椎卣业轿覀冃枰馁Y訊呢？當(dāng)決定使用超文本作為WWW文檔的標(biāo)準(zhǔn)格式后，于是在1990年，科學(xué)家們立即制定了能夠快速查找這些超文本文檔的協(xié)議，即HTTP協(xié)議。經(jīng)過(guò)幾年的使用與發(fā)展，得到不斷的完善和擴(kuò)展，目前在WWW中使用的是HTTP/1.0的第六版。

http 百科名片

超文本傳輸協(xié)議(HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。

目錄

簡(jiǎn)介

協(xié)議功能

協(xié)議基礎(chǔ)

通用頭域

Cache-Control頭域

HTTP Keep-Alive

Date頭域

Pragma頭域

請(qǐng)求消息

Host頭域

Referer頭域

Range頭域

User-Agent頭域

響應(yīng)消息

HTTP-運(yùn)作方式

實(shí)體

Content-Type實(shí)體頭

Last-modified實(shí)體頭

協(xié)議結(jié)構(gòu)

工作原理

狀態(tài)消息

1xx:信息

2xx:成功

3xx:重定向

4xx:客戶端錯(cuò)誤

5xx:服務(wù)器錯(cuò)誤

版本歷史

協(xié)議版本0.9、HTTP/1.0、HTTP/1.1

簡(jiǎn)介

協(xié)議功能、協(xié)議基礎(chǔ)、通用頭域、Cache-Control頭域

HTTP Keep-Alive、Date頭域、Pragma頭域

請(qǐng)求消息

Host頭域、Referer頭域、Range頭域、User-Agent頭域

響應(yīng)消息

HTTP-運(yùn)作方式、實(shí)體、Content-Type實(shí)體頭、Last-modified實(shí)體頭、協(xié)議結(jié)構(gòu)、工作原理

狀態(tài)消息

1xx:信息

2xx:成功

3xx:重定向

4xx:客戶端錯(cuò)誤

5xx:服務(wù)器錯(cuò)誤

版本歷史

協(xié)議版本0.9、HTTP/1.0、HTTP/1.1

6、簡(jiǎn)介

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)站。通過(guò)使用Web瀏覽器、網(wǎng)絡(luò)爬蟲(chóng)或者其它的工具，客戶端發(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é)議并沒(méi)有規(guī)定必須使用它和（基于）它支持的層。 事實(shí)上，HTTP可以在任何其他互聯(lián)網(wǎng)協(xié)議上，或者在其他網(wǎng)絡(luò)上實(shí)現(xiàn)。HTTP只假定（其下層協(xié)議提供）可靠的傳輸，任何能夠提供這種保證的協(xié)議都可以被其使用。

通常，由HTTP客戶端發(fā)起一個(gè)請(qǐng)求，建立一個(gè)到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接。HTTP服務(wù)器則在那個(gè)端口監(jiān)聽(tīng)客戶端發(fā)送過(guò)來(lái)的請(qǐng)求。一旦收到請(qǐng)求，服務(wù)器（向客戶端）發(fā)回一個(gè)狀態(tài)行，比如"HTTP/1.1 200 OK"，和（響應(yīng)的）消息，消息的消息體可能是請(qǐng)求的文件、錯(cuò)誤消息、或者其它一些信息。 HTTP使用TCP而不是UDP的原因在于（打開(kāi)一個(gè)）一個(gè)網(wǎng)頁(yè)必須傳送很多數(shù)據(jù)，而TCP協(xié)議提供傳輸控制，按順序組織數(shù)據(jù)，和錯(cuò)誤糾正。

通過(guò)HTTP或者HTTPS協(xié)議請(qǐng)求的資源由統(tǒng)一資源標(biāo)示符（Uniform Resource Identifiers）（或者，更準(zhǔn)確一些，URLs）來(lái)標(biāo)識(shí)。

7、協(xié)議功能

HTTP是超文本傳輸協(xié)議，是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議。在Internet上的Web服務(wù)器上存放的都是超文本信息，客戶機(jī)需要通過(guò)HTTP協(xié)議傳輸所要訪問(wèn)的超文本信息。HTTP包含命令和傳輸信息，不僅可用于Web訪問(wèn)，也可以用于其他因特網(wǎng)/內(nèi)聯(lián)網(wǎng)應(yīng)用系統(tǒng)之間的通信，從而實(shí)現(xiàn)各類應(yīng)用資源超媒體訪問(wèn)的集成。

當(dāng)我們想瀏覽一個(gè)網(wǎng)站的時(shí)候，只要在瀏覽器的地址欄里輸入網(wǎng)站的地址就可以了，例如www.*****.com,但是在瀏覽器的地址欄里面出現(xiàn)的卻是：http://www.*******,你知道為什么會(huì)多出一個(gè)“http”嗎？

我們?cè)跒g覽器的地址欄里輸入的網(wǎng)站地址叫做URL (Uniform Resource Locator，統(tǒng)一資源定位符)。就像每家每戶都有一個(gè)門(mén)牌地址一樣，每個(gè)網(wǎng)頁(yè)也都有一個(gè)Internet地址。當(dāng)你在 瀏覽器的地址框中輸入一個(gè)URL或是單擊一個(gè)超級(jí)鏈接時(shí)，URL就確定了要瀏覽的地址。瀏覽器通過(guò)超文本轉(zhuǎn)移協(xié)議(HTTP)，將Web服務(wù)器上站點(diǎn)的網(wǎng)頁(yè)代碼提取出來(lái)，并翻譯成漂亮的網(wǎng)頁(yè)。因此，在我們認(rèn)識(shí)HTTP之前，有必要先弄清楚URL的組成,
例如：

http://www.******.com/china/index.htm。

它的含義如下：

1. http://：代表超文本轉(zhuǎn)移協(xié)議，通知****.com服務(wù)器顯示W(wǎng)eb頁(yè)，通常不用輸入；

2. www：代表一個(gè)Web（萬(wàn)維網(wǎng)）服務(wù)器；

3. ****.com/：這是裝有網(wǎng)頁(yè)的服務(wù)器的域名，或站點(diǎn)服務(wù)器的名稱；

4. China/：為該服務(wù)器上的子目錄，就好像我們的文件夾；

5. Index.htm：index.htm是文件夾中的一個(gè)HTML文件（網(wǎng)頁(yè)）。

我們知道，Internet的基本協(xié)議是TCP/IP協(xié)議，然而在TCP/IP模型最上層的是應(yīng)用層（Application layer），它包含所有高層的協(xié)議。高層協(xié)議有：文件傳輸協(xié)議FTP、電子郵件傳輸協(xié)議SMTP、域名系統(tǒng)服務(wù)DNS、網(wǎng)絡(luò)新聞傳輸協(xié)議NNTP和HTTP協(xié)議等。

HTTP協(xié)議（HyperText Transfer Protocol，超文本轉(zhuǎn)移協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。這就是你為什么在瀏覽器中看到的網(wǎng)頁(yè)地址都是以http://開(kāi)頭的原因。

自WWW誕生以來(lái)，一個(gè)多姿多彩的資訊和虛擬的世界便出現(xiàn)在我們眼前，可是我們?cè)趺茨軌蚋尤菀椎卣业轿覀冃枰馁Y訊呢？當(dāng)決定使用超文本作為WWW文檔的標(biāo)準(zhǔn)格式后，于是在1990年，科學(xué)家們立即制定了能夠快速查找這些超文本文檔的協(xié)議，即HTTP協(xié)議。經(jīng)過(guò)幾年的使用與發(fā)展，得到不斷的完善和擴(kuò)展，目前在WWW中使用的是HTTP/1.0的第六版。

8、協(xié)議基礎(chǔ)

HTTP（HyperText Transfer Protocol）是超文本轉(zhuǎn)移協(xié)議的縮寫(xiě)，它用于傳送WWW方式的數(shù)據(jù)，關(guān)于HTTP協(xié)議的詳細(xì)內(nèi)容請(qǐng)參考RFC2616。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型。客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求，請(qǐng)求頭包含請(qǐng)求的方法、URL、協(xié)議版本、以及包含請(qǐng)求修飾符、客戶信息和內(nèi)容的類似于MIME的消息結(jié)構(gòu)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，相應(yīng)的內(nèi)容包括消息協(xié)議的版本，成功或者錯(cuò)誤編碼加上包含服務(wù)器信息、實(shí)體元信息以及可能的實(shí)體內(nèi)容。

通常HTTP消息包括客戶機(jī)向服務(wù)器的請(qǐng)求消息和服務(wù)器向客戶機(jī)的響應(yīng)消息。這兩種類型的消息由一個(gè)起始行，一個(gè)或者多個(gè)頭域，一個(gè)指示頭域結(jié)束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請(qǐng)求頭，響應(yīng)頭和實(shí)體頭四個(gè)部分。每個(gè)頭域由一個(gè)域名，冒號(hào)（:）和域值三部分組成。域名是大小寫(xiě)無(wú)關(guān)的，域值前可以添加任何數(shù)量的空格符，頭域可以被擴(kuò)展為多行，在每行開(kāi)始處，使用至少一個(gè)空格或制表符。

通用頭域

通用頭域包含請(qǐng)求和響應(yīng)消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對(duì)通用頭域的擴(kuò)展要求通訊雙方都支持此擴(kuò)展，如果存在不支持的通用頭域，一般將會(huì)作為實(shí)體頭域處理。下面簡(jiǎn)單介紹幾個(gè)在UPnP消息中使用的通用頭域。

Cache-Control頭域

Cache-Control指定請(qǐng)求和響應(yīng)遵循的緩存機(jī)制。在請(qǐng)求消息或響應(yīng)消息中設(shè)置Cache-Control并不會(huì)修改另一個(gè)消息處理過(guò)程中的緩存處理過(guò)程。請(qǐng)求時(shí)的緩存指令包括

no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，

響應(yīng)消息中的指令包括

public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

各個(gè)消息中的指令含義如下：
　　
Public指示響應(yīng)可被任何緩存區(qū)緩存。 　
　
Private指示對(duì)于單個(gè)用戶的整個(gè)或部分響應(yīng)消息，不能被共享緩存處理。這允許服務(wù)器僅僅描述當(dāng)用戶 的部分響應(yīng)消息，此響應(yīng)消息對(duì)于其他用戶的請(qǐng)求無(wú)效。

no-cache指示請(qǐng)求或響應(yīng)消息不能緩存
　　
no-store用于防止重要的信息被無(wú)意的發(fā)布。在請(qǐng)求消息中發(fā)送將使得請(qǐng)求和響應(yīng)消息都不使用緩存。 　
　
max-age指示客戶機(jī)可以接收生存期不大于指定時(shí)間（以秒為單位）的響應(yīng)。

min-fresh指示客戶機(jī)可以接收響應(yīng)時(shí)間小于當(dāng)前時(shí)間加上指定時(shí)間的響應(yīng)。 　　
max-stale指示客戶機(jī)可以接收超出超時(shí)期間的響應(yīng)消息。如果指定max-stale消息的值，那么客戶機(jī)可以接收超出超時(shí)期指定值之內(nèi)的響應(yīng)消息。

HTTP Keep-Alive

Keep-Alive功能使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對(duì)服務(wù)器的后繼請(qǐng)求時(shí)，Keep-Alive功能避免了建立或者重新建立連接。市場(chǎng)上的大部分Web服務(wù)器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對(duì)于提供靜態(tài)內(nèi)容的網(wǎng)站來(lái)說(shuō)，這個(gè)功能通常很有用。但是，對(duì)于負(fù)擔(dān)較重的網(wǎng)站來(lái)說(shuō)，這里存在另外一個(gè)問(wèn)題：雖然為客戶保留打開(kāi)的連接有一定的好處，但它同樣影響了性能，因?yàn)樵谔幚頃和Ｆ陂g，本來(lái)可以釋放的資源仍舊被占用。當(dāng)Web服務(wù)器和應(yīng)用服務(wù)器在同一臺(tái)機(jī)器上運(yùn)行時(shí)，Keep- Alive功能對(duì)資源利用的影響尤其突出。

KeepAliveTime 值控制 TCP/IP 嘗試驗(yàn)證空閑連接是否完好的頻率。如果這段時(shí)間內(nèi)沒(méi)有活動(dòng)，則會(huì)發(fā)送保持活動(dòng)信號(hào)。如果網(wǎng)絡(luò)工作正常，而且接收方是活動(dòng)的，它就會(huì)響應(yīng)。如果需要對(duì)丟失接收方敏感，換句話說(shuō)，需要更快地發(fā)現(xiàn)丟失了接收方，請(qǐng)考慮減小這個(gè)值。如果長(zhǎng)期不活動(dòng)的空閑連接出現(xiàn)次數(shù)較多，而丟失接收方的情況出現(xiàn)較少，您可能會(huì)要提高該值以減少開(kāi)銷。缺省情況下，如果空閑連接 7200000 毫秒（2 小時(shí)）內(nèi)沒(méi)有活動(dòng)，Windows 就發(fā)送保持活動(dòng)的消息。通常，1800000 毫秒是首選值，從而一半的已關(guān)閉連接會(huì)在 30 分鐘內(nèi)被檢測(cè)到。

KeepAliveInterval 值定義了如果未從接收方收到保持活動(dòng)消息的響應(yīng)，TCP/IP 重復(fù)發(fā)送保持活動(dòng)信號(hào)的頻率。當(dāng)連續(xù)發(fā)送保持活動(dòng)信號(hào)、但未收到響應(yīng)的次數(shù)超出 TcpMaxDataRetransmissions 的值時(shí)，會(huì)放棄該連接。如果期望較長(zhǎng)的響應(yīng)時(shí)間，您可能需要提高該值以減少開(kāi)銷。如果需要減少花在驗(yàn)證接收方是否已丟失上的時(shí)間，請(qǐng)考慮減小該值或

TcpMaxDataRetransmissions 值。缺省情況下，在未收到響應(yīng)而重新發(fā)送保持活動(dòng)的消息之前，Windows 會(huì)等待 1000 毫秒（1 秒）。 KeepAliveTime 根據(jù)你的需要設(shè)置就行，比如10分鐘，注意要轉(zhuǎn)換成MS。 XXX代表這個(gè)間隔值得大小。

Date頭域

Date頭域表示消息發(fā)送的時(shí)間，時(shí)間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時(shí)間表示世界標(biāo)準(zhǔn)時(shí)，換算成本地時(shí)間，需要知道用戶所在的時(shí)區(qū)。

Pragma頭域

Pragma頭域用來(lái)包含實(shí)現(xiàn)特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協(xié)議中，它的含義和Cache-Control:no-cache相同。

請(qǐng)求消息

請(qǐng)求消息的第一行為下面的格式： 　
　
MethodSPRequest-URISPHTTP-VersionCRLFMethod

表示對(duì)于Request-URI完成的方法，這個(gè)字段是大小寫(xiě)敏感的，包括

OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。

方法GET和HEAD應(yīng)該被所有的通用WEB服務(wù)器支持，其他所有方法的實(shí)現(xiàn)是可選的。GET方法取回由Request-URI標(biāo)識(shí)的信息。

HEAD方法也是取回由Request-URI標(biāo)識(shí)的信息，只是可以在響應(yīng)時(shí)，不返回消息體。POST方法可以請(qǐng)求服務(wù)器接收包含在請(qǐng)求中的實(shí)體信息，可以用于提交

表單，

向新聞組、BBS、郵件群組和數(shù)據(jù)庫(kù)發(fā)送消息。

SP表示空格。Request-URI遵循URI格式，在此字段為星號(hào)（*）時(shí)，說(shuō)明請(qǐng)求并不用于某個(gè)特定的資源地址，而是用于服務(wù)器本身。HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。

CRLF表示換行回車符。請(qǐng)求頭域允許客戶端向服務(wù)器傳遞關(guān)于請(qǐng)求或者關(guān)于客戶機(jī)的附加信 息。請(qǐng)求頭域可能包含下列字段

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。

對(duì)請(qǐng)求頭域的擴(kuò)展要求通訊雙方都支持，如果存在不支持的請(qǐng)求頭域，一般將會(huì)作為實(shí)體頭域處理。

典型的請(qǐng)求消息：

Host: download.*******.de 　　
Accept: */* 　　Pragma: no-cache 　　
Cache-Control: no-cache 　　
User-Agent: Mozilla/4.04[en](Win95;I;Nav) 　　
Range: bytes=554554- 　　

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

Host頭域

Host頭域指定請(qǐng)求資源的Intenet主機(jī)和端口號(hào)，必須表示請(qǐng)求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請(qǐng)求必須包含主機(jī)頭域，否則系統(tǒng)會(huì)以400狀態(tài)碼返回。

Referer頭域

Referer頭域允許客戶端指定請(qǐng)求uri的源資源地址，這可以允許服務(wù)器生成回退鏈表，可用來(lái)登陸、優(yōu)化cache等。他也允許廢除的或錯(cuò)誤的連接由于維護(hù)的目的被追蹤。如果請(qǐng)求的uri沒(méi)有自己的uri地址，Referer不能被發(fā)送。如果指定的是部分uri地址，則此地址應(yīng)該是一個(gè)相對(duì)地址。

Range頭域

Range頭域可以請(qǐng)求實(shí)體的一個(gè)或者多個(gè)子范圍。例如， 　　表示頭500個(gè)字節(jié)：bytes=0-499 　　表示第二個(gè)500字節(jié)：bytes=500-999 　　表示最后500個(gè)字節(jié)：bytes=-500 　　表示500字節(jié)以后的范圍：bytes=500- 　　第一個(gè)和最后一個(gè)字節(jié)：bytes=0-0,-1 　　同時(shí)指定幾個(gè)范圍：bytes=500-600,601-999 　　但是服務(wù)器可以忽略此請(qǐng)求頭，如果無(wú)條件GET包含Range請(qǐng)求頭，響應(yīng)會(huì)以狀態(tài)碼206（PartialContent）返回而不是以200（OK）。

User-Agent頭域

User-Agent頭域的內(nèi)容包含發(fā)出請(qǐng)求的用戶信息。

響應(yīng)消息
　　響應(yīng)消息的第一行為下面的格式： 　　
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF 　　
HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。Status-Code是一個(gè)三個(gè)數(shù)字的結(jié)果代碼。Reason-Phrase給Status-Code提供一個(gè)簡(jiǎn)單的文本描述。Status-Code主要用于機(jī)器自動(dòng)識(shí)別，Reason-Phrase主要用于幫助用戶理解。Status-Code的第一個(gè)數(shù)字定義響應(yīng)的類別，后兩個(gè)數(shù)字沒(méi)有分類的作用。第一個(gè)數(shù)字可能取5個(gè)不同的值：

1xx:信息響應(yīng)類，表示接收到請(qǐng)求并且繼續(xù)處理

2xx:處理成功響應(yīng)類，表示動(dòng)作被成功接收、理解和接受

3xx:重定向響應(yīng)類，為了完成指定的動(dòng)作，必須接受進(jìn)一步處理

4xx:客戶端錯(cuò)誤，客戶請(qǐng)求包含語(yǔ)法錯(cuò)誤或者是不能正確執(zhí)行

5xx:服務(wù)端錯(cuò)誤，服務(wù)器不能正確執(zhí)行一個(gè)正確的請(qǐng)求 　　響應(yīng)頭域允許服務(wù)器傳遞不能放在狀態(tài)行的附加信息，這些域主要描述服務(wù)器的信息和Request-URI進(jìn)一步的信息。響應(yīng)頭域包含

Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。

對(duì)響應(yīng)頭域的擴(kuò)展要求通訊雙方都支持，如果存在不支持的響應(yīng)頭域，一般將會(huì)作為實(shí)體頭域處理。

典型的響應(yīng)消息：
　　
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服務(wù)端響應(yīng)一個(gè)GET方法。棕色的部分表示響應(yīng)頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實(shí)體頭域的信息。 　　
Location響應(yīng)頭

Location響應(yīng)頭用于重定向接收者到一個(gè)新URI地址。
　　
Server響應(yīng)頭

Server響應(yīng)頭包含處理請(qǐng)求的原始服務(wù)器的軟件信息。此域能包含多個(gè)產(chǎn)品標(biāo)識(shí)和注釋，產(chǎn)品標(biāo)識(shí)一般按照重要性排序。

HTTP-運(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)之間通過(guò)一個(gè)單獨(dú)的連接來(lái)完成。

當(dāng)一個(gè)或多個(gè)中介出現(xiàn)在請(qǐng)求／響應(yīng)鏈中時(shí)，情況就變得復(fù)雜一些。中介由三種：代理(Proxy)、網(wǎng)關(guān)(Gateway)和通道(Tunnel)。

一個(gè)代理根據(jù)URI的絕對(duì)格式來(lái)接受請(qǐng)求，重寫(xiě)全部或部分消息，通過(guò)URI的標(biāo)識(shí)把已格式化過(guò)的請(qǐng)求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個(gè)接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請(qǐng)求翻譯給下層的服務(wù)器協(xié)議。一個(gè)通道作為不改變消息的兩個(gè)連接之間的中繼點(diǎn)。當(dāng)通訊需要通過(guò)一個(gè)中介(例如：防火墻等)或者是中介不能識(shí)別消息的內(nèi)容時(shí)，通道經(jīng)常被使用.

實(shí)體
　　請(qǐng)求消息和響應(yīng)消息都可以包含實(shí)體信息，實(shí)體信息一般由實(shí)體頭域和實(shí)體組成。實(shí)體頭域包含關(guān)于實(shí)體的原信息，實(shí)體頭包括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允許客戶端定義新的實(shí)體頭，但是這些域可能無(wú)法被接受方識(shí)別。實(shí)體可以是一個(gè)經(jīng)過(guò)編碼的字節(jié)流，它的編碼方式由Content-Encoding或Content-Type定義，它的長(zhǎng)度由Content-Length或Content-Range定義。

Content-Type實(shí)體頭

Content-Type實(shí)體頭用于向接收方指示實(shí)體的介質(zhì)類型，指定HEAD方法送到接收方的實(shí)體介質(zhì)類型，或GET方法發(fā)送的請(qǐng)求介質(zhì)類型Content-Range實(shí)體頭

Content-Range實(shí)體頭用于指定整個(gè)實(shí)體中的一部分的插入位置，他也指示了整個(gè)實(shí)體的長(zhǎng)度。在服務(wù)器向客戶返回一個(gè)部分響應(yīng)，它必須描述響應(yīng)覆蓋的范圍和整個(gè)實(shí)體長(zhǎng)度。一般格式：

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

例如，傳送頭500個(gè)字節(jié)次字段的形式：Content-Range:bytes0-499/1234如果一個(gè)http消息包含此節(jié)（例如，對(duì)范圍請(qǐng)求的響應(yīng)或?qū)σ幌盗蟹秶闹丿B請(qǐng)求），Content-Range表示傳送的范圍，Content-Length表示實(shí)際傳送的字節(jié)數(shù)。

Last-modified實(shí)體頭

Last-modified實(shí)體頭指定服務(wù)器上保存內(nèi)容的最后修訂時(shí)間。

例如，傳送頭500個(gè)字節(jié)次字段的形式：Content-Range:bytes0-499/1234如果一個(gè)http消息包含此節(jié)（例如，對(duì)范圍請(qǐng)求的響應(yīng)或?qū)σ幌盗蟹秶闹丿B請(qǐng)求），Content-Range表示傳送的范圍，Content-Length表示實(shí)際傳送的字節(jié)數(shù)。

Last-modified實(shí)體頭

9 協(xié)議結(jié)構(gòu)

**編輯
　　HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求和從服務(wù)器到客戶機(jī)的響應(yīng)構(gòu)成。請(qǐng)求報(bào)文格式如下：

請(qǐng)求行 － 通用信息頭 － 請(qǐng)求頭 － 實(shí)體頭 － 報(bào)文主體

請(qǐng)求行以方法字段開(kāi)始，后面分別是 URL 字段和 HTTP 協(xié)議版本字段，并以 CRLF 結(jié)尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關(guān)通用信息頭，請(qǐng)求頭和實(shí)體頭方面的具體內(nèi)容可以參照相關(guān)文件。

應(yīng)答報(bào)文格式如下：

狀態(tài)行 － 通用信息頭 － 響應(yīng)頭 － 實(shí)體頭 － 報(bào)文主體

狀態(tài)碼元由3位數(shù)字組成，表示請(qǐng)求是否被理解或被滿足。原因分析是對(duì)原文的狀態(tài)碼作簡(jiǎn)短的描述，狀態(tài)碼用來(lái)支持自動(dòng)操作，而原因分析用來(lái)供用戶使用。客戶機(jī)無(wú)需用來(lái)檢查或顯示語(yǔ)法。有關(guān)通用信息頭，響應(yīng)頭和實(shí)體頭方面的具體內(nèi)容可以參照相關(guān)文件。

10 工作原理

**編輯
　　既然我們明白了URL的構(gòu)成，那么HTTP是怎么工作呢？我們接下來(lái)就要討論這個(gè)問(wèn)題。

一次HTTP操作稱為一個(gè)事務(wù)，其工作過(guò)程可分為四步：

首先客戶機(jī)與服務(wù)器需要建立連接。只要單擊某個(gè)超級(jí)鏈接，HTTP的工作就開(kāi)始了。

建立連接后，客戶機(jī)發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符（URL）、協(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)容。

客戶端接收服務(wù)器所返回的信息通過(guò)瀏覽器顯示在用戶的顯示屏上，然后客 戶機(jī)與服務(wù)器斷開(kāi)連接。

如果在以上過(guò)程中的某一步出現(xiàn)錯(cuò)誤，那么產(chǎn)生錯(cuò)誤的信息將返回到客戶端，由顯示屏輸出。對(duì)于用戶來(lái)說(shuō)，這些過(guò)程是由HTTP自己完成的，用戶只要用鼠標(biāo)點(diǎn)擊，等待信息顯示就可以了。

許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請(qǐng)?jiān)谠捶?wù)器上資源的請(qǐng)求。最簡(jiǎn)單的情況可能是在用戶代理和服務(wù)器之間通過(guò)一個(gè)單獨(dú)的連接來(lái)完成。在Internet上，HTTP通訊通常發(fā)生在TCP/IP連接之上。缺省端口是TCP 80，但其它的端口也是可用的。但這并不預(yù)示著HTTP協(xié)議在Internet或其它網(wǎng)絡(luò)的其它協(xié)議之上才能完成。HTTP只預(yù)示著一個(gè)可靠的傳輸。

這個(gè)過(guò)程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什么規(guī)格的商品，然后商家再告訴我們什么商品有貨，什么商品缺貨。這些，我們是通過(guò)電話線用電話聯(lián)系（HTTP是通過(guò)TCP/IP），當(dāng)然我們也可以通過(guò)傳真，只要商家那邊也有傳真。

以上簡(jiǎn)要介紹了HTTP協(xié)議的宏觀運(yùn)作方式，下面介紹一下HTTP協(xié)議的內(nèi)部操作過(guò)程。

在WWW中，“客戶”與“服務(wù)器”是一個(gè)相對(duì)的概念，只存在于一個(gè)特定的連接期間，即在某個(gè)連接中的客戶在另一個(gè)連接中可能作為服務(wù)器。基于HTTP協(xié)議的客戶/服務(wù)器模式的信息交換過(guò)程，它分四個(gè)過(guò)程：建立連接、發(fā)送請(qǐng)求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。這就好像上面的例子，我們電話訂貨的全過(guò)程。

其實(shí)簡(jiǎn)單說(shuō)就是任何服務(wù)器除了包括HTML文件以外，還有一個(gè)HTTP駐留程序，用于響應(yīng)用戶請(qǐng)求。你的瀏覽器是HTTP客戶，向服務(wù)器發(fā)送請(qǐng)求，當(dāng)瀏覽器中輸入了一個(gè)開(kāi)始文件或點(diǎn)擊了一個(gè)超級(jí)鏈接時(shí)，瀏覽器就向服務(wù)器發(fā)送了HTTP請(qǐng)求，此請(qǐng)求被送往由IP地址指定的URL。

駐留程序接收到請(qǐng)求，在進(jìn)行必要的操作后回送所要求的文件。在這一過(guò)程中，在網(wǎng)絡(luò)上發(fā)送和接收的數(shù)據(jù)已經(jīng)被分成一個(gè)或多個(gè)數(shù)據(jù)包（packet），每個(gè)數(shù)據(jù)包包括：要傳送的數(shù)據(jù)；控制信息，即告訴網(wǎng)絡(luò)怎樣處理數(shù)據(jù)包。TCP/IP決定了每個(gè)數(shù)據(jù)包的格式。如果事先不告訴你，你可能不會(huì)知道信息被分成用于傳輸和再重新組合起來(lái)的許多小塊。

也就是說(shuō)商家除了擁有商品之外，它也有一個(gè)職員在接聽(tīng)你的電話，當(dāng)你打電話的時(shí)候，你的聲音轉(zhuǎn)換成各種復(fù)雜的數(shù)據(jù)，通過(guò)電話線傳輸?shù)綄?duì)方的電話機(jī)，對(duì)方的電話機(jī)又把各種復(fù)雜的數(shù)據(jù)轉(zhuǎn)換成聲音，使得對(duì)方商家的職員能夠明白你的請(qǐng)求。這個(gè)過(guò)程你不需要明白聲音是怎么轉(zhuǎn)換成復(fù)雜的數(shù)據(jù)的。

11、狀態(tài)消息

**編輯

1xx:信息

100 Continue

服務(wù)器僅接收到部分請(qǐng)求，但是一旦服務(wù)器并沒(méi)有拒絕該請(qǐng)求，客戶端應(yīng)該繼續(xù)發(fā)送其余的請(qǐng)求。

101 Switching Protocols

服務(wù)器轉(zhuǎn)換協(xié)議：服務(wù)器將遵從客戶的請(qǐng)求轉(zhuǎn)換到另外一種協(xié)議。

2xx:成功

消息:
描述:

200 OK

請(qǐng)求成功（其后是對(duì)GET和POST請(qǐng)求的應(yīng)答文檔。）

201 Created

請(qǐng)求被創(chuàng)建完成，同時(shí)新的資源被創(chuàng)建。

202 Accepted

供處理的請(qǐng)求已被接受，但是處理未完成。

203 Non-authoritative Information

文檔已經(jīng)正常地返回，但一些應(yīng)答頭可能不正確，因?yàn)槭褂玫氖俏臋n的拷貝。

204 No Content

沒(méi)有新文檔。瀏覽器應(yīng)該繼續(xù)顯示原來(lái)的文檔。如果用戶定期地刷新頁(yè)面，而Servlet可以確定用戶文檔足夠新，這個(gè)狀態(tài)代碼是很有用的。

5 Reset Content

沒(méi)有新文檔。但瀏覽器應(yīng)該重置它所顯示的內(nèi)容。用來(lái)強(qiáng)制瀏覽器清除表單輸入內(nèi)容。

06 Partial Content

客戶發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求，服務(wù)器完成了它。

3xx:重定向

300 Multiple Choices

多重選擇。鏈接列表。用戶可以選擇某鏈接到達(dá)目的地。最多允許五個(gè)地址。

301 Moved Permanently

所請(qǐng)求的頁(yè)面已經(jīng)轉(zhuǎn)移至新的url。

302 Found

所請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url。

303 See Other

所請(qǐng)求的頁(yè)面可在別的url下被找到。

304 Not Modified

未按預(yù)期修改文檔。客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用。

305 Use Proxy

客戶請(qǐng)求的文檔應(yīng)該通過(guò)Location頭所指明的代理服務(wù)器提取。

*306 Unused

此代碼被用于前一版本。目前已不再使用，但是代碼依然被保留。

307 Temporary Redirect

被請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)移至新的url。

4xx:客戶端錯(cuò)誤

400 Bad Request

服務(wù)器未能理解請(qǐng)求。

401 Unauthorized

被請(qǐng)求的頁(yè)面需要用戶名和密碼。

402 Payment Required

此代碼尚無(wú)法使用。

403 Forbidden

對(duì)被請(qǐng)求頁(yè)面的訪問(wèn)被禁止。

404 Not Found

服務(wù)器無(wú)法找到被請(qǐng)求的頁(yè)面。

405 Method Not Allowed

請(qǐng)求中指定的方法不被允許。

406 Not Acceptable

服務(wù)器生成的響應(yīng)無(wú)法被客戶端所接受。

407 Proxy Authentication Required

用戶必須首先使用代理服務(wù)器進(jìn)行驗(yàn)證，這樣請(qǐng)求才會(huì)被處理。

408 Request Timeout

請(qǐng)求超出了服務(wù)器的等待時(shí)間。

409 Conflict

由于沖突，請(qǐng)求無(wú)法被完成。

410 Gone

被請(qǐng)求的頁(yè)面不可用。

411 Length Required

"Content-Length" 未被定義。如果無(wú)此內(nèi)容，服務(wù)器不會(huì)接受請(qǐng)求。

412 Precondition Failed

請(qǐng)求中的前提條件被服務(wù)器評(píng)估為失敗。

413 Request Entity Too Large

由于所請(qǐng)求的實(shí)體的太大，服務(wù)器不會(huì)接受請(qǐng)求。

414 Request-url Too Long

由于url太長(zhǎng)，服務(wù)器不會(huì)接受請(qǐng)求。當(dāng)post請(qǐng)求被轉(zhuǎn)換為帶有很長(zhǎng)的查詢信息的get請(qǐng)求時(shí)，就會(huì)發(fā)生這種情況。

415 Unsupported Media Type

由于媒介類型不被支持，服務(wù)器不會(huì)接受請(qǐng)求。

416

服務(wù)器不能滿足客戶在請(qǐng)求中指定的Range頭。

417 Expectation Failed

** 5xx:服務(wù)器錯(cuò)誤**

500 Internal Server Error

請(qǐng)求未完成。服務(wù)器遇到不可預(yù)知的情況。

501 Not Implemented

請(qǐng)求未完成。服務(wù)器不支持所請(qǐng)求的功能。

502 Bad Gateway

請(qǐng)求未完成。服務(wù)器從上游服務(wù)器收到一個(gè)無(wú)效的響應(yīng)。

503 Service Unavailable

請(qǐng)求未完成。服務(wù)器臨時(shí)過(guò)載或當(dāng)機(jī)。

504 Gateway Timeout

網(wǎng)關(guān)超時(shí)。

505 HTTP Version Not Supported

服務(wù)器不支持請(qǐng)求中指明的HTTP協(xié)議版本。

12 版本歷史

協(xié)議版本

超文本傳輸協(xié)議已經(jīng)演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP 版本號(hào)的用法。客戶端在請(qǐng)求的開(kāi)始告訴服務(wù)器它采用的協(xié)議版本號(hào)，而后者則在響應(yīng)中采用相同或者更早的協(xié)議版本。

0.9

已過(guò)時(shí)。只接受 GET 一種請(qǐng)求方法，沒(méi)有在通訊中指定版本號(hào)，且不支持請(qǐng)求頭。由于該版本不支持 POST 方法，所以客戶端無(wú)法向服務(wù)器傳遞太多信息。

HTTP/1.0

這是第一個(gè)在通訊中指定版本號(hào)的HTTP 協(xié)議版本，至今仍被廣泛采用，特別是在代理服務(wù)器中。

HTTP/1.1

當(dāng)前版本。持久連接被默認(rèn)采用，并能很好地配合代理服務(wù)器工作。還支持以管道方式在同時(shí)發(fā)送多個(gè)請(qǐng)求，以便降低線路負(fù)載，提高傳輸速度。
　　
HTTP/1.1相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在：
　　
1 緩存處理

2 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用

3 錯(cuò)誤通知的管理

4 消息在網(wǎng)絡(luò)中的發(fā)送

5 互聯(lián)網(wǎng)地址的維護(hù)

6 安全性及完整性 詞條圖冊(cè)更多圖冊(cè)

1、網(wǎng)絡(luò)傳送帶(影音傳送帶)

2、Configuring the HTTP Listener

13 安全超文本傳輸協(xié)議

安全超文本傳輸協(xié)議（Secure Hypertext Transfer Protocol, S-HTTP）是一種結(jié)合HTTP而設(shè)計(jì)的消息的安全通信協(xié)議。S-HTTP協(xié)議為HTTP客戶機(jī)和服務(wù)器提供了多種安全機(jī)制，這些安全服務(wù)選項(xiàng)是適用于Web上各類用戶的。還為客戶機(jī)和服務(wù)器提供了對(duì)稱能力（及時(shí)處理請(qǐng)求和恢復(fù)，及兩者的參數(shù)選擇）同時(shí)維持HTTP的通信模型和實(shí)施特征。

S-HTTP不需要客戶方的公用密鑰證明，但它支持對(duì)稱密鑰的操作模式。這意味著在沒(méi)有要求用戶個(gè)人建立公用密鑰的情況下，會(huì)自發(fā)地發(fā)生私人交易。它支持端對(duì)端安全傳輸，客戶機(jī)可能首先啟動(dòng)安全傳輸（使用報(bào)頭的信息），用來(lái)支持加密技術(shù)。

在語(yǔ)法上，S-HTTP報(bào)文與HTTP相同，由請(qǐng)求行或狀態(tài)行組成，后面是信頭和主體。請(qǐng)求報(bào)文的格式由請(qǐng)求行、通用信息頭、請(qǐng)求頭、實(shí)體頭、信息主體組成。相應(yīng)報(bào)文由響應(yīng)行、通用信息頭、響應(yīng)頭、實(shí)體頭、信息主體組成。

目前有兩種方法來(lái)建立連接：HTTPS URI方案和HTTP 1.1請(qǐng)求頭（由RFC2817引入）。由于瀏覽器對(duì)后者的幾乎沒(méi)有任何支持，因此HTTPS URI方案仍是建立安全超文本協(xié)議連接的主要手段。