報文：

　　簡單來說，報文就是也就是HTTP報文，作用是在各個系統之間進行和響應時用來交換與傳輸的資料單元，即站點一次性要傳送的資料塊，這些資料塊以一些文字形式的元資訊開頭，這些資訊描述了報文的內容及含義，報文包含了將要傳送的完整的資料資訊，還需要遵守規定好的格式。

　　另外，報文也是網路傳輸的單位，傳輸過程中會不斷的封裝成分組、包、幀來傳輸，封裝的方式就是新增一些資訊段，那就是報文頭以一定格式組織起來的資料。

HTTP的請求順序：

　　一次HTTP請求，HTTP報文會從"客戶端"傳送到"代理"再傳送到"伺服器"，再伺服器工作完成之後，報文又會從"伺服器"傳送到"代理"

HTTP請求報文和響應報文：

　　HTTP報文是面向文字的，所有的HTTP報文都可以分為兩類，請求報文和響應報文，請求和響應報文的基本報文結構大致是相同的，只有起始行的語法會有所不同。

一、HTTP請求報文：

　　它會向Web伺服器請求一個動作，一個HTTP請求報文一般由請求行、請求頭部、請求資料這麼幾個部分所組成如圖：

　　請求報文的格式：

　　　　請求行：    <mehod><request-URL><version>

　　　　請求頭部：

　　　　請求資料：<entity-body>

　　各部分的簡要描述：

　　1、method（方式）：客戶端希望伺服器對資源執行的動作，比如GET/POST/HEAD

　　2、請求URL（request-URL）：要直接與伺服器進行對話，只要請求URL是資源的絕對路徑就可以了，伺服器可以假定自己是URL的主機/埠

　　3、版本（version）：報文所使用的HTTP版本，其格式：HTTP/<主要版本號><次要版本號>

　　4、實體的主體部分（entity-body）：實體的主體部分包含一個由任意資料組成的資料塊，並不是所有的報文都包含實體的主體部分，有時，報文只是以一個

　　5、頭部(header)：可以有零個或多個頭部，每個首部都包含一個名字，後面跟著一個冒號(:)，然後是一個可選的空格，接著是一個值，最後是一個CRLF首部是由一個空行(CRLF)結束的，表示了頭部列表的結束和實體主體部分的開始

1>請求行：

　　請求行由請求方法欄位、URL欄位和HTTP協議版本欄位三個欄位組成，它們用空格分隔，例如，GET/index.html HTTP/1.1，HTTP協議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

　　HEAD就像GET，只不過服務端接收到HEAD請求後只返回響應頭，而不會發送響應內容，當我們只需要檢視某個頁面的狀態的時候，使用HEAD是非常高效的，因為在傳輸的過程中省去了頁面內容。

　　下面來舉個例子：

　　　　Request URL:https://www.baidu.com/

　　　　Requset Method:GET

　　　　Status Code:200 OK

　　　　Remote Address:172.31.1.246:8080

2>請求頭部：

　　請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號“：”分隔。頭部和協議配合工作，共同決定了客戶端和伺服器能做什麼事情，請求頭部通知伺服器有關客戶端請求的資訊，頭部主要分為了：通用頭部/請求頭部/響應頭部/實體首部。

　　通用頭部：既可以出現在請求報文中，也可以出現在響應報文中，它提供了與報文相關的最基本的資訊

　　　　　　　Connection：允許客戶端和伺服器指定與請求/響應連線有關的選項

　　　　　　　Date：提供日期和時間標誌，說明報文是什麼時間建立的

　　　　　　　MIME-Version：給出了傳送端使用的MIME版本

　　　　　　　Trailer：如果報文采用了分塊傳輸編碼方式，就可以用這個首部列出位於報文拖掛部分的首部集合

　　　　　　　Transfer-Encoding：告知接收端為了保證報文的可靠傳輸，對報文采用了什麼編碼方式

　　　　　　　Update：給出了傳送端可能想要“升級”使用的新版本或協議

　　　　　　　Via：顯示了報文經過的中間節點(代理、閘道器)

　　　　　　　Cache-Control：用於隨報文傳送快取指示

　　請求頭部：請求頭部是隻在請求報文中有意義的頭部。用於說明是誰或什麼在傳送請求、請求源自何處，或者客戶端的喜好及能力。

　　　　　　　Client-IP：提供了執行客戶端的機器的IP地址

　　　　　　　From：提供了客戶端使用者的E-mail地址

　　　　　　　Host：給出了接收請求的伺服器的主機名和埠號

　　　　　　　Referer：提供了包含當前請求URI的文件的URL

　　　　　　　UA-Color：提供了與客戶端顯示器的顯示顏色有關的資訊

