寫在前面的話：喜歡這個比喻：如果說http是網際網路的信使，那麼http報文就是它用來搬東西的包裹。
http是乙個應用層協議，研究它的內容的確很枯燥，沒啥意思，都是規定好的，我們只需要知道是什麼就好了，在此基礎上如果能從協議的設計中得到一些實際開發中的啟發，那就更好了。
這篇算是我的讀書筆記吧，看過權威指南的同學都知道，基本上是照抄過來的（不過絕對沒有 ctrl-c 哦），
這裡順帶捎帶一句，讀書筆記只是乙個引子，詳細內容還得從書中找，或者通過引子能回憶起詳細內容，我這種讀書筆記就有點粗放型了，誰讓咱智商捉急呢。
我建議讀書筆記使用某種思維導圖工具比較好，邏輯性也清晰。
帶著問題在書中找答案：
沒有目錄的博文（讀書筆記）都是耍流氓：
報文是如何流動的？
http報文的三個組成部分
請求和響應報文之間的區別
請求報文支援的各種功能
和響應報文一起返回的各種狀態碼都什麼意思？
各種各樣的http首部都是用來做什麼的？
http報文是在http應用程式之間傳送的資料塊。這些資料塊以文字形式的元資訊開頭，描述了報文的內容和含義，後面跟著的是可選的資料部分。報文在客戶端、伺服器和**之間流動。術語「流入」、「流出」、「上游」和「下游」都是用來描述報文方向的。
流入和流出描述事務處理的方向，報文流入伺服器，處理完成之後，會流出伺服器，流入客戶端。
上游和下游，所有報文的傳送者都在接收者的上游(upstream)。不管傳送者和接收者是伺服器還是客戶端或者是**。
http報文是簡單的格式化資料塊。每條報文都包含來自客戶端的請求，或者一條來自伺服器的響應。
它們由三個部分組成：對報文進行描述的起始行（start line）、包含屬性的首部塊（header）以及可選的、包含資料的主體（body）部分。
起始行和首部是由行分隔的ascii文字。每行都以乙個由兩個字元組成的行終止序列作為結束，其中包括乙個回車符（ascii碼13）和乙個換行符（ascii碼10）。這個終止序列可以寫做crlf。
報文的主體是乙個可選的資料塊。與起始行和首部不同的是，主體可以包含文字或二進位制資料，也可以為空。
所有的http報文都可以分為兩類：請求報文和響應報文。
請求報文會向web伺服器請求乙個動作，響應報文會將請求的結果返回給客戶端。兩種報文的結構相同。
請求報文的格式
響應報文的格式
對各個部分的簡要描述
方法(method)
客戶端希望伺服器對資源執行的動作。比如get、head或post等
請求url(request-url)
命名了所請求的資源，或者url路徑元件的完整url。如果直接與伺服器進行對話，只要url的路徑元件是資源的絕對路徑，通常就不會有什麼問題。
版本(version)
報文所使用的http版本，其格式看起來是這樣：http/.主次版本號都要是整數。
狀態碼(status-code)
這三位數字描述了請求過程中所發生的情況。每個狀態碼的第一位數字用來描述狀態的一般類別（成功、出錯）。
原因短語(reason-phrase)
數字狀態碼的可讀版本，包含行終止序列之前的所有文字。
首部(header)
可以有零個或者多個首部，每個首部都包含乙個名字，後面跟著乙個冒號，然後是乙個可選空格，接著是乙個值，最後是乙個crlf（行終止序列）。
首部是由乙個空行(crlf)結束的，表示了首部列表的結束和實體主體部分的開始。
主體部分(entity-body)
實體的主體部分包含乙個由任意資料組成的資料塊。並不是所有的報文都包含實體的主體部分。
請求報文支援的方法有很多，但並不是每台伺服器都實現了所有的方法，下面介紹一些常用的方法。
get，通常用於請求伺服器傳送某個資源。http/1.1 要求伺服器實現此方法。
head，該方法和get方法的行為類似，但伺服器在響應中只返回首部。不會返回實體的主體部分。那麼問題來了，沒有主體部分的響應報文我們有什麼用呢？
在不獲取資源的情況下了解資源的情況（判斷資源型別）
通過檢視響應中的狀態碼，看看某個物件是否存在
通過檢視首部，測試資源是否被修改了。
伺服器開發者必須確保返回的首部和get請求返回報文的首部完全相同。http/1.1要求伺服器必須實現此方法。
put，與get從伺服器讀取文件相反，put方法會向伺服器寫入文件。put方法的語義是讓伺服器用請求的主體部分來建立乙個由所請求的url命名的新文件，或者，如果那個url已經存在的話，就用這個主體來替代它。
post，此方法起初是用來向伺服器輸入資料的。實際上，通常會用它來支援html的表單。表單中填好的資料通常會被送給伺服器，然後由伺服器將其傳送到它要去的地方
trace，客戶端發起乙個請求時，這個請求可能要穿過防火牆、**、閘道器或者其他一些應用程式。每個中間節點都可能會修改原始的http請求。trace方法允許客戶端在最終將請求傳送給伺服器時，看看請求變成了什麼樣子。
trace請求會在目的伺服器端發起乙個「環迴」診斷。行程最後一站的伺服器會彈回一條trace響應，並在響應主體中攜帶它收到的原始請求報文。這樣客戶端可以檢視在所有中間http應用程式組成的請求/響應鏈上，原始報文如何被修改過或者毀壞過。
該方法主要用於驗證請求是否如願的穿過了請求/響應鏈。它假定中間應用程式對不同型別的請求的處理是相同的，trace方法並不提供區別這些方法的機制，通常，中間應用程式會自行決定對trace請求的處理方式。
trace請求中不能帶有實體的主體部分。trace響應的實體主體部分包含了響應伺服器收到的請求的精確副本。
delete方法，請伺服器刪除url指定的資源。但是，客戶端應用無法保證刪除操作一定會執行。http規範允許伺服器在不通知客戶端的情況下撤銷請求。
http狀態碼被分為5大類，其中100~199是資訊性狀態碼，200~299是成功狀態碼，300~399是重定向狀態碼，400~499是客戶端錯誤狀態碼，500~599是伺服器錯誤狀態碼。
每個狀態碼的意思我覺得沒有必要一一枚舉出來，也沒必要全記住，記住幾個常見的就好了，其他的用的時候再查。書就是用來查的麼 : )
首部和方法配合工作，共同決定了客戶端和伺服器能做什麼事情。
在請求和響應報文中都可以用首部來提供資訊，有些首部是某種報文專用的，有些是通用的。首部可以分為五個主要型別。
通用首部：客戶端和伺服器都可以使用的通用首部。可以在客戶端、伺服器和其他應用程式之間提供一些非常有用的通用功能。比如：date 首部，說明構建報文的時間和日期。
請求首部：請求報文特有的，它們為伺服器提供了一些額外資訊，比如客戶端希望接收什麼型別的資料。
響應首部：響應報文特有的，為客戶端提供資訊，比如客戶端在與哪種型別的伺服器進行互動。
實體首部：用於應對主體部分的首部。比如，用實體首部來說明主體部分的資料型別。content-type
擴充套件首部：非標準的首部，有應用程式開發者建立。
寫在後面的話，協議是枯燥的，只是一種規定，我分享這篇博文主要是我的讀書筆記，當然可能作為筆記內容多了點，其實書中說的已經很言簡意賅了，有興趣的同學可以針對章節選擇性的閱讀。
HTTP報文解析
超文字傳輸協議 hypertext transfer protocol，簡稱http 是應用層協議。http 是一種請求 響應式的協議，即乙個客戶端與伺服器建立連線後，向伺服器傳送乙個請求 伺服器接到請求後，給予相應的響應資訊。http請求報文分為三部分 請求行 請求頭部 請求包體 由方法字段 ur...
HTTP報文分析
請求報文 1 請求行 請求方法 get post等 請求uri http 協議版本 2 請求頭 header 由關鍵字 值對組成，每行一對，關鍵字和值用英文冒號 分隔 中間有空行 最後乙個請求頭之後是乙個空行，傳送回車符和換行符，通知伺服器以下不再有請求頭。3 請求資料 body 請求資料不在get...
HTTP報文結構
b s網路架構的核心是http。要理解http，最重要的就是熟悉http中的http header，http header控制著網際網路上成千上萬的使用者的資料傳輸。最關鍵的是，它控制著使用者瀏覽器行為和伺服器的執行邏輯。http有兩類報文 請求報文和響應報文 由於http是面向正文的 text o...