本文為《三萬長文50+趣圖帶你領悟web編程的內功心法》第三個章節，

3、HTTP/1.1報文詳解

在RFC2616中心詳細的描述了HTTP/1.1^[1]的報文，感興趣的朋友也可以前往閱讀，

HTTP是基于TCP的，HTTP作為應用層協議，會在TCP/IP協議堆疊往下傳遞的時候，不斷封裝資料幀，如下圖：

上面HTTP正文即是以我們HTTP報文格式來組織的，下面我們看看具體的HTTP報文的格式，

3.1、HTTP報文組成部分

HTTP請求和回應都使用如下通用的格式：

• start-line：起始行，起始行可以為以下兩者之一：

  • Request-Line：請求行，如：

    • GET /hello-world2.html HTTP/1.1
      

  • Status-Line：狀態行，如：

    • HTTP/1.1 200 OK
      

• *(message-header CRLF)：0個或者多個訊息頭；

• CRLF：一個空行；

• [message-body]：可選的訊息體；

可以分別把請求報文和回應報文分開來描述：

請求報文

回應報文

可以發現，請求報文和回應報文格式就起始行不一樣，

下面我們逐個來介紹，

為了盡可能保證內容的準確性，下面報文各種欄位說明部分內容，大部分整理自RFC2616和MDN web docs：

• Hypertext Transfer Protocol -- HTTP/1.1 2616^[1:1]
• HTTP. MDN web docs^[2]
• 《HTTP權威指南》

以上資料內容有沖突的，以RFC2616的為準，

3.2、請求行

請求行格式：

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

3.2.1、Method

方法是區分大訊息的，以下是常用的方法：

另外，服務器還可以實作一些自己的請求方法，這些附加的方法是對HTTP規范的擴展，因此也成為擴展方法，

extension-method = token

請求可能的回傳結果：

• 405：表示請求的方法不被允許，這個時候服務器回應頭會回應當前資源允許的方法，如：

  • Allow: GET, HEAD, PUT
    

• 501：代表原服務器的該方法未能被識別或者未實作；

下面逐個方法介紹下：

GET

GET方法意味著可以檢索 Request-URI標識的任何資訊，

如果Request-URI涉及到創建資料，則應該將新建的資料作為回應物體回傳，

如果請求訊息包含 If-Modified-Since，If-Unmodified-Since，If-Match，If-None_match或If-Range標頭欄位，則此時的Get為條件GET，通過使用快取標頭，可以盡可能避免不必要的網路傳輸，

如果請求標頭包含Range，則GET方法變為部分GET，

HEAD

HEAD方法與GET方法很類似，但是HEAD方法在在回應中只回傳首部，不會反悔訊息體，

這就允許客戶端再不用獲取實際資源的情況下，對資源首部進行檢查，如：

• 檢查資源是否有更新：如果獲取到的 Content-Length、Content-MD5、ETag、Last-Modified與之前獲取到的值不同，那么快取應該被視為過期；
• 查看回應狀態碼，查看資源是否存在；
• 獲取首部更多資訊，判斷資源情況，

POST

POST方法起初是用來向服務器傳輸資料的，通常用來提交HTML的表單到服務器，

PUT

PUT方法用于向服務器寫入資源，如果Request-URI對應的資源已經存在的話，就進行更新，

注意：

POST用于向服務器發送資料，PUT用于向服務器上的資源中存盤資料，

DELETE

請求服務器洗掉URL所指示的資源，但是客戶端無法保證洗掉操作一定會被執行，除非在回應式服務器打算洗掉資源或者將其移動到無法訪問的位置，可能的回應：

• 如果回應包含描述狀態的物體，則回應200（確定）；
• 如果尚未執行洗掉操作，則回應202（接受）；
• 如果已執行該操作，并且回應不包含任何物體，則回應204（無內容），

此方法的回應不可快取，

TRACE

一個請求從客戶端到服務端，中間可能會經歷各種代理、網關等程式，每個中間節點都可能修改原始HTTP請求，為此，通過TRACE，服務端會在接收到請求后反饋一個TRACE回應，并且在回應主體中攜帶它收到的原始請求報文，客戶端拿到TRACE回應，就可以進行測驗和診斷了，其中Via標頭欄位特別有用，它用于充當請求鏈的跟蹤，

可以使用Max-Forwards標頭欄位限制請求鏈的長度，這對于測驗無限回圈中轉發訊息的代理很有用，

如果請求有效，則回應應該在物體正文中包含整個請求訊息，其 Content-Type為"message/http"，對此方法的回應絕對不能快取，

