超文本傳輸協(xié)議-HTTP(HTTP，HyperText Transfer Protocol)是因特網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個標準。設(shè)計HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。
HTTP概述
HTTP的發(fā)展是萬維網(wǎng)協(xié)會（World Wide Web Consortium）和Internet工作小組（Internet Engineering Task Force）合作的結(jié)果，（他們）最終發(fā)布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協(xié)議的我們今天普遍使用的一個版本——HTTP 1.1。
HTTP是一個客戶端和服務(wù)器端請求和應(yīng)答的標準（TCP）?？蛻舳耸墙K端用戶，服務(wù)器端是網(wǎng)站。通過使用Web瀏覽器、網(wǎng)絡(luò)爬蟲或者其它的工具，客戶端發(fā)起一個到服務(wù)器上指定端口（默認端口為80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。應(yīng)答的服務(wù)器上存儲著（一些）資源，比如HTML文件和圖像。（我們稱）這個應(yīng)答服務(wù)器為源服務(wù)器（origin server）。在用戶代理和源服務(wù)器中間可能存在多個中間層，比如代理，網(wǎng)關(guān)，或者隧道（tunnels）。盡管TCP/IP協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，HTTP協(xié)議并沒有規(guī)定必須使用它和（基于）它支持的層。 事實上，HTTP可以在任何其他互聯(lián)網(wǎng)協(xié)議上，或者在其他網(wǎng)絡(luò)上實現(xiàn)。HTTP只假定（其下層協(xié)議提供）可靠的傳輸，任何能夠提供這種保證的協(xié)議都可以被其使用。
通常，由HTTP客戶端發(fā)起一個請求，建立一個到服務(wù)器指定端口（默認是80端口）的TCP連接。HTTP服務(wù)器則在那個端口監(jiān)聽客戶端發(fā)送過來的請求。一旦收到請求，服務(wù)器（向客戶端）發(fā)回一個狀態(tài)行，比如"HTTP/1.1 200 OK"，和（響應(yīng)的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。
HTTP使用TCP而不是UDP的原因在于（打開一個）一個網(wǎng)頁必須傳送很多數(shù)據(jù)，而TCP協(xié)議提供傳輸控制，按順序組織數(shù)據(jù)，和錯誤糾正。具體細節(jié)請參考‘TCP和UDP的不同’通過HTTP或者HTTPS協(xié)議請求的資源由統(tǒng)一資源定位器（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。
HTTP請求信息（Request Message）
發(fā)出的請求信息包括以下幾個
HTTP請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images 目錄下請求logo.gif 這個文件。
（請求）頭，例如Accept-Language: en
空行
可選的消息體
請求行和標題必須以<CR><LF> 作為結(jié)尾（也就是，回車然后換行）?？招袃?nèi)必須只有<CR><LF>而無其他空格。在HTTP/1.1 協(xié)議中，所有的請求頭，除Host外，都是可選的。
HTTP請求方法（Request Methods）
HTTP協(xié)議中定義了八種方法（有時也叫“動作”）來表示對指定數(shù)據(jù)的操作。
HEAD
（Head方法）要求響應(yīng)與相應(yīng)的GET請求的響應(yīng)一樣，但是沒有的響應(yīng)體（response body）。這用來獲得響應(yīng)頭（response header）中的
元數(shù)據(jù)信息（meta-infomation）有（很）幫助，（因為）它不需要傳輸所有的內(nèi)容。
GET
（Get方法用來）請求指定的資源。它是目前網(wǎng)上最常用的方法。它不應(yīng)該用于一些會造成副作用的操作中
（在網(wǎng)絡(luò)應(yīng)用中用它來提交動作是一種常見的錯誤用法）。（細節(jié)請）參考后面的“安全方法”（這一節(jié)）。
POST
（POST方法用來）向指定的資源提交需要處理的數(shù)據(jù)。這些數(shù)據(jù)寫在請求的內(nèi)容里。（POST請求）可以導(dǎo)致新資源的產(chǎn)生和已有資源的更新。
PUT
上傳指定資源
DELETE
刪除指定資源
TRACE
（Trace方法告訴服務(wù)器端）返回收到的請求。客戶端可以（通過此方法）察看在請求過程中中間服務(wù)器添加或者改變哪些內(nèi)容。
OPTIONS
返回服務(wù)器（在指定URL上）支持的HTTP方法。通過請求“*”而不是指定的資源，這個方法可以用來檢查網(wǎng)絡(luò)服務(wù)器的功能。
CONNECT
將請求的連接轉(zhuǎn)換成透明的TCP/IP通道，通常用來簡化通過非加密的HTTP代理的SSL-加密通訊（HTTPS）。
HTTP服務(wù)器至少應(yīng)該實現(xiàn)Get和Head方法，可能的話，也實現(xiàn)OPTIONS方法。
HTTP安全方法
有些方法（比如HEAD, GET, OPTIONS, and TRACE) 被定義為安全方法，這些方法針對的只是信息的返回，并不會改變服務(wù)器的狀態(tài)（換句話說就是這些方法不會產(chǎn)生副作用）。不安全的方法（例如POST, PUT and DELETE) 應(yīng)該用特殊的方式向用戶展示，通常是按鈕而不是鏈接，這樣就可以使用戶意識到可能要負的責任（例如一個按鈕帶來的資金交易。）
HTTP協(xié)議版本號
超文本傳輸協(xié)議已經(jīng)演化出了很多版本，它們中的大部分都是向下兼容的?？蛻舳嗽谡埱蟮拈_始告訴服務(wù)器它采用的協(xié)議版本號，而后者則在響應(yīng)中采用相同或者更早的協(xié)議版本。
HTTP/0.9
已過時。只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由于該版本不支持 POST 方法，所以客戶端無法向服務(wù)器傳遞太多信息。
HTTP/1.0
這是第一個在通訊中指定版本號的 HTTP 協(xié)議版本，至今仍被廣泛采用，特別是在代理服務(wù)器中。
HTTP/1.1
當前版本。持久連接被默認采用，并能很好地配合代理服務(wù)器工作。還支持以管道方式在同時發(fā)送多個請求，以便降低線路負載，提高傳輸速度。
此版相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在：
HTTP緩存處理
帶寬及網(wǎng)絡(luò)連接的管理
安全性及完整性
HTTP狀態(tài)行
參見：HTTP狀態(tài)碼
所有 HTTP 響應(yīng)的第一行都是狀態(tài)行, 依次是當前 HTTP 版本號，3位數(shù)字組成的狀態(tài)代碼，以及描述狀態(tài)的短語，彼此由空格分隔。
狀態(tài)代碼的第一個數(shù)字代表當前響應(yīng)的類型：
1xx 消息——請求已被服務(wù)器接收，繼續(xù)處理
2xx 成功——請求已成功被服務(wù)器接收、理解、并接受
3xx 重定向——需要后續(xù)操作才能完成這一請求
4xx 請求錯誤——請求含有詞法錯誤或者無法被執(zhí)行
5xx 服務(wù)器錯誤——服務(wù)器在處理某個正確請求時發(fā)生錯誤
雖然 RFC 2616 中已經(jīng)推薦了描述狀態(tài)的短語，例如"200 OK"，"404 Not Found"，但是 WEB 開發(fā)者仍然能夠自行決定采用何種短語，用以顯示本地化的狀態(tài)描述或者自定義信息。
例子
下面是一個HTTP客戶端與服務(wù)器之間會話的例子，運行于www.cnpaf.net，端口80
客戶端請求：
GET / HTTP/1.1
Host：www.google.com
（緊跟著一個換行，通過敲入回車實現(xiàn)）
服務(wù)器應(yīng)答：
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格式的文本組成了中國協(xié)議分析網(wǎng)的主頁）
在HTTP1.0中，客戶端發(fā)送一個請求至服務(wù)器，服務(wù)器發(fā)送一個應(yīng)答至客戶端。之后，連接將被釋放。另一方面，HTTP1.1支持持久連接。這使得客戶端可以發(fā)送請求并且接收應(yīng)答，然后迅速的發(fā)送另一個請求和接收另一個應(yīng)答。因為多個額外的請求，TCP連接并沒有被釋放，而每個請求中關(guān)于TCP的負載相對較少。同時，在得到上一個請求的應(yīng)答之前發(fā)送多個請求（通常是兩個）也成為可能。這個技術(shù)被稱為“流水線”。
