http相關的整理

HTTP概述

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

是互聯網上應用最爲廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。

HTTP的發展是萬維網協會（World Wide Web Consortium）和Internet工作小組（Internet Engineering Task Force）合作的結果，（他們）最終發佈了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協議的我們今天普遍使用的一個版本——HTTP 1.1。

HTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口爲80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。

應答的服務器上存儲着（一些）資源，比如HTML文件和圖像。（我們稱）這個應答服務器爲源服務器（origin server）。在用戶代理和源服務器中間可能存在多箇中間層，比如代理，網關，或者隧道（tunnels）。儘管TCP/IP協議是互聯網上最流行的應用，HTTP協議並沒有規定必須使用它和（基於）它支持的層。事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。

HTTP使用TCP而不是UDP的原因在於（打開一個）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。具體細節請參考‘TCP和UDP的不同’。

通過HTTP或者HTTPS協議請求的資源由統一資源定位器（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。

2、請求信息Request Message

發出的請求信息包括以下幾個

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

空行

可選的消息體

請求行和標題必須以<CR><LF> 作爲結尾（也就是，回車然後換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的。

3、請求方法

HTTP/1.1協議中共定義了八種方法（有時也叫“動作”）來表明Request-URI指定的資源的不同操作方式：

OPTIONS

返回服務器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務器發送'*'的請求來測試服務器的功能性。

HEAD

向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。

GET

向特定的資源發出請求。注意：GET方法不應當被用於產生“副作用”的操作中，例如在Web Application中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。參見安全方法

POST

向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。

PUT

向指定資源位置上傳其最新內容。

DELETE

刪除指定資源。

TRACE

回顯服務器收到的請求。

CONNECT

HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。

方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405(Method Not Allowed)；當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501(Not Implemented)。

HTTP服務器至少應該實現GET和HEAD方法，其他方法都是可選的。當然，所有的方法支持的實現都應當符合下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP服務器還能夠擴展自定義的方法。安全及冪等方法

安全方法

開發者應當意識到他們的軟件代表了用戶在因特網上進行交互，並且應當告知用戶，他們正在進行的操作可能對他們自身或者其他人有未曾預料的重要影響。

特別地，對於GET和HEAD方法而言，除了進行獲取資源信息外，這些請求不應當再有任何其他意義。也就是說，這些方法應當被認爲是“安全的”。客戶端應當使用其他“非安全”方法，例如POST，PUT及DELETE來以特殊的方式（通常是按鈕而不是超鏈接）使得客戶能夠意識到可能要負的責任（例如一個按鈕帶來的資金交易）或者被告知正在請求的操作可能是不安全的（例如某個文件將被上傳或刪除）。

但是，不能想當然地認爲服務器不會在處理某個GET請求時不會產生任何副作用。事實上，很多動態資源會把這作爲其特性。這裏重要的區別在於用戶並沒有請求這一副作用，因此不應由用戶爲這些副作用承擔責任。

冪等方法

假如在不考慮諸如錯誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那麼這些請求方法就能夠被視作“冪等”的。GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由於根據協議，OPTIONS，TRACE都不應有副作用，因此也理所當然也是冪等的。

假如某個由若干個請求做成的請求序列產生的結果在重複執行這個請求序列或者其中任何一個或多個請求後仍沒有發生變化，則這個請求序列便是“冪等”的。但是，可能出現若干個請求做成的請求序列是“非冪等”的，即使這個請求序列中所有執行的請求方法都是冪等的。例如，這個請求序列的結果依賴於某個會在下次執行這個序列的過程中被修改的變量。

4、協議版本號

超文本傳輸協議已經演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本號的用法。客戶端在請求的開始告訴服務器它採用的協議版本號，而後者則在響應中採用相同或者更早的協議版本。 0.9

已過時。只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由於該版本不支持 POST 方法，所以客戶端無法向服務器傳遞太多信息。

HTTP/1.0

這是第一個在通訊中指定版本號的 HTTP 協議版本，至今仍被廣泛採用，特別是在代理服務器中。

