超文字傳輸協議-HTTP(HTTP，HyperText Transfer Protocol)是因特網上應用最為廣泛的一種網路協議。所有的WWW檔案都必須遵守這個標準。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。 

HTTP概述

　　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客戶端發起一個請求，建立一個到伺服器指定埠（預設是80埠）的TCP連線。HTTP伺服器則在那個埠監聽客戶端傳送過來的請求。一旦收到請求，伺服器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（響應的）訊息，訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些資訊。 

HTTP使用TCP而不是UDP的原因在於（開啟一個）一個網頁必須傳送很多資料，而TCP協議提供傳輸控制，按順序組織資料，和錯誤糾正。具體細節請參考‘TCP和UDP的不同’通過HTTP或者HTTPS協議請求的資源由統一資源定位器（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。 

HTTP請求資訊（Request Message） 

發出的請求資訊包括以下幾個 

HTTP請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images 目錄下請求logo.gif 這個檔案。 
（請求）頭，例如Accept-Language: en 
空行 
可選的訊息體 
請求行和標題必須以<CR><LF> 作為結尾（也就是，回車然後換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的。 

HTTP請求方法（Request Methods） 

HTTP協議中定義了八種方法（有時也叫“動作”）來表示對指定資料的操作。

HEAD

 

（Head方法）要求響應與相應的GET請求的響應一樣，但是沒有的響應體（response body）。這用來獲得響應頭（response header）中的 
元資料資訊（meta-infomation）有（很）幫助，（因為）它不需要傳輸所有的內容。

GET 

（Get方法用來）請求指定的資源。它是目前網上最常用的方法。它不應該用於一些會造成副作用的操作中 
（在網路應用中用它來提交動作是一種常見的錯誤用法）。（細節請）參考後面的“安全方法”（這一節）。

POST 

（POST方法用來）向指定的資源提交需要處理的資料。這些資料寫在請求的內容裡。（POST請求）可以導致新資源的產生和已有資源的更新。

PUT 

上傳指定資源

DELETE 

刪除指定資源

TRACE 

（Trace方法告訴伺服器端）返回收到的請求。客戶端可以（通過此方法）察看在請求過程中中間伺服器新增或者改變哪些內容。

OPTIONS 

返回伺服器（在指定URL上）支援的HTTP方法。通過請求“*”而不是指定的資源，這個方法可以用來檢查網路伺服器的功能。

CONNECT 

將請求的連線轉換成透明的TCP/IP通道，通常用來簡化通過非加密的HTTP代理的SSL-加密通訊（HTTPS）。 
HTTP伺服器至少應該實現Get和Head方法，可能的話，也實現OPTIONS方法。 

HTTP安全方法 

　　有些方法（比如HEAD, GET, OPTIONS, and TRACE) 被定義為安全方法，這些方法針對的只是資訊的返回，並不會改變伺服器的狀態（換句話說就是這些方法不會產生副作用）。不安全的方法（例如POST, PUT and DELETE) 應該用特殊的方式向用戶展示，通常是按鈕而不是連結，這樣就可以使使用者意識到可能要負的責任（例如一個按鈕帶來的資金交易。） 

HTTP協議版本號 

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


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


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


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

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

HTTP快取處理 

頻寬及網路連線的管理 
安全性及完整性

HTTP狀態行 

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

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

1xx 訊息——請求已被伺服器接收，繼續處理 
2xx 成功——請求已成功被伺服器接收、理解、並接受 
3xx 重定向——需要後續操作才能完成這一請求 
4xx 請求錯誤——請求含有詞法錯誤或者無法被執行 
5xx 伺服器錯誤——伺服器在處理某個正確請求時發生錯誤 
雖然 RFC 2616 中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，但是 WEB 開發者仍然能夠自行決定採用何種短語，用以顯示本地化的狀態描述或者自定義資訊。 

例子 
下面是一個HTTP客戶端與伺服器之間會話的例子，運行於www.cnpaf.net，埠80 

客戶端請求： 

GET / HTTP/1.1 
Host：www.google.com 
（緊跟著一個換行，通過敲入回車實現） 

伺服器應答：

HTTP/1.1 200 OK
Content-Length: 61655
Content-Type: text/html
Content-Location: http://www.cnpaf.net/index.htm
Last-Modified: Thu, 23 Oct 2008 01:51:26 GMT
Accept-Ranges: bytes
ETag: "70e053dcb134c91:3554"
Server: Microsoft-IIS/6.0
Date: Thu, 23 Oct 2008 01:59:25 GMT
Connection: close
Connection: keep-alive 
（緊跟著一個空行，並且由HTML格式的文字組成了中國協議分析網的主頁） 

　　在HTTP1.0中，客戶端傳送一個請求至伺服器，伺服器傳送一個應答至客戶端。之後，連線將被釋放。另一方面，HTTP1.1支援持久連線。這使得客戶端可以傳送請求並且接收應答，然後迅速的傳送另一個請求和接收另一個應答。因為多個額外的請求，TCP連線並沒有被釋放，而每個請求中關於TCP的負載相對較少。同時，在得到上一個請求的應答之前傳送多個請求（通常是兩個）也成為可能。這個技術被稱為“流水線”。