HTTP協議介紹

萬維網

萬維網www (World Wide Web)並不是某種特殊的計算機網絡。萬維網是一個大規模的、聯機式的信息儲藏所，英文簡稱爲Web.萬維網用連接的方法能很是方便地從互聯網上的一個站點訪問另外一個站點(也就是所謂的「連接到另外一個站點」)，從而主動地按需獲取豐富的信息。

萬維網是一個分佈式的超媒體(lhypermedia)系統，它是超文本(hypertext)系統的擴充。所謂超文本是指包含指向其餘文檔的連接的文本(text)。也就是說，一個超文本由多個信息源連接成，而這些信息源能夠分佈在世界各地，而且數目也是不受限制的。利用一個連接可以使用戶找到遠在異地的另外一個文檔，而這又可連接到其餘的文檔(依此類推)。這些文檔能夠位於世界上任何一個接在互聯網上的超文本系統中。超文本是萬維網的基礎。超媒體與超文本的區別是文檔內容不一樣。超文本文檔僅包含文本信息，而超媒體文檔還包含其餘表示方式的信息，如圖形、圖像、聲音、動畫以及視頻圖像等。

萬維網以客戶服務器方式工做。上面所說的瀏覽器就是在用戶主機上的萬維網客戶程序。萬維網文檔所駐留的主機則運行服務器程序，所以這臺主機也稱爲萬維網服務器。客戶程序向服務器程序發出請求，服務器程序向客戶程序送回客戶所要的萬維網文檔。在一個客戶程序主窗口上顯示出的萬維網文檔稱爲頁面(page)。

從以上所述能夠看出，萬維網必須解決如下幾個問題:
(1)怎樣標誌分佈在整個互聯網上的萬維網文檔?
(2)用什麼樣的協議來實現萬維網上的各類連接?
(3)怎樣使不一樣做者創做的不一樣風格的萬維網文檔，都能在互聯網上的各類主機上顯示出來，同時使用戶清楚地知道在什麼地方存在着連接?
(4)怎樣使用戶可以很方便地找到所需的信息?
在這裏主要回答前兩個問題。

URL

爲了解決第一個問題，萬維網使用統一資源定位符URL (Uniform Resource Locator)來標誌萬維網上的各類文檔，並使每個文檔在整個互聯網的範圍內具備惟- 的標識符URL。

URL的格式

一資源定位符URL是用來表示從互聯網上獲得的資源位置和訪問這些資源的方法。URL給資源的位置提供一種抽象的識別方法，並用這種方法給資源定位。只要可以對資源定位，系統就能夠對資源進行各類操做，如存取、更新、替換和查找其屬性。因而可知，URL實際上就是在互聯網上的資源的地址。只有知道了這個資源在互聯網上的什麼地方，才能對它進行操做。顯然，互聯網上的全部資源，都有一個惟一肯定的URL.

URL的通常形式由如下四個部分組成:

<協議>://<主機>:<端口>/<路徑>

URL的第一部分是最左邊的<協議>。這裏的<協議>就是指出使用什麼協議來獲取該萬維網文檔。如今最經常使用的協議就是http (超文本傳送協議HTTP),其次是ftp(文件傳送協議FTP)。

在<協議>後面的「//」是規定的格式。它的右邊是第二部分<主機>，它指出這個萬維網文檔是在哪一臺主機上。這裏的<主機>就是指該主機在互聯網上的域名。再後面是第三和第四部分<端口>和<路徑>，有時可省略。而使用最多的URL就是http的URL:http://<主機>:<端口>/<路徑>

超文本傳輸協議HTTP

爲了解決上述的第二個問題，就要使萬維網客戶程序與萬維網服務器程序之間的交互遵照嚴格的協議,這就是超文本傳送協議HTTP (HyperText Transfer Protocol)。HTTP 是一個應用層協議，它使用TCP鏈接進行可靠的傳送。

HTTP的操做過程

HTTP協議定義了瀏覽器(即萬維網客戶進程)怎樣向萬維網服務器請求萬維網文檔，以及服務器怎樣把文檔傳送給瀏覽器。從層次的角度看，HTTP 是面向事務的(ransaction-oriented)」應用層協議，它是萬維網上可以可靠地交換文件(包括文本、聲音、圖像等各類多媒體文件)的重要基礎。請注意，HTTP不只傳送完成超文本跳轉所必需的信息，並且也傳送任何能夠從互聯網獲取的信息。

每一個萬維網網點都有一個服務器進程，它不斷地監聽TCP的端口80，以便發現是否有瀏覽器(即萬維網客戶。請注意，瀏覽器和萬維網客戶是同義詞)向它發出鏈接創建請求。一旦監聽到鏈接創建請求並創建了TCP鏈接以後，瀏覽器就向萬維網服務器發出瀏覽某個頁面的請求，服務器接着就返回所請求的頁面做爲響應。最後，TCP鏈接就被釋放了。在瀏覽器和服務器之間的請求和響應的交互，必須按照規定的格式和遵循必定的規則。這些格式和規則就是超文本傳送協議HTTP。

HTTP使用了面向鏈接的TCP做爲運輸層協議，保證了數據的可靠傳輸。HTTP沒必要考慮數據在傳輸過程當中被丟棄後又怎樣被重傳。可是，HTTP 協議自己是無鏈接的。這就是說，雖然HTTP使用了TCP鏈接，但通訊的雙方在交換HTTP報文以前不須要先創建HTTP鏈接。

HTTP協議是無狀態的(stateless)。也就是說，同一個客戶第二次訪問同一個服務器上的頁面時，服務器的響應與第一次被訪問時的相同(假定如今服務器尚未把該頁面更新)，由於服務器並不記得曾經訪問過的這個客戶，也不記得爲該客戶曾經服務過多少次。HTTP的無狀態特性簡化了服務器的設計，使服務器更容易支持大量併發的HTTP請求。

