第30章超文本傳輸協議-好第一頁，共33頁。第30章超文本傳輸協議30.1統(tǒng)一資源定位符30.2超文本傳輸協議30.3一般格式30.4HTTP請求報文30.5HTTP響應報文第二頁，共33頁。30.1統(tǒng)一資源定位符

統(tǒng)一資源定位符URL(UniformResourceLocator)，也稱Web地址，俗稱“網址”。

URL的完整格式有以下基本部分組成： 協議+“://”+主機域名(IP地址)+“:”端口號+目錄路徑+文件名第三頁，共33頁。1．協議協議是指定服務連接而使用的所有訪問協議，下表表示常用的協議類型。協議名稱功能http超文本文件服務ftp文件傳輸服務gopherGopher服務newsUsenet新聞組服務telnet遠程主機連接服務waisWAIS服務器連接服務第四頁，共33頁。2．主機域名(IP地址)

主機域名(IP地址)指出WWW數據所在的服務器域名，例如。3．端口(port)

服務器提供端口號表示客戶訪問不同資源類型，例如常見的WWW服務器提供端口號為80或8080。在URL中端口號可以省略，省略時連同前面的“：”一起省略。4．目錄路徑(path)

目錄路徑指明服務器上存放被請求信息的路徑。5．文件名（file）文件名是客戶訪問頁面的名稱。例如index.htm，頁面名稱與設計時網頁的源代碼名稱并不要求相同，由服務器完成兩者之間的映射。第五頁，共33頁。路徑表示資源在主機中的位置，路徑描述采用的是UNIX下的路徑格式。端口和路徑都是可以省略的。例子：返回第六頁，共33頁。30.2超文本傳輸協議

HTTP協議是作為一種請求／回答協議來實現的?？蛻粽埱髲腤eb服務器上給他傳輸一頁。Web服務器以那一頁來應答。

HTTP協議工作在應用層。一個客戶將一個請求發(fā)送給HTTP服務器(通常在TCP的80號端口)；HTTP服務器接受這個請求，并給客戶發(fā)送一個合適的回答。 實際的通訊一般不是持續(xù)連接的，并且非靜態(tài)的。當HTTP服務器回答了客戶的請求之后連接便撤銷，直到發(fā)布了下一個請求。第七頁，共33頁。1．HTTP通信方式

HTTP為客戶／服務器通信提供了握手方式及消息傳送格式。

HTTP采用請求／響應的握手方式，HTTP定義的事務處理其運作的基本過程如下圖所示：

第八頁，共33頁。

HTTP通信方式主要三種：

1)點對點方式點對點方式是最簡單的傳輸方式，用戶經過請求與源服務器間通過HTTP建立起點對點的連接。

2）具有中間服務器方式中間服務器系統(tǒng)充當通信中繼功能，客戶發(fā)出的請求通過中繼到達相關的服務器，同樣服務器的響應也要通過中繼才能返回給客戶。

3）緩存方式緩存方式暫時保存一定時間內的客戶請求及該客戶請求所對應的服務器響應，這樣的緩存便于處理新的客戶請求，節(jié)省網絡流量和當地計算資源。第九頁，共33頁。2.HTTP的安全性

HTTP安全性可以通過加密和鑒別來實現，最通常的方法是使用安全套接字層(SSL)。 安全套接字層SSL工作在TCP/IP的傳輸層和應用層之間。在客戶和服務器之間的所有傳輸都被SSL加密和解密。下圖顯示的是一個典型的SSL通信順序。第十頁，共33頁。SSL通信工作過程如下：1）客戶機發(fā)送安全會話請求消息，此消息包括SSL版本、客戶機支持的密碼族和客戶機支持的數據壓縮方法等。2）服務器發(fā)送響應消息和服務器數字證書（含服務器的公鑰），響應消息包含密碼方法和由服務器選擇的數據壓縮方法，以及會話標識等。如果服務器需要對客戶進行認證（可選），則向客戶發(fā)出“證書請求”消息。消息中包含服務器支持的數字證書類型的列表和可接受的認證中心的專有名稱。3）客戶機（Web瀏覽器）將驗證服務器數字證書的有效性并檢查服務器的響應消息參數是否可以接受。如果服務器請求客戶機的證書，客戶機將發(fā)送數字證書；如果沒有合適的數字證書可用，客戶機將發(fā)送“沒有證書”警告。如果客戶機認證是強制性的，服務器將會使會話失敗。第十一頁，共33頁。4）客戶機發(fā)送“客戶機密鑰交換”消息。此消息包含隨機產生的會話密鑰、報文鑒別碼（MAC）密鑰（用服務器的公鑰加密的）以及用于加密和報文鑒別的密鑰材料。如果客戶機發(fā)送數字證書給服務器，客戶機將發(fā)出簽有客戶機的專用密鑰的“證書驗證”消息。通過驗證此消息的簽名，服務器可以顯式驗證客戶機數字證書的所有權。5）服務器發(fā)送“已完成”消息響應，SSL握手結束。隨后的所有的數據將被加密和解密。URL中包含HTTPS://。第十二頁，共33頁。3．HTTP主要特點

