一、HTTP概況
20世紀90年代初期，一個主要的新興應用即萬維網（World Wide Web）登上了舞臺。Web是一個引起公眾注意的因特網應用。Web的應用層協議是超文本傳輸協議（HTTP），它是Web的核心。HTTP由兩個程序實現：一個客戶程序和一個服務器程序。客戶程序和服務器程序運行在不同的端系統中，通過交換HTTP報文進行會話。HTTP會話定義了這些報文的結構以及客戶和服務器進行報文交換的方式。
Web頁面（也叫文檔）是由對象組成的。一個對象只是一個文件，諸如一個HTML文件、一個JPEG圖形、一個Java小程序或一個視頻片段這樣的文件，且他們可通過一個URL地址尋址。多數Web頁面含有一個HTML基本文件以及幾個引用對象。例如，如果一個Web頁面包含HTML基本文件和5個JPEG圖形，那么這個Web頁面6個對象：一個HTML基本文件加5個圖形。HTML基本文件通過對象的URL地址引用頁面中的其他對象。每個URL地址由兩部分組成：存放對象的服務器主機名和對象的路徑名。Web瀏覽器實現了HTTP的客戶端，Web服務器實現了HTTP的服務器端，它用于存儲Web對象，每個對象由URL尋址。
HTTP定義了Web客戶向Web服務器請求Web頁面的方式，以及服務器向客戶傳送Web頁面的方式，其基本思想就是當用戶請求一個Web頁面（如點擊一個超鏈接）時，瀏覽器向服務器發出對該頁面中所包含對象的HTTP請求報文，服務器接收到請求并用包含這些對象的HTTP響應報文進行響應。
HTTP使用TCP作為它的支撐運輸協議（而不是在UDP上運行）。HTTP客戶首先發起一個與服務器的TCP連接。一旦連接建立，該瀏覽器和服務器進程就可以通過套接字接口訪問TCP。客戶向它的套接字接口發送HTTP請求報文并從它的套接字接口接收HTTP響應報文。類似的，服務器從它的套接字接口接收HTTP請求報文和向它的套接字接口發送HTTP響應報文。一旦客戶向他的套接字接口發送了一個請求報文，該報文就脫離了客戶控制并進入TCP的控制。TCP為HTTP提供可靠數據傳輸服務。這意味著，一個客戶進程發出的每個HTTP請求報文最終能完整地到達服務器；類似的，服務器進程發出的每個HTTP響應報文最終能完整地到達客戶。
注意到下列現象很重要：服務器向客戶發送被請求的文件，而不存儲任何關于該客戶的狀態信息。假如某個特定的客戶在短短的幾秒鐘內兩次請求同一個對象，服務器并不會因為剛剛為該客戶提供了該對象就不再做出反應，而是重新發送該對象，就像服務器已經完全忘記不久之前所做過的事一樣。因為HTTP服務器并不保存關于客戶的任何信息，所以我們說HTTP是一個無狀態協議。
二、非持續連接和持續連接
在許多因特網應用程序中，客戶和服務器在一個相當長的時間范圍內通信，其中客戶發出一系列請求并且服務器對每個請求進行響應。依據應用程序以及該應用程序的使用方式，這一系列請求可以以規則的間隔周期性的或者間斷性的一個接一個發出。當這種客戶-服務器的交互是經TCP進行的，應用程序的研制者就要做一個重要決定，即每個請求/響應對是經一個單獨的TCP連接發送，還是所有的請求及其相應經相同的TCP連接發送呢？采用前一種方法，該應用程序被稱為使用非持續連接；采用后一種方法，該應用程序被稱為使用持續連接。如HTTP既能夠使用非持續連接，也能夠使用持續連接。盡管HTTP在默認方式下使用持續連接，HTTP客戶和服務器也能配置成非持續連接。
1.采用非持續連接的HTTP
我們看看在非持續連接情況下，從服務器向客戶傳送一個Web頁面的步驟。假設該頁面含有一個HTML基本文件和10個JPEG圖形，并且這11個對象位于同一臺服務器上。該HTML文件的URL為：http://www.someSchool.edu/someDepartment/home.index。我們看看發生了什么情況：
- HTTP客戶進程在端口號80發起一個到服務器www.someSchool.edu的TCP連接，該端口號是HTTP的默認端口。在客戶和服務器上分別有一個套接字與該連接相關聯。
- HTTP客戶經它的套接字向該服務器發送一個HTTP請求報文。請求報文中包含了路徑名/someDepartment/home.index。
- HTTP服務器進程經它的套接字接收該請求報文，從其存儲器（RAM或磁盤）中檢索出對象http://www.someSchool.edu/someDepartment/home.index，在一個HTTP響應報文中封裝對象，并通過其套接字向客戶發送響應報文。
- HTTP服務器進程通知TCP斷開該TCP連接。（但是直到TCP確認客戶已經完整的收到響應報文為止，它才會實際中斷連接。
- HTTP客戶接收響應報文，TCP連接關閉。該報文指出封裝的對象是一個HTML文件，客戶從響應報文中提取出該文件，檢查該HTML文件，得到對10個JPEG圖形的引用。
- 對每個引用的JPEG圖形對象重復前4個步驟。
上面的步驟舉例說明了非持續連接的使用，其中每個TCP連接在服務器發送一個對象后關閉，即該連接并不為其他的對象而持續下來。值得注意的是每個TCP來接只傳輸一個請求報文和響應報文。
在上面描述的步驟中，我們有意沒有明確客戶獲得這10個JPEG圖形對象是使用10個串行的TCP連接，還是某些JPEG對象使用了一些并行的TCP連接。事實上，用戶能配置現代瀏覽器以控制并行度。在默認方式下，大部分瀏覽器打開5~10個并行的TCP連接，而每條連接處理一個請求響應事務。如果用戶愿意，最大并行連接數可以設置為1，這樣10條連接就會串行建立。
我們來簡單估算一下從客戶請求HTML基本文件起到該客戶收到整個文件止所花費的時間。為此，我們給出往返時間（Round-Trip Time，RTT）的定義，該時間是指一個短分組從客戶到服務器然后再返回客戶所花費的時間。RTT包括分組傳播時延、分組在中間路由器和交換機上的排隊時延以及分組處理時延。現在考慮當用戶點擊超鏈接時會發生什么現象。如圖2-7所示，這引起瀏覽器在它和Web服務器之間發起一個TCP連接；這涉及一次“三次握手”過程。即客戶向服務器發送一個小TCP報文段，服務器用一個小TCP報文段做出確認和響應，最后，客戶向服務器返回確認。三次握手中前兩個部分所耗費的時間占用了一個RTT。完成了三次握手的前兩個部分后，客戶結合三次握手的第三部分（確認）向該TCP連接發送一個HTTP請求報文。一旦該請求報文到達服務器，服務器就在該TCP連接上發送HTML文件。該HTTP請求/響應用去了另一個RTT。因此，粗略地將，總的響應時間就是兩個RTT加上服務器傳輸HTML文件的時間。
2.采用持續連接的HTTP
非持續連接有一些缺點。首先，必須為每一個請求的對象建立和維護一個全新的連接。對于每個這樣的連接，在客戶和服務器中都要分配TCP的緩沖區和保持TCP變量，這給Web服務器帶來了嚴重的負擔，因為一臺Web服務器可能同時服務于數以百計不同的客戶的請求。第二，就像我們剛描述的那樣，每一個對象經受兩倍RTT的交付時延，即一個RTT用于創建TCP，另一個RTT用于請求和接收一個對象。
在采用持續連接的情況下，服務器在發送響應后保持該TCP連接打開。在相同的客戶與服務器之間的后續請求和響應報文能夠通過相同的連接進行傳送。特別是，一個完整的Web頁面（上例中的HTML基本文件加上10個圖形）可以用單個持續TCP連接進行傳送。更有甚者，位于同一臺服務器的多個Web頁面在從該服務器發送給同一個客戶時，可以在單個持續TCP連接上進行。可以一個接一個地發出對對象的這些請求，而不必等待對未決請求（流水線）的回答。一般來說，如果一條連接經過一定的時間間隔（一個可配置的超時間隔）仍未被使用，HTTP服務器就關閉該連接。HTTP的默認模式是使用帶流水線的持續連接。
三、HTTP報文格式
HTTP報文有兩種：請求報文和響應報文。
1.HTTP請求報文
下面提供了一個典型的HTTP請求報文：
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
通過仔細觀察這個簡單的請求報文，我們就能知道很多東西。首先，我們看到該報文是用普通的ASCII文本書寫的，我們看到該報文由5行組成，每行由一個回車和換行符結束。最后一行后再附加一個回車換行符。一個請求報文能夠具有更多的行或者至少為一行。請求行的方法字段可以取幾種不同的值，包括GET、POST、HEAD、PUT和DELETE。當瀏覽器請求一個對象時，使用GET方法，在URL字段帶有請求對象的標識，在本例中，該瀏覽器正在請求對象/somedir/page.html。其版本字段是自解釋的；在本例中，瀏覽器實現的是HTTP/1.1版本。現在我們看看本例的首部行。首部行Host: www.someschool.edu指明了對象所在的主機。你也許認為該首部行是不必要的，因為在該主機中已經有一條TCP連接存在了，但是，該首部行提供的信息是Web代理高速緩存所要求的。通過包含Connection: close首部行，該瀏覽器告訴服務器不希望麻煩地使用持續連接，它要求服務器在發送完被請求的對象后就關閉這條連接。User-agent: 首部行用來指明用戶代理，即向服務器發送請求的瀏覽器類型。這里瀏覽器類型是Mozilla/5.0，即Firefox瀏覽器。這個首部行是有用的，因為服務器可以有效地為不同類型的用戶代理實際發送相同對象的不同版本。（每個版本都由相同的URL尋址。）最后，Accept-language: 首部行表示用戶想得到該對象的法語版本。如果服務器中沒有這樣的對象的話，服務器應當發送它的默認版本。
接下來看看如圖2-8所示的一個請求報文的通用格式。你可能注意到了在首部行（和附加的回車和換行）后有一個“實體主體”。使用GET方法是實體主體為空，而使用POST方法時才使用該實體主體。當用戶提交表單時，HTTP客戶常常使用POST方法，例如當用戶向搜索引擎提供搜索關鍵詞時。使用POST報文時，用戶仍可以向服務器請求一個Web頁面，但Web頁面的特定內容依賴于用戶在表單字段中輸入的內容。如果方法字段的值為POST時，則實體主體中包含的就是用戶在表單字段中的輸入值。
當然，如果不提“用表單生成的請求報文不是必須使用POST方法”這一點，那將是失職。HTML表單經常使用GET方法，并在（表單字段中）所請求的URL中包括輸入的數據。例如，一個表單使用GET方法，它有兩個字段，分別填寫的是“monkeys”和“bananas”，這樣，該URL結構為www.somesite.com/animalsearch? monkeys&bananas。
HEAD方法類似GET方法。當服務器收到使用HEAD方法的請求時，將會用一個HTTP報文進行響應，但是并不返回請求對象。應用程序開發者常用HEAD方法進行調試跟蹤。PUT方法常與Web發行工具聯合使用，它允許用戶上傳對象到指定的Web服務器上指定的路徑（目錄）。PUT也被那些需要向Web服務器上傳對象的應用程序使用。DELETE方法允許用戶或者應用程序刪除Web服務器上的對象。
2.HTTP響應報文
下面我們提供了一條典型的HTTP響應報文。該響應報文可以是對剛剛討論的例子中請求報文的響應。
HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)
我們仔細看這個響應報文。實體主體部分是報文的主要部分，即它包含了所請求的對象本身（表示為data data data data data ...）。我們現在來看看首部行。服務器用Connection：close首部行告訴客戶，發送完報文后將關閉該TCP連接。Date：首部行指示服務器產生并發送該響應報文的日期和時間。值得一提的是，這個時間不是指對象創建或者最后修改的時間；而是服務器從它的文件系統中檢索到該對象，插入到響應報文，并發送響應報文的時間。Server：首部行指示該報文是由一臺Apache Web服務器產生的，它類似于HTTP請求報文中的User-agent：首部行，Last-Modified：首部行指示了對象創建或者最后修改的日期和時間。Last-Modified：首部行對極可能在本地客戶也可能在網絡緩存服務器（代理服務器）上的對象緩存來說非常重要。Content-Length：首部行知識了被發送對象中的字節數。Content-Type：首部行指示了實體主體中的對象是HTML文本。（該對象類型應該正式地由Content-Type：首部行而不是用文件擴展名來指示。）
看過一個例子后，我們再來查看響應報文的通用格式（如圖2-9所示）。我們補充說明一下狀態碼和它們對應的短語。狀態碼及其相應的短語指示了請求的結果。一些常見的狀態碼和相關的短語包括：
- 200 OK：請求成功，信息在返回的響應報文中。
- 301 Moved Permanently：請求的對象已經被永久轉移了，新的URL定義在響應報文的Location：首部行中。**客戶軟件將自動獲取新的URL。
- 400 Bad Request：一個通用差錯代碼，指示該請求不能被服務器理解。
- 404 Not Found：被請求的文檔不在服務器上。
- 505 HTTP Version Not Supported：服務器不支持請求報文使用的HTTP協議版本。
你想看一下真正的HTTP響應報文嗎？很容易做到。首先用Telnet登錄到你喜歡的Web服務器上，接下來輸入一個只有一行的請求報文去請求放在該服務器上的某些對象。
在linux終端輸入完telnet www.baidu.com 80后，會是下面這種情況：
然后按下ctrl + ]呼出telnet命令行出現下面這種情況：
先按下回車鍵，再輸入HTTP請求，最終得到HTTP響應如下：
在telnet命令行上輸入quit退出telnet，如下圖：