HTTP/1.1

當前版本。持久連接被默認採用，並能很好地配合代理服務器工作。還支持以管道方式在同時發送多個請求，以便降低線路負載，提高傳輸速度。

HTTP/1.1相較於 HTTP/1.0 協議的區別主要體現在：

緩存處理

帶寬優化及網絡連接的使用

錯誤通知的管理

消息在網絡中的發送

互聯網地址的維護

安全性及完整性

5、狀態行

參見：HTTP狀態碼

所有 HTTP 響應的第一行都是狀態行, 依次是當前 HTTP 版本號，3位數字組成的狀態代碼，以及描述狀態的短語，彼此由空格分隔。

狀態代碼的第一個數字代表當前響應的類型：

1xx 消息——請求已被服務器接收，繼續處理

2xx 成功——請求已成功被服務器接收、理解、並接受

3xx 重定向——需要後續操作才能完成這一請求

4xx 請求錯誤——請求含有詞法錯誤或者無法被執行

5xx 服務器錯誤——服務器在處理某個正確請求時發生錯誤

雖然 RFC 2616 中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，但是 WEB 開發者仍然能夠自行決定採用何種短語，用以顯示本地化的狀態描述或者自定義信息。

HTTP是什麼?

　　當我們想瀏覽一個網站的時候，只要在瀏覽器的地址欄裏輸入網站的地址就可以了，例如www.baidu.com,但是在瀏覽器的地址欄裏面出現的卻是：http://www.baidu.com ,你知道爲什麼會多出一個“http”嗎？

　　我們在瀏覽器的地址欄裏輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。因此，在我們認識HTTP之前，有必要先弄清楚URL的組成,例如：http://www.baidu.com/china/index.htm。它的含義如下：

　　1. http://：代表超文本傳輸協議，通知baidu.com服務器顯示Web頁，通常不用輸入；

　　2. www：代表一個Web（萬維網）服務器；

　　3. baidu.com/：這是裝有網頁的服務器的域名，或站點服務器的名稱；

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

　　5. Index.htm：index.htm是文件夾中的一個HTML文件（網頁）。

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

　　HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。這就是你爲什麼在瀏覽器中看到的網頁地址都是以http://開頭的原因。

　　自WWW誕生以來，一個多姿多彩的資訊和虛擬的世界便出現在我們眼前，可是我們怎麼能夠更加容易地找到我們需要的資訊呢？當決定使用超文本作爲WWW文檔的標準格式後，於是在1990年，科學家們立即制定了能夠快速查找這些超文本文檔的協議，即HTTP協議。經過幾年的使用與發展，得到不斷的完善和擴展，目前在WWW中使用的是HTTP/1.0的第六版。

http 百科名片

