HTTP響應報文與工做原理詳解

HTTP 是一種請求/響應式的協議，即一個客戶端與服務器創建鏈接後，向服務器發送一個請求;服務器接到請求後，給予相應的響應信息。

超文本傳輸協議(Hypertext Transfer Protocol，簡稱HTTP)是應用層協議。HTTP 是一種請求/響應式的協議，即一個客戶端與服務器創建鏈接後，向服務器發送一個請求;服務器接到請求後，給予相應的響應信息。

HTTP 請求報文

HTTP 請求報文由請求行、請求頭部、空行 和 請求包體 4 個部分組成，以下圖所示：

 

下面對請求報文格式進行簡單的分析：

請求行：請求行由方法字段、URL 字段 和HTTP 協議版本字段 3 個部分組成，他們之間使用空格隔開。經常使用的 HTTP 請求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT;

 

● GET：當客戶端要從服務器中讀取某個資源時，使用GET 方法。GET 方法要求服務器將URL 定位的資源放在響應報文的數據部分，回送給客戶端，即向服務器請求某個資源。使用GET 方法時，請求參數和對應的值附加在 URL 後面，利用一個問號(「?」)表明URL 的結尾與請求參數的開始，傳遞參數長度受限制。例如，/index.jsp?id=100&op=bind。

 

● POST：當客戶端給服務器提供信息較多時可使用POST 方法，POST 方法向服務器提交數據，好比完成表單數據的提交，將數據提交給服務器處理。GET 通常用於獲取/查詢資源信息，POST 會附帶用戶數據，通常用於更新資源信息。POST 方法將請求參數封裝在HTTP 請求數據中，以名稱/值的形式出現，能夠傳輸大量數據;

 

請求頭部：請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號「:」分隔。請求頭部通知服務器有關於客戶端請求的信息，典型的請求頭有：

空行：最後一個請求頭以後是一個空行，發送回車符和換行符，通知服務器如下再也不有請求頭;

請求包體：請求包體不在 GET 方法中使用，而是在POST 方法中使用。POST 方法適用於須要客戶填寫表單的場合。與請求包體相關的最常使用的是包體類型 Content-Type 和包體長度 Content-Length;

 

 

 

HTTP 響應報文

HTTP 響應報文由狀態行、響應頭部、空行 和 響應包體 4 個部分組成，以下圖所示：

下面對響應報文格式進行簡單的分析：

狀態行：狀態行由 HTTP 協議版本字段、狀態碼和狀態碼的描述文本 3 個部分組成，他們之間使用空格隔開;

響應頭部：響應頭可能包括：

    Location：Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，爲了讓客戶端重定向到這個頁面新的位置，服務器端能夠發回Location響應報頭後使用重定向語句，讓客戶端去訪問新的域名所對應的服務器上的資源;

 

    Server：Server 響應報頭域包含了服務器用來處理請求的軟件信息及其版本。它和 User-Agent 請求報頭域是相對應的，前者發送服務器端軟件的信息，後者發送客戶端軟件(瀏覽器)和操做系統的信息。

Vary：指示不可緩存的請求頭列表;

    Connection：鏈接方式;

    對於請求來講：close(告訴 WEB 服務器或者代理服務器，在完成本次請求的響應後，斷開鏈接，不等待本次鏈接的後續請求了)。keepalive(告訴WEB服務器或者代理服務器，在完成本次請求的響應後，保持鏈接，等待本次鏈接的後續請求);

    對於響應來講：close(鏈接已經關閉); keepalive(鏈接保持着，在等待本次鏈接的後續請求); Keep-Alive：若是瀏覽器請求保持鏈接，則該頭部代表但願WEB 服務器保持鏈接多長時間(秒);例如：Keep-Alive：300;

    WWW-Authenticate：WWW-Authenticate響應報頭域必須被包含在401 (未受權的)響應消息中，這個報頭域和前面講到的Authorization 請求報頭域是相關的，當客戶端收到 401 響應消息，就要決定是否請求服務器對其進行驗證。若是要求服務器對其進行驗證，就能夠發送一個包含了Authorization 報頭域的請求;

 

    `空行：最後一個響應頭部以後是一個空行，發送回車符和換行符，通知服務器如下再也不有響應頭部。

響應包體：服務器返回給客戶端的文本信息;

 

 

HTTP 工做原理

HTTP 協議採用請求/響應模型。客戶端向服務器發送一個請求報文，服務器以一個狀態做爲響應。

如下是 HTTP 請求/響應的步驟：

HTTP 無狀態性

    HTTP 協議是無狀態的(stateless)。也就是說，同一個客戶端第二次訪問同一個服務器上的頁面時，服務器沒法知道這個客戶端曾經訪問過，服務器也沒法分辨不一樣的客戶端。HTTP 的無狀態特性簡化了服務器的設計，使服務器更容易支持大量併發的HTTP 請求。

 

HTTP 持久鏈接

    HTTP1.0 使用的是非持久鏈接，主要缺點是客戶端必須爲每個待請求的對象創建並維護一個新的鏈接，即每請求一個文檔就要有兩倍RTT 的開銷。由於同一個頁面可能存在多個對象，因此非持久鏈接可能使一個頁面的下載變得十分緩慢，並且這種短鏈接增長了網絡傳輸的負擔。HTTP1.1 使用持久鏈接keepalive，所謂持久鏈接，就是服務器在發送響應後仍然在一段時間內保持這條鏈接，容許在同一個鏈接中存在屢次數據請求和響應，即在持久鏈接狀況下，服務器在發送完響應後並不關閉TCP 鏈接，而客戶端能夠經過這個鏈接繼續請求其餘對象。

HTTP/1.1 協議的持久鏈接有兩種方式：

●     非流水線方式：客戶在收到前一個響應後才能發出下一個請求;

●     流水線方式：客戶在收到 HTTP 的響應報文以前就能接着發送新的請求報文;

 

最後給出一個具體例子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Remote Address:116.57.254.104:80    Request URL:http: //hr.tencent.com/    Request Method:GET    Status Code:200 OK         Request Headers    GET / HTTP/1.1    Host: hr.tencent.com    Connection: keep-alive    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8    User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36    Accept-Encoding: gzip,deflate,sdch    Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4    Cookie: pgv_pvi=2098703360; PHPSESSID=bc7onl0dojbsatscsfv79pds77; pgv_info=ssid=s1454606128;              pgv_pvid=926725350; ts_uid=4084753309         Response Header    HTTP/1.1 200 OK    Server: nginx    Date: Mon, 26 Jan 2015 01:09:10 GMT    Content-Type: text/html;charset=utf-8    Content-Length: 3631    Connection: keep-alive    X-Powered-By: PHP/5.3.10    Expires: Thu, 19 Nov 1981 08:52:00 GMT    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0    Pragma: no-cache    Vary: Accept-Encoding    Content-Encoding: gzip

從請求報文能夠知道：

1	GET / HTTP/1.1

  

請求方法 GET 表示一個讀取請求，將從服務器得到網頁數據，/表示URL 的路徑，URL 老是以/開頭，/就表示首頁，最後的HTTP/1.1 指示採用的 HTTP 協議版本是 1.1;請求域名以下所示：

1	Host: hr.tencent.com

 

響應報文以下：

1	HTTP/1.1 200 OK   Server: nginx

  

原文來自：http://network.51cto.com/art/201501/464513_1.htm