TRACE允跨站點跟蹤問題，并且可能使黑客可以選擇竊取您的cookie資訊，基于安全的考慮，一般的服務器會關掉TRACE：

TraceEnable off

這樣執行TRACE會導致客戶端收到一個405不允許使用方法的狀態碼，

CONNECT

CONNECT 方法可以開啟一個客戶端與所請求資源之間的雙向溝通的通道，它可以用來創建隧道（tunnel），

例如，CONNECT 可以用來訪問采用了 SSL (HTTPS) 協議的站點，客戶端要求代理服務器將 TCP 連接作為通往目的主機隧道，之后該服務器會代替客戶端與目的主機建立連接，連接建立好之后，代理服務器會面向客戶端發送或接收 TCP 訊息流，^[3]

OPTIONS

通過該方法，可以請求服務器獲取Request-URI對應支持的各種通信選項的信息，最常見的如：詢問服務器當前URI支持哪些請求方法，

此方法回應不能快取，

方法的安全性與冪等性

所謂安全性，就是無論方法執行多少次，服務器上的資料都不會被改變，

安全方法：GET、HEAD；

不安全方法：POST、PUT、DELETE操作則會改動資料，

所謂冪等，就是多次執行一個方法，結果都是相同的，

冪等方法：GET、HEAD、PUT、DELETE；

非冪等方法：POST，

3.2.2、Request-URI

URI，Uniform Resource Identifier，請求的統一資源識別符號，

3.2.2.1、URI與URL什么關系？

我們經常會用到這兩個概念，但是他們是什么意思呢？

URI，Uniform Resource Identifier，統一資源識別符號，能夠唯一的標識網上的一個資源，比如，我的網站IT宅的Logo：

https://www.itzhai.com/resources/images/itzhai_logo_home_page.jpg

只要在世界的任何一個有網路的地方，發起請求，就可以拿到這個圖片，這個URI具有唯一性，那什么是URL呢？

URI有兩種形式：URL和URN，

URL

URL，Uniform Resource Locator，統一資源定位符，描述了一臺特定服務器上某個資源的特定位置，例如上面的鏈接就是一個統一資源定位符：

• scheme方案：指定方位資源所使用的協議型別，如HTTPS；
• 主機與埠：英特網地址，即域名，這里默認為80埠；
• 路徑：其余部分指定web服務器上的某個資源，

幾乎所有的 URI都是URL，

一個完整的URL格式如下：

• 用戶名和密碼：有寫服務器要求輸入用戶名和密碼才允許用戶訪問資料，如FTP；
• ?query 查詢字串：可以通過查詢字串進行查詢來縮小所請求資源型別的范圍；
• fragment片段：指向HTML檔案中特定的圖片或者小節，

URN

URL，Uniform Resource Name，統一資源名，作為特定內容的唯一名稱，與資源所在位置無關，也就是說，我可以給一份檔案定義一個URN，不管你把這個檔案放到哪里，有多少個URL，但是都只有唯一個URN，舉個例子，因特網標準檔案 RFC 3986不管存在哪個服務器上，都可以用唯一的URN來命名：

urn:ietf:rfc:3986

URN處于試驗階段，暫未大范圍使用，

再通俗易懂點來說：URN就相當于身份證，通過特定的規則，制定了一串唯一的字串作為你的身份證，但是沒有規定身份證一定要放在哪里，只是作為你的個人唯一憑證，URL相當于是快遞單上的地址，根據地址，快遞員一定可以把快遞送到唯一的一個目的地，

3.2.3、HTTP-Version

指定了當前請求用到的HTTP協議版本，

3.3、訊息頭^[4]

通過傳遞訊息頭(首部)，服務器和客戶端可以把自己的資訊或者是請求回應相關資訊進行傳遞，

可以把首部分為：通用首部，請求首部，回應首部，物體首部，擴展首部，下面就來詳細介紹下，

3.3.1、通用首部

有些首部，不管是請求還是回應都會出現他們的身影，我們把他們歸類為通用首部，常見通用首部如下表格所示：

3.3.2、請求首部

客戶端通過傳遞請求頭欄位，將有關請求以及有關客戶端本身的其他資訊傳遞給服務器，這些欄位充當請求修飾符，其語意等同于編程語言方法呼叫中的引數，

常見的請求頭如下：

Accept首部

條件請求首部

安全請求首部

代理請求首部

3.3.3、回應首部

協商首部

如果資源有多種表示方法，服務器可以通過協商首部來傳遞可協商資源有關的資訊，

安全回應首部

3.3.4、物體首部

用來描述HTTP報文中物體相關資訊的首部，我們成為物體首部，