一次http請求的時間

用戶在點擊鼠標連接某個萬維網文檔時，HTTP協議首先要和服務器創建TCP鏈接。這須要使用三個報文握手。當創建TCP鏈接的三個報文握手的前兩部分完成後(即通過了一個RTT時間後)，萬維網客戶就把HTTP請求報文，做爲創建TCP鏈接的三個報文握手中的第三個報文的數據，發送給萬維網服務器。服務器收到HTTP請求報文後，就把所請求的文檔做爲響應報文返回給客戶。

從上圖可看出，請求一個萬維網文檔所需的時間是該文檔的傳輸時間(與文檔大小成正比)加上兩倍往返時間RTT (一個RTT用於鏈接TCP鏈接，另外一個RTT用於請求和接收萬維網文檔。TCP創建鏈接的三報文握手的第三個報文段中的數據，就是客戶對萬維網文檔的請求報文)。

HTTP/1.0的主要缺點，就是每請求一個文檔就要有兩倍RTT的開銷。若一個主頁上有不少連接的對象(如圖片等)須要依次進行連接，那麼每一次連接下載都致使2x RTT的開銷。另外一種開銷就是萬維網客戶和服務器每一次創建新的TCP鏈接都要分配緩存和變量。特別是萬維網服務器每每要同時服務於大量客戶的請求，因此這種非持續鏈接會使萬維網服務器的負擔很重。好在瀏覽器都可以打開5 ~ 10個並行的TCP鏈接，而每個TCP鏈接處理客戶的一個請求。所以，使用並行TCP鏈接能夠縮短響應時間。

HTTP/1.1協議較好地解決了這個問題，它使用了持續鏈接(persistent connection)。 所謂持續鏈接就縣萬維網服務器發送響應後仍在一段時間內保持鏈接，使同一個客戶(瀏覽器)和該服務器能夠繼續在這條鏈接上傳送後續的HTTP請求報文和響應報文。這並不侷限於傳送同一個頁面上連接的文檔，而是隻要這些文檔都在同一個服務器上就行。

HTTP/1.1協議的持續鏈接有兩種工做方式，即非流水線方式(without pipelining)和流水線方式(with pipelining)。

非流水線方式的特色，是客戶在收到前一個響應後才能發出下一個請求。所以，在TCP鏈接已創建後，客戶每訪問一次對象都要用去一個往返時間RTT。這比非持續鏈接要用去兩倍RTT的開銷，節省了創建TCP鏈接所需的一個RTT時間。但非流水線方式仍是有缺點的，由於服務器在發送完一個對象後，其TCP鏈接就處於空閒狀態，浪費了服務器資源。流水線方式的特色，是客戶在收到HTTP的響應報文以前就可以接着發送新的請求報文。因而一個接一個的請求報文到達服務器後，服務器就可連續發回響應報文。所以，使用流水線方式，客戶訪問全部的對象只需花費一個RTT的時間開銷(等待的時間)。

http報文的結構

因爲HTTP是面向文本的(text oriented),所以在報文中的每個字段都是一些ASCII碼串，於是各個字段的長度都是不肯定的。
HTTP請求報文和響應報文都是由三個部分組成的。能夠看出，這兩種報文格式的區別。

(1)開始行，用於區分是請求報文仍是響應報文。在請求報文中的開始行叫作請求行(Request-Line)，而在響應報文中的開始行叫作狀態行(Status Line)。在開始行的三個字段之間都以空格分隔開，最後的「CR」和「LF」分別表明「回車」和「換行」。
(2)首部行，用來講明瀏覽器、服務器或報文主體的一些信息。首部能夠有好幾行，但也能夠不使用。在每個首部行中都有首部字段名和它的值，每一行在結束的地方都要有「回車」和「換行」。整個首部行結束時，還有一空行將首部行和後面的實體主體分開。
(3)實體主體(entity body)，在請求報文中通常都不用這個字段，而在響應報文中也可能沒有這個字段。

下面先介紹HTTP請求報文的一些主要特色。

請求報文的第一行「請求行」只有三個內容，即方法，請求資源的URL,以及HTTP的版本。
所謂「方法」就是對所請求的對象進行的操做，這些方法實際上也就是一些命令。所以，請求報文的類型是由它所採用的方法決定的。下面給出了請求報文中經常使用的幾種方法。

方法	意義
OPTION	請求一些選項的信息
GET	請求讀取由URL所標誌的信息
HEAD	請求讀取由URL所標誌的信息的首部
POST	給服務器添加信息(例如，註釋)
PUT	在指明的URL下存儲一個文檔
DELETE	刪除指明的URL所標誌的資源
TRACE	用來進行環回測試的請求報文
CONNECT	用於代理服務器

再看一下HTTP響應報文的主要特色。

每個請求報文發出後，都能收到一個響應報文。響應報文的第一行就是狀態行。
狀態行包括三項內容，即HTTP的版本，狀態碼，以及解釋狀態碼的簡單短語。
狀態碼(Status-Code)都是三位數字的，分爲5大類，原先有33種[RFC 2616]，後來又增長了幾種[RFC 6585]。這5大類的狀態碼都是以不一樣的數字開頭的。

1xx表示通知信息，如請求收到了或正在進行處理。
2xx表示成功，如接受或知道了。
3xx表示重定向，如要完成請求還必須採起進步的行動。
4xx表示客戶的差錯，如請求中有錯誤的語法或不能完成。
5xx表示服務器的差錯，如服務器失效沒法完成請求。