　　　　　　　UA-CPU：給出了客戶端CPU的型別或製造商

　　　　　　　UA-OS：給出了執行在客戶端機器上的作業系統名稱及版本

　　　　　　　UA-Pixels：提供了客戶端顯示器的畫素資訊

　　　　　　　User-Agent：將發起請求的應用程式名稱告知伺服器       

　　　　　　　Accept：告訴伺服器能夠傳送哪些媒體型別

　　　　　　　Accept-Charset：告訴伺服器能夠傳送哪些字符集

　　　　　　　Accept-Encoding：告訴伺服器能夠傳送哪些編碼方式

　　　　　　　Accept-Language：告訴伺服器能夠傳送哪些語言

　　　　　　　TE：告訴伺服器可以使用那些擴充套件傳輸編碼

　　　　　　　Expect：允許客戶端列出某請求所要求的伺服器行為

　　　　　　　Range：如果伺服器支援範圍請求，就請求資源的指定範圍

　　　　　　　If-Match：如果實體標記與文件當前的實體標記相匹配，就獲取這份文件

　　　　　　　If-Modified-Sinec：除非在某個指定的日期之後資源被修改過，否則就限制這個請求

　　　　　　　If-None-Match：如果提供的實體標記與當前文件的實體標記不相符，就獲取文件

　　　　　　　If-Range：允許對文件的某個範圍進行條件請求

　　　　　　　If-Unmodified-Since：除非在某個指定日期之後資源沒有被修改過，否則就限制這個請求

　　　　　　　Authorization：包含了客戶端提供給伺服器，以便對其自身進行認證的資料

　　　　　　　Cookie：客戶端用它向伺服器傳送資料

　　　　　　　Cookie2：用來說明請求端支援的cookie版本

　　　　　　　Max-Forward：在通往源端伺服器的路徑上，將請求轉發給其他代理或閘道器的最大次數

　　　　　　　Proxy-Authorization：這個首部在與代理進行認證時使用的

　　　　　　　Proxy-Connection：這個首部是在與代理建立連線時使用的

　　響應頭部：響應頭部為客戶端提供了一些額外資訊，比如誰在傳送響應、響應者的功能，甚至與響應相關的一些特殊指令

　　　　　　　Age：(從最初建立開始)響應持續時間

　　　　　　　Public：伺服器為其資源支援的請求方法列表

　　　　　　　Retry-After：如果資源不可用的話，在此日期或時間重試

　　　　　　　Server：伺服器應用程式軟體的名稱和版本

　　　　　　　Title：對HTML文件來說，就是HTML文件的源端給出的標題

　　　　　　　Warning：比原因短語更詳細一些的警告報文

　　　　　　　Accept-Ranges：對此資源來說，伺服器可接受的範圍型別

　　　　　　　Vary：伺服器會根據這些首部的內容挑選出最適合的資源版本傳送給客戶端

　　　　　　　Proxy-Authenticate：來自代理的對客戶端的質詢列表

　　　　　　　Set-Cookie：在客戶端設定資料，以便伺服器對客戶端進行標識

　　　　　　　Set-Cookie2：與Set-Cookie類似

　　　　　　　WWW-Authenticate：來自伺服器的對客戶端的質詢列表

　　實體首部：描述主體的長度和內容，或者資源自身

　　　　　　　Allow：列出了可以對此實體執行的請求方法

　　　　　　　Location：告知客戶端實體實際上位於何處，用於將接收端定向到資源的位置(URL)上去

　　　　　　　Content-Base：解析主體中的相對URL時使用的基礎URL

　　　　　　　Content-Encoding：對主體執行的任意編碼方式

　　　　　　　Content-Language：理解主體時最適宜使用的自然語言

　　　　　　　Content-Length：主體的長度

　　　　　　　Content-Location：資源實際所處的位置

　　　　　　　Content-MD5：主體的MD5校驗和

　　　　　　　Content-Range：在整個資源中此實體表示的位元組範圍

　　　　　　　Content-Type：這個主體的物件型別

　　　　　　　ETag：與此實體相關的實體標記

　　　　　　　Expires：實體不再有效，要從原始的源端再次獲取實體的日期和時間

　　　　　　　Last-Modified：這個實體最後一次被修改的日期和時間

　　擴充套件首部：規範中沒有定義的新首部，開發者可以自定義一個首部的值/對

3>請求的資料

　　請求資料不在GET方法中使用，而是在POST方法中使用，POST方法適用於需要客戶填寫表單的場合，與請求資料相關的最常使用的請求頭是Content-Type和Content-Length。

二、HTTP響應報文：