內容首部

物體快取首部

物體快取首部提供與被快取物體有關的資訊，如什么時候或者如何快取，快取是否有效等，通過快取首部可以估計快取何時失效，

3.4、訊息體

3.4.1、請求訊息體

并不是所有的請求都需要body，如：GET，HEAD，DELETE，OPTIONS通產不需要body，

請求body可以分為兩類：

• Single-resource bodies，由單個檔案組成，該型別 body 由兩個 header 定義： Content-Type 和 Content-Length；
• Multiple-resource bodies，由多部分body組成，每一部分包含不同的資訊位，通常是和 HTML Forms 連系在一起，

3.4.2、回應訊息體

并不是所有的回應都有body，如 201 或 204狀態碼的回應一般不會有body，

回應body可以分為三類：

• Single-resource bodies，由已知長度的單個檔案組成，該型別 body 由兩個 header 定義：Content-Type 和 Content-Length；
• Single-resource bodies，由未知長度的單個檔案組成，通過將 Transfer-Encoding 設定為 chunked 來使用 chunks 編碼；
• Multiple-resource bodies，由多部分 body 組成，每部分包含不同的資訊段，但這是比較少見的，

3.5、狀態行

回應訊息的第一行是狀態行，由協議版本，數字狀態代碼及其關聯的文本短語組成，每個元素由SP字符分隔， 除最后的CRLF序列外，不允許CR或LF，

狀態行格式：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

3.5.1、Status-Code狀態碼和Reason-Phrase狀態描述

狀態碼是3位數的整數結果代碼，

狀態碼的第一位數字定義回應的類別， 后兩位數字沒有任何分類作用，可以分為5個類別：

• 1xx：資訊狀態碼，收到請求，繼續進行；
• 2xx：請求成功接收；
• 3xx：重定向，必須采取進一步措施才能完成請求；
• 4xx：客戶端錯誤，請求包含錯誤語法，或者不能被完成；
• 5xx：服務器錯誤，服務器無法完成看似有效的請求；

RFC中定義的狀態碼很多，這里我們列出最常見的一些狀態碼：

更多狀態碼說明：

• List of HTTP status codes^[5]
• https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status^[6]

上面我們把HTTP報文介紹了一遍，HTTP作為一個協議，只是規定了大家要遵循這樣的約定，但是具體實作的時候，還是要看應用程式的兼容程度，我們在寫程式的時候，也不要跟協議對著干，這會讓對接的同事無法理解的，

你都知道以下狀態碼的含義了嗎？

200 204 206 301 302 304 401 403 405 500 501 502 503 504

本文首次發表于: HTTP/1.1報文詳解 以及公眾號 Java架構雜談，未經許可，不得轉載，

本文為arthinking基于相關技術資料和官方檔案撰寫而成，確保內容的準確性，如果你發現了有何錯漏之處，煩請高抬貴手幫忙指正，萬分感激，

如果您覺得讀完本文有所識訓的話，可以關注我的賬號，或者點贊吧，碼字不易，您的支持就是我寫作的最大動力，再次感謝！

為了把相關系列文章收集起來，方便后續查閱，這里我創建了一個Github倉庫，把發布的文章按照分類收集起來了，感興趣的朋友可以Star跟進：

https://github.com/arthinking/java-tech-stack

關注我的博客IT宅(itzhai.com)或者公眾號Java架構雜談，及時獲取最新的文章，我將持續更新后端相關技術，涉及JVM、Java基礎、架構設計、網路編程、資料結構、資料庫、演算法、并發編程、分布式系統等相關內容，

References

• 謝希仁. 計算機網路(第6版). 電子工業出版社.
• TCP/IP詳解 卷1：協議（原書第2版）. 機械工業出版社.
• UNIX網路編程 卷1：套接字聯網API. 人民郵電出版社
• HTTP權威指南. 人民郵電出版社
• HTTP/2基礎教程. 人民郵電出版社
• 劉超. 趣談網路協議. 極客時間
• 羅劍鋒. 透視HTTP協議. 即可時間

本文同步發表于我的博客IT宅(itzhai.com)和公眾號(Java架構雜談)

作者：arthinking | 公眾號：Java架構雜談

博客鏈接：https://www.itzhai.com/articles/detailed-explanation-of-http-1-1-messages.html

著作權宣告： 著作權歸作者所有，未經許可不得轉載，侵權必究！聯系作者請加公眾號，

標籤：Java

上一篇：死磕Spring之IoC篇 - BeanDefinition 的決議階段（XML 檔案）

下一篇：Redis原始碼入門-字串sds,sdshdr