超文本文檔中包含有超鏈接，指向其他的資源。超文本文檔是萬維網(wǎng)(World Wide Web，即www)的基礎。

HTTP協(xié)議解決文件傳輸?shù)膯栴}。HTTP是應用層協(xié)議，主要建立在TCP協(xié)議之上(偶爾也可以UDP為底層)。它隨著萬維網(wǎng)的發(fā)展而流行。HTTP協(xié)議目的是，如何在萬維網(wǎng)的網(wǎng)絡環(huán)境下，更好的利用TCP協(xié)議，以實現(xiàn)文件，特別是超文本文件的傳輸。

早期的HTTP協(xié)議主要傳輸靜態(tài)文件，即真實存儲在服務器上的文件。隨著萬維網(wǎng)的發(fā)展，HTTP協(xié)議被用于傳輸“動態(tài)文件”，服務器上的程序根據(jù)HTTP請求即時生成的動態(tài)文件。我們將HTTP的傳輸對象統(tǒng)稱為資源(resource)。

點單

HTTP實現(xiàn)了資源的訂購和傳送。其工作方式類似于快餐點單。

請求(request): 顧客向服務員提出請求：“來個雞腿漢堡”。

回復(response):服務員根據(jù)情況，回應顧客的請求

根據(jù)情況的不同，服務員的回應可能有很多，比如:

服務員準備雞腿漢堡，將雞腿漢堡交給顧客。(一切OK)

服務員發(fā)現(xiàn)自己只是個甜品站。他讓顧客前往正式柜臺點單。(重新定向)

服務員告訴顧客雞腿漢堡沒有了。(無法找到)

交易結(jié)束后，服務員就將剛才的交易拋到腦后，準備服務下一位顧客。

下面來看一下HTTP是如何具體實現(xiàn)的。

格式

HTTP協(xié)議的通信是一次request-responce交流?？蛻舳?guest)向服務器發(fā)出請求(request)，服務器(server)回復(response)客戶端。

HTTP協(xié)議規(guī)定了請求和回復的格式:

起始行 (start line)
頭信息 (headers)

主體(entity body)

起始行只有一行。它包含了請求/回復最重要的信息。請求的起始行表示(顧客)“想要什么”?；貜偷钠鹗夹斜硎?后廚)“發(fā)生什么”。

頭信息可以有多行。每一行是一對鍵值對(key-value pair)，比如:

Content-type: text/plain 

它表示，包含有一個名為Content-type的參數(shù)，該參數(shù)的值為text/plain。頭信息是對起始行的補充。請求的頭信息對服務器有指導意義 (好像在菜單上注明: 雞腿不要辣)?；貜偷念^信息則是提示客戶端(比如，在盒子上注明: 小心燙)

主體部分包含了具體的資源。上圖的請求中并沒有主體，因為我們只是在下單，而不用該后廚送什么東西 (請求是可以有主體內(nèi)容的)?；貜椭邪闹黧w是一段文本文字(Hello World!)。這段文本文字正是顧客所期待的，雞腿漢堡。

請求

我們深入一些細節(jié)。先來看一下請求:

GET /index.html HTTP/1.1
Host: www.example.com

在起始行中，有三段信息:

GET 方法。用于說明想要服務器執(zhí)行的操作。

/index.html 資源的路徑。這里指向服務器上的index.html文件。

HTTP/1.1 協(xié)議的版本。HTTP***個廣泛使用的版本是1.0，當前版本為1.1。

早期的HTTP協(xié)議只有GET方法。遵從HTTP協(xié)議，服務器接收到GET請求后，會將特定資源傳送給客戶。這類似于客戶點單，并獲得漢堡的過程。使用GET方法時，是客戶向服務器索取資源，所以請求往往沒有主體部分。

GET方法也可以用于傳輸一些不重要的數(shù)據(jù)。它是通過改寫URL的方式實現(xiàn)的。GET的數(shù)據(jù)利用URL?變量名=變量值的方法傳輸。比如向http://127.0.0.1發(fā)送一個變量“q”，它的值為“a”。那么，實際的URL為http://127.0.0.1?q=a。服務器收到請求后，就可以知道"q"的值為"a"。

GET方法之外，最常用的是POST方法。它用于從客戶端向服務器提交數(shù)據(jù)。使用POST方法時，URL不再被改寫。數(shù)據(jù)位于http請求的主體。POST方法最用于提交HTML的form數(shù)據(jù)。服務器往往會對POST方法提交的數(shù)據(jù)進行一定的處理，比如存入服務器數(shù)據(jù)庫。

樣例請求中有一行頭信息。該頭信息的名字是Host。HTTP的請求必須有Host頭信息，用于說明服務器的地址和端口。HTTP協(xié)議的默認端口是80，如果在HOST中沒有說明端口，那么將默認采取該端口。在該例子中，服務器的域名為www.example.com，端口為80。域名將通過DNS服務器轉(zhuǎn)換為IP地址，從而確定服務器在互聯(lián)網(wǎng)上的地址。#p#

回復

服務器在接收到請求之后，會根據(jù)程序，生成對應于該請求的回復，比如:

HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 12

Hello World!

回復的起始行同樣包含三段信息

HTTP/1.1 協(xié)議版本

200 狀態(tài)碼(status code)。

OK 狀態(tài)描述

OK是對狀態(tài)碼200的文字描述，它只是為了便于人類的閱讀。電腦只關心三位的狀態(tài)碼(status code)，即這里的200。200表示一切OK，資源正常返回。狀態(tài)碼代表了服務器回應動作的類型。

其它常見的狀態(tài)碼還有:

302，重新定向(redirect): 我這里沒有你想要的資源，但我知道另一個地方xxx有，你可以去那里找。

404，無法找到(not found): 我找不到你想要的資源，無能為力。

(重新定向時，客戶端可以根據(jù)302的建議前往xxx尋找資源，也可以忽略該建議。)

Content-type說明了主體所包含的資源的類型。根據(jù)類型的不同，客戶端可以啟動不同的處理程序(比如顯示圖像文件，播放聲音文件等等)。下面是一些常見的資源

text/plain 普通文本

text/html HTML文本

image/jpeg jpeg圖片

image/gif gif圖片

Content-length說明了主體部分的長度，以字節(jié)(byte)為單位。

回應的主體部分為一段普通文本，即

Hello World!

無狀態(tài)

根據(jù)早期的HTTP協(xié)議，每次request-reponse時，都要重新建立TCP連接。TCP連接每次都重新建立，所以服務器無法知道上次請求和本次請求是否來自于同一個客戶端。因此，HTTP通信是無狀態(tài)(stateless)的。服務器認為每次請求都是一個全新的請求，無論該請求是否來自同一地址。

想象高級餐廳和快餐店。高級餐廳會知道客人所在的位置，如果新增點單，那么服務員知道這和上一單同一桌。而在快餐店中，不好意思，服務員并不記錄客人的特征。想再次點單?請重新排隊……

隨著HTTP協(xié)議的發(fā)展，HTTP協(xié)議允許TCP連接復用，以節(jié)省建立連接所耗費的時間。但HTTP協(xié)議依然保持無狀態(tài)的特性。

總結(jié)

HTTP協(xié)議實現(xiàn)了萬維網(wǎng)上的資源傳輸，采用request-response的工作方式。

GET， POST

無狀態(tài)