超文本傳輸協議(HTTP，HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。

目錄

簡介

協議功能

協議基礎

通用頭域

Cache-Control頭域

HTTP Keep-Alive

Date頭域

Pragma頭域

請求消息

Host頭域

Referer頭域

Range頭域

User-Agent頭域

響應消息

HTTP-運作方式

實體

Content-Type實體頭

Last-modified實體頭

協議結構

工作原理

狀態消息

1xx:信息

2xx:成功

3xx:重定向

4xx:客戶端錯誤

5xx:服務器錯誤

版本歷史

協議版本0.9、HTTP/1.0、HTTP/1.1

簡介

協議功能、協議基礎、通用頭域、Cache-Control頭域

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

請求消息

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

響應消息

HTTP-運作方式、實體、Content-Type實體頭、Last-modified實體頭、協議結構、工作原理

狀態消息

1xx:信息

2xx:成功

3xx:重定向

4xx:客戶端錯誤

5xx:服務器錯誤

版本歷史

協議版本0.9、HTTP/1.0、HTTP/1.1

6、簡介

HTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口爲80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。應答的服務器上存儲着（一些）資源，比如HTML文件和圖像。（我們稱）這個應答服務器爲源服務器（origin server）。

在用戶代理和源服務器中間可能存在多箇中間層，比如代理，網關，或者隧道（tunnels）。儘管TCP/IP協議是互聯網上最流行的應用，HTTP協議並沒有規定必須使用它和（基於）它支持的層。事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。　　

通常，由HTTP客戶端發起一個請求，建立一個到服務器指定端口（默認是80端口）的TCP連接。HTTP服務器則在那個端口監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。 HTTP使用TCP而不是UDP的原因在於（打開一個）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。　　

通過HTTP或者HTTPS協議請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。

7、協議功能

HTTP是超文本傳輸協議，是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機需要通過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不僅可用於Web訪問，也可以用於其他因特網/內聯網應用系統之間的通信，從而實現各類應用資源超媒體訪問的集成。　　

當我們想瀏覽一個網站的時候，只要在瀏覽器的地址欄裏輸入網站的地址就可以了，例如www.*.com,但是在瀏覽器的地址欄裏面出現的卻是：http://www.*******,你知道爲什麼會多出一個“http”嗎？　　

我們在瀏覽器的地址欄裏輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本轉移協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。因此，在我們認識HTTP之前，有必要先弄清楚URL的組成, 例如：

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

它的含義如下：　　

http://：代表超文本轉移協議，通知****.com服務器顯示Web頁，通常不用輸入；　　
www：代表一個Web（萬維網）服務器；　　
**.com/：這是裝有網頁的服務器的域名，或站點服務器的名稱；　　
China/：爲該服務器上的子目錄，就好像我們的文件夾；　　
Index.htm：index.htm是文件夾中的一個HTML文件（網頁）。

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

HTTP協議（HyperText Transfer Protocol，超文本轉移協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先於圖形)等。這就是你爲什麼在瀏覽器中看到的網頁地址都是以http://開頭的原因。

8、協議基礎

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

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

通用頭域

　　通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般將會作爲實體頭域處理。下面簡單介紹幾個在UPnP消息中使用的通用頭域。

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代表這個間隔值得大小。

Date頭域

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

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下的文件。棕色的部分表示請求頭域的信息，綠色的部分表示通用頭部分。

Host頭域

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

Referer頭域

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

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）。

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方法。棕色的部分表示響應頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的信息。　　 Location響應頭　　

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

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

HTTP-運作方式

　　HTTP協議是基於請求／響應範式的。一個客戶機與服務器建立連接後，發送一個請求給服務器，請求方式的格式爲，統一資源標識符、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼，

後邊是MIME信息包括服務器信息、實體信息和可能的內容。　　

許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源服務器(O)之間通過一個單獨的連接來完成。　　

當一個或多箇中介出現在請求／響應鏈中時，情況就變得複雜一些。中介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)。

一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作爲一些其它服務器的上層，並且如果必須的話，可以把請求翻譯給下層的服務器協議。一個通道作爲不改變消息的兩個連接之間的中繼點。當通訊需要通過一箇中介(例如：防火牆等)或者是中介不能識別消息的內容時，通道經常被使用.

實體　　請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關於實體的原信息，實體頭包括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定義。

Content-Type實體頭

　　Content-Type實體頭用於向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型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表示實際傳送的字節數。

Last-modified實體頭

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

Last-modified實體頭

9 協議結構

**編輯　　HTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應構成。請求報文格式如下：　　

請求行－通用信息頭－請求頭－實體頭－報文主體　　

請求行以方法字段開始，後面分別是 URL 字段和 HTTP 協議版本字段，並以 CRLF 結尾。SP 是分隔符。除了在最後的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關通用信息頭，請求頭和實體頭方面的具體內容可以參照相關文件。　　

應答報文格式如下：　　

狀態行－通用信息頭－響應頭－實體頭－報文主體　　

狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支持自動操作，而原因分析用來供用戶使用。客戶機無需用來檢查或顯示語法。有關通用信息頭，響應頭和實體頭方面的具體內容可以參照相關文件。

10 工作原理

**編輯　　既然我們明白了URL的構成，那麼HTTP是怎麼工作呢？我們接下來就要討論這個問題。　　