　　它會將請求的結果返回給客戶端，這裡也是由三部分組成：狀態行、訊息報頭、響應正文。

　　響應報文的格式：

　　　　狀態行：     <version> <status> <reason-phrase>

　　　　訊息頭部：<headers>

      　　 響應正文：<entity-body>

正如你所見，在響應中唯一真正的區別在於第一行中用狀態資訊代替了請求資訊。

　　各部分的簡要描述：

　　1、狀態碼(status-code)：狀態碼是三位數字，描述了請求過程中所發生的情況。每個狀態碼的第一位數字都用於描述狀態的一般類別(比如，“成功”、“出錯”等等)

　　2、原因短語(reason-phrase)：數字狀態碼的可讀版本，包含行終止序列之前的所有文字。原因短語只對人類有意義，因此，儘管響應行HTTP/1.0 200 NOT OK和HTTP/1.0 200 OK中原因短語的含義不同，但同樣都會被當作成功指示處理

　　狀態行的格式如下：

　　HTTP-Version Status-Code Reason-Phrase CRLF

　　其中，HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態程式碼；Reason-Phrase表示狀態程式碼的文字描述。狀態程式碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。

 　　1xx：指示資訊--表示請求已接收，繼續處理。

 　　2xx：成功--表示請求已被成功接收、理解、接受。

　　 3xx：重定向--要完成請求必須進行更進一步的操作。

　　 4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。

　　 5xx：伺服器端錯誤--伺服器未能實現合法的請求。

　　常見狀態程式碼、狀態描述的說明如下：

　　 200 OK：客戶端請求成功。

　　 400 Bad Request：客戶端請求有語法錯誤，不能被伺服器所理解。

 　　401 Unauthorized：請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用。

 　　403 Forbidden：伺服器收到請求，但是拒絕提供服務。

　　 404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。

 　　500 Internal Server Error：伺服器發生不可預期的錯誤。

 　　503 Server Unavailable：伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常，舉個例子：HTTP/1.1 200 OK（CRLF）。

　　下面我們來說一下在傳輸中常見的HTTP方法：

1> GET方法：通常用於請求伺服器傳送某個資源。不包含主體

HEAD方法：與GET方法類似，但伺服器在響應中只返回首部，使用HEAD方法可以，在不獲取資源的情況下了解資源的情況(比如，判斷其型別)；通過檢視響應中的狀態碼，看看某個物件是否存在；通過檢視首部，測試資源是否被修改了；不包含主體

2> POST方法：該方法是用來向伺服器傳送資料的，常用於HTML表單，包含主體

3> PUT方法：該方法的語義就是讓伺服器用請求的主體部分來建立一個由所請求的URL命名的新文件，如果那個URL已經存在的話，就用這個主體來替代它。包含主體

4> TRACE方法：主要用於驗證請求是否如願穿過了請求/響應鏈，不包含主體

5> OPTIONS方法：決定可以在伺服器上執行那些方法，不包含主體

6> DELETE方法：該方法就是請伺服器刪除請求URL所指定的資源，但是客戶端應用程式無法保證刪除操作一定會被執行，因為HTTP規範允許伺服器在不通知客戶端的情況下撤銷請求，不包含主體

7> 擴充套件方法：指的是沒有在HTTP/1.1規範中定義的方法，這些方法為開發者提供了一種擴充套件這些HTTP服務能力的手段。

　　就這些方法之上，最後我們再說一下關於HTTP請求中，GET與POST的區別：

1> 資料傳輸方法不同：

GET提交，請求的資料會附在URL之後， 以?分割URL和傳輸資料，多個引數用&連線;例如：login.action?name=hyddd& password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果資料是英文字母/數字，原樣傳送，如果是空格，轉換為+，如果是中文/其他字元，則直接把字串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進製表示的ASCII。

     POST提交：把提交的資料放置在是HTTP包的包體＜request-body＞中。

  因此，GET提交的資料會在位址列中顯示出來，而POST提交，位址列不會改變。

2> 傳輸資料的大小：

     首先宣告,HTTP協議沒有對傳輸的資料大小進行限制，HTTP協議規範也沒有對URL長度進行限制。 而在實際開發中存在的限制主要有：

    GET:特定瀏覽器和伺服器對URL長度有限制， 因此對於GET提交時，傳輸資料就會受到URL長度的限制。

     POST:由於不是通過URL傳值，理論上資料不受限。但實際各個WEB伺服器會規定對post提交資料大小進行限制，Apache、IIS6都有各自的配置。

3> 安全性：

    POST的安全性相比來說要比GET的安全性高，注意，只是相比來說，主要因為GET提交的資料明文出現在URL上，所以安全性低。