1）簡單

HTTP協議在客戶與服務器連接后，要求客戶必須傳送的信息只是請求方法和路徑。

HTTP協議規(guī)范定義的幾種請求方法，實際上常用的只是其中的GET、HEAD、POST三種。由于HTTP簡單，使得HTTP服務器程序規(guī)模小且簡單，與其它協議相比時間開銷小。HTTP協議的通信速度很快，可以有效地處理大量請求，得到了廣泛的使用。

2）無連接性

HTTP是一個無連接性協議(HTTP1.0)，每次連接只處理一個請求，并且客戶接到服務器應答后立即斷開連接。(HTTP1.1提供對持續(xù)連接的支持)第十三頁，共33頁。3）無狀態(tài)性

HTTP是無狀態(tài)的協議。

HTTP無狀態(tài)性使客戶與服務器連接通信運行速度快，服務器應答也快。但是，因為無狀態(tài)性，協議對事務處理是沒有記憶的和獨立的。所以，為了滿足后續(xù)事務處理需要前面事務的有關信息的情況，這些前面事務的有關信息必須在協議外面保存，這便導致每次連接要傳送較多的信息。

4）元信息

HTTP協議對所有事務處理都加了首部，我們稱之為元信息，即關于信息的信息。返回第十四頁，共33頁。30.3一般格式HTTP信息采用RFC822的普通信息格式，信息包含請求行/狀態(tài)行(start-line)、信息首部(message—header)、空行（null）和信息體(message—body)。

請求行/狀態(tài)行信息首部空行信息行第十五頁，共33頁。1．請求行/狀態(tài)行請求行/狀態(tài)行指示本報文的請求類型或響應的狀態(tài)等信息。在客戶端發(fā)出的請求報文中指明請求類型(方法)、URL、HTTP版本號；在服務器發(fā)出的響應報文中指明HTTP版本號和服務器執(zhí)行請求的狀態(tài)信息。2．信息首部信息首部(message-header)用于在客戶端和服務器之間交換附加信息。HTTP信息首部有4類： 一般首部(general—header)

請求首部(request-header)

響應首部(response-header)

實體首部(entity-header)．

第十六頁，共33頁。信息首部每行用一個首部名-值對表示。首部名和首部值用冒號分割。首部內容：

(1)一般首部：一般首部是請求和響應中都可以出現的用于描述報文的一般信息，如Cache-control、Connection、Date、MIME-version、Upgrade。首部名：首部值首部名：首部值…首部名：首部值第十七頁，共33頁。(2)請求首部：僅出現在請求報文中，定義客戶端的配置和客戶端所期望的文檔格式。如：Accept表明客戶端可以接受的媒體格式Accept-charset表明客戶端可以處理的字符集Accept-encoding表明客戶端可以處理的編碼機制Accept-language表明客戶端可以接受的語言Authorization表明客戶端具有的權限From表明用戶的e-mail地址Host表示客戶端的主機和端口號If-modified-since如果比定義的日期新則發(fā)送文件If-match如果與給定匹配則發(fā)送文件……第十八頁，共33頁。(3)響應首部：僅出現在響應報文中，定義服務器的配置和關于請求的信息。如：Accept-range服務器是否接受客戶請求的范圍Age文檔的存在時間Public表明服務器所支持的方法列表Retry-after定義服務器可用的日期Server服務器名和版本號(4)實體首部：給出文檔主體數據的信息。實體頭部主要出現在響應中，POST和PUT類型的請求也會使用實體頭部。Allow可用于URL的方法列表Content-encoding定義編碼機制第十九頁，共33頁。Content-language定義語言Content-length表示文檔的長度Content-range定義文檔的范圍Content-type定義媒體的類型Etag實體標簽Expires給出實體可能變化的日期和時間Last-modified給出實體上次變化的日期和時間Location定義產生和移動的文檔的位置第二十頁，共33頁。3.信息體(message-body)信息體是用來傳遞與請求或響應相關的實體的。使用傳遞編碼：信息體是經過編碼的實體；未使用傳遞編碼：信息體就是實體本身。傳遞編碼主要是用來增強保密性或讓支持這種編碼的接收者能正確接收。在客戶的請求報文中，信息體存放POST、PUT等請求向服務器傳送的數據；在服務器發(fā)出的響應報文中，信息體存放服務器返回的客戶所請求的頁面。返回第二十一頁，共33頁。30.4HTTP請求報文在HTTP報文中，大多數請求報文沒有實體數據，請求報文的格式如圖所示：常用的HTTP請求的方法有GET、HEAD、PUT、POST、DELETE、LINK、UNLINK七種方法，其中GET、HEAD、POST方法被大多數服務器支持。第二十二頁，共33頁。1)GET方法

