HTTP報文：它是HTTP應用程序之間發送的數據塊。這些數據塊以一些文本形式的元信息開頭，這些信息描述了報文的內容及含義，后面跟着可選的數據部分。這些報文都是在客戶端、服務器和代理之間流動。
HTTP報文的流動方向：一次HTTP請求，HTTP報文會從“客戶端”流到“代理”再流到“服務器”，在服務器工作完成之后，報文又會從“服務器”流到“代理”再流到“客戶端”
報文的語法：所有的HTTP報文都可以分為兩類，請求報文和響應報文。請求和響應報文的基本報文結構大致是相同的，只有起始行的語法有所不同。
請求報文：它會向Web服務器請求一個動作
請求報文的格式：
起始行： <method> <request-URL> <version>
頭部： <headers>
主體： <entity-body>
響應報文：它會將請求的結果返回給客戶端。
響應報文的格式：
起始行： <version> <status> <reason-phrase>
頭部： <headers>
主體： <entity-body>
下面是對各部分的簡要描述：
1、方式(method)：客戶端希望服務器對資源執行的動作，是一個單獨的詞，比如，GET、POST或HEAD
2、請求URL(request-URL)：要直接與服務器進行對話，只要請求URL是資源的絕對路徑就可以了，服務器可以假定自己是URL的主機/端口
3、版本(version)：報文所使用的HTTP版本。其格式：HTTP/<主要版本號>.<次要版本號>
4、狀態碼(status-code)：狀態碼是三位數字，描述了請求過程中所發生的情況。每個狀態碼的第一位數字都用於描述狀態的一般類別(比如，“成功”、“出錯”等等)
5、原因短語(reason-phrase)：數字狀態碼的可讀版本，包含行終止序列之前的所有文本。原因短語只對人類有意義，因此，盡管響應行HTTP/1.0 200 NOT OK和HTTP/1.0 200 OK中原因短語的含義不同，但同樣都會被當作成功指示處理
6、頭部(header)：可以有零個或多個頭部，每個首部都包含一個名字，后面跟着一個冒號(:)，然后是一個可選的空格，接着是一個值，最后是一個CRLF首部是由一個空行(CRLF)結束的，表示了頭部列表的結束和實體主體部分的開始
7、實體的主體部分(entity-body)：實體的主體部分包含一個由任意數據組成的數據塊，並不是所有的報文都包含實體的主體部分，有時，報文只是以一個CRLF結束。
展示一些假想的請求和響應報文：
HTTP報文的組成部分：對報文進行描述的起始行、包含屬性的頭部塊、可選的，包含數據的主體部分
1、起始行：所有的HTTP報文都以一個起始行作為開始。請求報文的起始行說明了要做些什么。響應報文的起始行說明發生了什么。
請求報文的起始行：該行包含了一個方法和一個請求的URL，還包含HTTP 的版本。
響應報文的起始行：該行包含了響應報文使用的HTTP版本、數字狀態碼、原因短語。
2、頭部：HTTP首部字段向請求和響應報文中添加了一些附加信息。本質上來說，它們只是一些名/值對的列表。頭部和協議配合工作，共同決定了客戶端和服務器能做什么事情。
頭部的分類：
通用頭部：既可以出現在請求報文中，也可以出現在響應報文中，它提供了與報文相關的最基本的信息
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、實體的主體部分：該部分其實就是HTTP要傳輸的內容，是可選的。HTTP報文可以承載很多類型的數字數據，比如，圖片、視頻、HTML文檔電子郵件、軟件應用程序等等。
HTTP方法：並不是每個服務器都實現了所有的方法。即使服務器實現了所有這些方法，這些方法的使用很可能也是受限的。例如，支持DELETE方法或PUT方法的服務器可能並不希望任何人都能夠刪除或存儲資源，這些限制通常都是在服務器的配置中進行設置的。
常用的HTTP方法：
GET方法：通常用於請求服務器發送某個資源。不包含主體
HEAD方法：與GET方法類似，但服務器在響應中只返回首部，使用HEAD方法可以，在不獲取資源的情況下了解資源的情況(比如，判斷其類型)；通過查看響應中的狀態碼，看看某個對象是否存在；通過查看首部，測試資源是否被修改了；不包含主體
POST方法：該方法是用來向服務器發送數據的，常用於HTML表單，包含主體
PUT方法：該方法的語義就是讓服務器用請求的主體部分來創建一個由所請求的URL命名的新文檔，如果那個URL已經存在的話，就用這個主體來替代它。包含主體
TRACE方法：主要用於驗證請求是否如願穿過了請求/響應鏈，不包含主體
OPTIONS方法：決定可以在服務器上執行那些方法，不包含主體
DELETE方法：該方法就是請服務器刪除請求URL所指定的資源，但是客戶端應用程序無法保證刪除操作一定會被執行，因為HTTP規范允許服務器在不通知客戶端的情況下撤銷請求，不包含主體
擴展方法：指的是沒有在HTTP/1.1規范中定義的方法，這些方法為開發者提供了一種擴展這些HTTP服務能力的手段。
狀態碼：HTTP狀態碼被分成了五大類。狀態碼為客戶端提供了一種理解事務處理結果的便捷方式。
1、100~199(信息性狀態碼)：HTTP/1.1向協議中引入了信息性狀態碼
2、200~299(成功狀態碼)：客戶端發起請求時，這些請求通常都是成功的。服務器有一組用來表示成功的狀態碼，分別對應於不同類型的請求
3、300~399(重定向狀態碼)：重定向狀態碼要么告知客戶端使用替代位置來訪問他們所感興趣的資源，要么就提供一個替代的響應而不是資源的內容
4、400~499(客戶端錯誤狀態碼)：有時客戶端會發送一些服務器無法處理的東西。瀏覽網頁時，我們都看到過臭名昭著的404 Not Found錯誤碼，這只是服務器在告訴我們，它對我們請求的資源一無所知
5、500~599(服務器錯誤狀態碼)：有時客戶端發送了一條有效請求，服務器自身卻出錯了，這些會返回5xx狀態碼