一次HTTP操作稱爲一個事務，其工作過程可分爲四步：　　

首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作就開始了。　　

建立連接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。　　

服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。　　

客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然後客戶機與服務器斷開連接。　　

如果在以上過程中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，由顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。　　

許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理和服務器之間通過一個單獨的連接來完成。在Internet上，HTTP通訊通常發生在TCP/IP連接之上。缺省端口是TCP 80，但其它的端口也是可用的。但這並不預示着HTTP協議在Internet或其它網絡的其它協議之上才能完成。HTTP只預示着一個可靠的傳輸。　　

這個過程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什麼規格的商品，然後商家再告訴我們什麼商品有貨，什麼商品缺貨。這些，我們是通過電話線用電話聯繫（HTTP是通過TCP/IP），當然我們也可以通過傳真，只要商家那邊也有傳真。　　

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

在WWW中，“客戶”與“服務器”是一個相對的概念，只存在於一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作爲服務器。基於HTTP協議的客戶/服務器模式的信息交換過程，它分四個過程：建立連接、發送請求信息、發送響應信息、關閉連接。這就好像上面的例子，我們電話訂貨的全過程。　　

其實簡單說就是任何服務器除了包括HTML文件以外，還有一個HTTP駐留程序，用於響應用戶請求。你的瀏覽器是HTTP客戶，向服務器發送請求，當瀏覽器中輸入了一個開始文件或點擊了一個超級鏈接時，瀏覽器就向服務器發送了HTTP請求，此請求被送往由IP地址指定的URL。

駐留程序接收到請求，在進行必要的操作後回送所要求的文件。在這一過程中，在網絡上發送和接收的數據已經被分成一個或多個數據包（packet），每個數據包包括：要傳送的數據；控制信息，即告訴網絡怎樣處理數據包。TCP/IP決定了每個數據包的格式。如果事先不告訴你，你可能不會知道信息被分成用於傳輸和再重新組合起來的許多小塊。　　

也就是說商家除了擁有商品之外，它也有一個職員在接聽你的電話，當你打電話的時候，你的聲音轉換成各種複雜的數據，通過電話線傳輸到對方的電話機，對方的電話機又把各種複雜的數據轉換成聲音，使得對方商家的職員能夠明白你的請求。這個過程你不需要明白聲音是怎麼轉換成複雜的數據的。

11、狀態消息

**編輯

1xx:信息

100 Continue

服務器僅接收到部分請求，但是一旦服務器並沒有拒絕該請求，客戶端應該繼續發送其餘的請求。

101 Switching Protocols

服務器轉換協議：服務器將遵從客戶的請求轉換到另外一種協議。

2xx:成功

消息: 描述:

200 OK

請求成功（其後是對GET和POST請求的應答文檔。）

201 Created

請求被創建完成，同時新的資源被創建。

202 Accepted

供處理的請求已被接受，但是處理未完成。

203 Non-authoritative Information

文檔已經正常地返回，但一些應答頭可能不正確，因爲使用的是文檔的拷貝。

204 No Content

沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。

5 Reset Content

沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。

06 Partial Content

客戶發送了一個帶有Range頭的GET請求，服務器完成了它。

3xx:重定向

300 Multiple Choices

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

301 Moved Permanently

所請求的頁面已經轉移至新的url。

302 Found

所請求的頁面已經臨時轉移至新的url。

303 See Other

所請求的頁面可在別的url下被找到。

304 Not Modified

未按預期修改文檔。客戶端有緩衝的文檔併發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還可以繼續使用。

305 Use Proxy

客戶請求的文檔應該通過Location頭所指明的代理服務器提取。

306 *Unused

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

307 Temporary Redirect

被請求的頁面已經臨時移至新的url。

4xx:客戶端錯誤

400 Bad Request

服務器未能理解請求。

401 Unauthorized

被請求的頁面需要用戶名和密碼。

402 Payment Required

此代碼尚無法使用。

403 Forbidden

對被請求頁面的訪問被禁止。

404 Not Found

服務器無法找到被請求的頁面。