GET方法的目的是取回由URL指定的資源。若對象是文件，則GET取的是文件內容；若對象是程序或描述，則GET取的是該程序執(zhí)行的結果，或該描述的輸出；若對象是數據庫查詢，則GET取的是查詢的結果。

GET允許通過使用IF語句來增加附加的靈活性，即條件GET。當在IF語句中的條件得到滿足時，數據便被傳輸。如果Web頁在最近沒有被更新，HTTP客戶便可以使用Web頁在緩沖區(qū)的拷貝。這樣可以充分利用網絡帶寬。第二十三頁，共33頁。2)HEAD方法

HEAD方法要求服務器查找某對象的元信息而不是對象本身，僅要求服務器返回關于文檔的信息，而非文檔本身。例如用戶想知道對象的大小，對象的最后一次修改的時間等。

HEAD方法和GET方法的工作非常類似，只是信息體不被返回到客戶那里。3)POST方法

POST方法從客戶向服務器傳送數據，用來請求HTTP服務器將附帶的數據當作HTTP服務器一個新的記錄來接收。這種方法可被用來將消息發(fā)給一個新聞組，或向HTTP服務器提交一個HTML表格，或者將一個記錄附加到HTTP服務器上駐留的一個數據庫上去。第二十四頁，共33頁。4）PUT方法

PUT方法是用來請求將這個請求中所發(fā)送的數據儲存到請求消息中表明的資源處。如果數據已經存在，則此數據將被看成已存在數據的一個修改。與POST方法的不同之處：數據的目標位置可以規(guī)定好。5）DELETE方法

DELETE方法是用來請求HTTP服務器刪除在請求消息中表明的資源。這個方法可能被人工干預或HTTP服務器上的安全設置所超越。僅當服務器同意刪除這個資源時，才會發(fā)送一個成功應答。第二十五頁，共33頁。6）TRACE方法

TRACE方法用來確保HTTP服務器所接收到的數據是正確的。TRACE的回答是實際的HTTP請求，允許對HTTP請求進行測試和調試。7）CONNECT方法

CONNECT方法被保留為安全接口層SSL隧道所用。返回第二十六頁，共33頁。30.5HTTP響應報文

HTTP響應報文一般都帶有實體數據，響應報文的格式如圖所示。第二十七頁，共33頁。1.狀態(tài)行(status-line)

響應信息中的狀態(tài)行由協議版本號、數字式的狀態(tài)碼(status-code)以及這個狀態(tài)碼對應的狀態(tài)短語(Reason-Phase)組成。響應信息中，狀態(tài)行以后的內容均使用MIME進行編碼。版本：HTTP1.1;HTTP1.0;HTTP0.9狀態(tài)碼：3位十進制數的狀態(tài)編碼。100~199信息200~299成功300~399重定向400~499客戶端錯500~599服務器錯狀態(tài)短語：對狀態(tài)碼的文字解釋。第二十八頁，共33頁。HTTP1.1正被定義為新的HTTP協議的標準。一些新特性已被增加到最新版本的HTTP協議中，包括如下這些：固定的連接。HTTP1.1允許在同一個連接中服務于多重請求。此協議以前的實現方法要求為每一個在一個Web頁上嵌入的圖像建立一個獨立的連接。流水線技術。這個特性允許給一個Web服務器發(fā)送附加的請求，這可在他們初始請求的回答信號到達之前發(fā)生。這將導致一個巨大的性能改進。緩沖區(qū)指針。實現緩沖區(qū)指針允許客戶和服務器的缺省緩沖區(qū)算法可以被調用或優(yōu)化。第二十九頁，共33頁。主機標題。HTTP1.1協議允許多重主機名與一個單獨的IP地址相關聯。這便除去了給一個駐留許多虛擬服務器的Web服務器配置多個IP地址的需要了。這個主機標題用來確定請求應該