報文：
簡單來說，報文就是也就是HTTP報文，作用是在各個系統之間進行和響應時用來交換與傳輸的數據單元，即站點一次性要發送的數據塊，這些數據塊以一些文本形式的元信息開頭，這些信息描述了報文的內容及含義，報文包含了將要發送的完整的數據信息，還需要遵守規定好的格式。
另外，報文也是網絡傳輸的單位，傳輸過程中會不斷的封裝成分組、包、幀來傳輸，封裝的方式就是添加一些信息段，那就是報文頭以一定格式組織起來的數據。
HTTP的請求順序：
一次HTTP請求，HTTP報文會從"客戶端"傳送到"代理"再傳送到"服務器"，再服務器工作完成之后，報文又會從"服務器"傳送到"代理"，最后再次回到"客戶端"。
HTTP請求報文和響應報文：
HTTP報文是面向文本的，所有的HTTP報文都可以分為兩類，請求報文和響應報文，請求和響應報文的基本報文結構大致是相同的，只有起始行的語法會有所不同。
一、HTTP請求報文：
它會向Web服務器請求一個動作，一個HTTP請求報文一般由請求行、請求頭部、請求數據這么幾個部分所組成如圖：
請求報文的格式：
請求行： <mehod><request-URL><version>
請求頭部：<headers>
請求數據：<entity-body>
各部分的簡要描述：
1、method（方式）：客戶端希望服務器對資源執行的動作，比如GET/POST/HEAD
2、請求URL（request-URL）：要直接與服務器進行對話，只要請求URL是資源的絕對路徑就可以了，服務器可以假定自己是URL的主機/端口
3、版本（version）：報文所使用的HTTP版本，其格式：HTTP/<主要版本號><次要版本號>
4、實體的主體部分（entity-body）：實體的主體部分包含一個由任意數據組成的數據塊，並不是所有的報文都包含實體的主體部分，有時，報文只是以一個CRLF結束。
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上，所以安全性低。