405 Method Not Allowed

請求中指定的方法不被允許。

406 Not Acceptable

服務器生成的響應無法被客戶端所接受。

407 Proxy Authentication Required

用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。

408 Request Timeout

請求超出了服務器的等待時間。

409 Conflict

由於衝突，請求無法被完成。

410 Gone

被請求的頁面不可用。

411 Length Required

"Content-Length" 未被定義。如果無此內容，服務器不會接受請求。

412 Precondition Failed

請求中的前提條件被服務器評估爲失敗。

413 Request Entity Too Large

由於所請求的實體的太大，服務器不會接受請求。

414 Request-url Too Long

由於url太長，服務器不會接受請求。當post請求被轉換爲帶有很長的查詢信息的get請求時，就會發生這種情況。

415 Unsupported Media Type

由於媒介類型不被支持，服務器不會接受請求。

416

服務器不能滿足客戶在請求中指定的Range頭。

417 Expectation Failed

5xx:服務器錯誤

500 Internal Server Error

請求未完成。服務器遇到不可預知的情況。

501 Not Implemented

請求未完成。服務器不支持所請求的功能。

502 Bad Gateway

請求未完成。服務器從上游服務器收到一個無效的響應。

503 Service Unavailable

請求未完成。服務器臨時過載或當機。

504 Gateway Timeout

網關超時。

505 HTTP Version Not Supported

服務器不支持請求中指明的HTTP協議版本。

12 版本歷史

協議版本

　　超文本傳輸協議已經演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP 版本號的用法。客戶端在請求的開始告訴服務器它採用的協議版本號，而後者則在響應中採用相同或者更早的協議版本。

0.9

　　已過時。只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由於該版本不支持 POST 方法，所以客戶端無法向服務器傳遞太多信息。

HTTP/1.0

　　這是第一個在通訊中指定版本號的HTTP 協議版本，至今仍被廣泛採用，特別是在代理服務器中。

HTTP/1.1

　　當前版本。持久連接被默認採用，並能很好地配合代理服務器工作。還支持以管道方式在同時發送多個請求，以便降低線路負載，提高傳輸速度。　　 HTTP/1.1相較於 HTTP/1.0 協議的區別主要體現在：　　 1 緩存處理　　

2 帶寬優化及網絡連接的使用　　

3 錯誤通知的管理　　

4 消息在網絡中的發送　　

5 互聯網地址的維護　　

6 安全性及完整性詞條圖冊更多圖冊

1、網絡傳送帶(影音傳送帶)

2、Configuring the HTTP Listener

13 安全超文本傳輸協議

　　安全超文本傳輸協議（Secure Hypertext Transfer Protocol, S-HTTP）是一種結合HTTP而設計的消息的安全通信協議。S-HTTP協議爲HTTP客戶機和服務器提供了多種安全機制，這些安全服務選項是適用於Web上各類用戶的。還爲客戶機和服務器提供了對稱能力（及時處理請求和恢復，及兩者的參數選擇）同時維持HTTP的通信模型和實施特徵。

　　S-HTTP不需要客戶方的公用密鑰證明，但它支持對稱密鑰的操作模式。這意味着在沒有要求用戶個人建立公用密鑰的情況下，會自發地發生私人交易。它支持端對端安全傳輸，客戶機可能首先啓動安全傳輸（使用報頭的信息），用來支持加密技術。

　　在語法上，S-HTTP報文與HTTP相同，由請求行或狀態行組成，後面是信頭和主體。請求報文的格式由請求行、通用信息頭、請求頭、實體頭、信息主體組成。相應報文由響應行、通用信息頭、響應頭、實體頭、信息主體組成。　

　　目前有兩種方法來建立連接：HTTPS URI方案和HTTP 1.1請求頭（由RFC2817引入）。由於瀏覽器對後者的幾乎沒有任何支持，因此HTTPS URI方案仍是建立安全超文本協議連接的主要手段。

作者：caoyuan 鏈接：http://www.jianshu.com/p/6309efc8e9e9 來源：簡書著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。