前言

如果說 TCP/IP 協議是網際網路通訊的根基，那麼 HTTP 就是其中當之無愧的王者，小到日常生活中的遊戲，新聞，大到雙十一秒殺等都能看到它的身影，據 NetCraft 統計，目前全球至少有 16 億個網站、2 億多個獨立域名，而這個龐大網路世界的底層運轉機制就是 HTTP，可以毫不誇張的說，無 HTTP 不通訊！

畫外音: TCP/IP 協議群如下, IP 不是 IP 地址，是 Internet Protocol 的簡稱

HTTP 應用如此廣泛，我們確實必要好好學習下它，不僅有助於我們理解和解釋工作中的強制重新整理，防盜鏈等現象和原理，還讓我們在設計開源中介軟體時會有所啟發，比如在設計 MQ, Dubbo 這些元件時，第一要務就是要設計協議，在其中你或多或少能看到 HTTP 協議的影子，學習了 HTTP 能讓你在設計中介軟體等元件協議時，提供很好的思路

本文將會全面剖析 HTTP 的設計理念，助你徹底掌握 HTTP，相信看完以下問題你會手到擒來！

1. 什麼是 HTTP，它有什麼特點，為什麼說 HTTP 是萬能的
2. 為什麼說反爬是個偽命題
3. 簡要介紹一下 HTTP 0.9, 1.1, 2.0, 3.0 的特點
4. 曾經在我司有一位同事在大群裡拋了一個問題：在瀏覽器的位址列輸入圖片 url，想預覽一下圖片，結果卻變成了下載圖片，你能替他解釋一下其中的原因嗎
5. DNS 協議瞭解多少，什麼是 DNS 負載均衡
6. HTTP 1.1 唯一一個要求請求頭必傳的欄位是哪個，它有什麼作用
7. no-cache 真的是不快取的意思？你對 HTTP 的快取瞭解多少
8. 為什麼重新整理了瀏覽器器卻抓不到請求，而強制重新整理卻可以抓到，強制重新整理到底做了什麼事
9. 301 和 302 的區別是啥
10. 各種協議與 HTTP 的關係
11. 老生常談很多人的誤解：GET 和 POST 的區別是啥

本文將會從以下幾點來展開闡述 HTTP

• 什麼是 HTTP
• 與 HTTP 相關的各種協議

  • 1. URI 和 URL
  • 2. TCP/IP 協議
  • 2. DNS 協議
• HTTP 報文格式

  • 請求報文格式
  • 響應報文格式
  • 請求和響應頭
  • 常用頭欄位
• HTTP 2.0 概覽

  • 1、頭部壓縮
  • 2、二進位制格式
  • 3. 流
  • HTTP 2 的隊頭阻塞
• 總結：HTTP 的特點
• 回答開篇問題

什麼是 HTTP

HTTP 全稱 HyperText Transfer Protocol「超文字傳輸協議」,拆成三個部分來看，即「超文字」,「傳輸」,「協議」

超文字：即「超越了普通文字的文字」，即音視訊，圖片，檔案的混合體，大家常見的網頁很多就內嵌了 img, video 這些標籤解析展現而成的圖片，視訊等，除了這些超文字內容外，最關鍵的是超文字中含有超連結，超連結意味著網頁等檔案內容的超文字上可以點選連結到其他頁面上，網際網路就是通過這樣的超連結構成的。

傳輸: 傳輸意味著至少有兩個參與者，比如 A，B，這意味著 HTTP 協議是個雙向協議，一般是將「超文字」按照約定的協議以二進位制資料包的形式從 A 傳到 B 或 B 傳到 A， A <===> B，我們把發起請求的叫請求方，接到請求後返回資料的那一方稱為應答方，但需要注意的是傳輸也不限於兩個參與者，允許中間有中轉或者接力，只要參與者間遵循約定的協議即可傳輸。 如圖示：傳輸可以有多個參與者，只要遵循相應的協議即可

協議：HTTP 是一個協議，啥是協議？在日常生活中協議並不少見，比如我們租房時簽訂的租房協議，入職後和企業簽訂的勞動合同協議，「協」意味著至少有兩人蔘與，「議」意味著雙方要就某項條款達成一致，比如租房協議規定月付 xx 元，勞動合同協議規定月工資 xx 元，協議即對通訊雙方的約束，雙方按照約定傳輸資料才能進行明白對方的意思，否則便是雞同鴨講。

經過以上解釋，我們可以給 HTTP 下一個比較準確的定義了:

HTTP 是一個在計算機世界裡專門在兩點之間傳輸文字、圖片、音訊、視訊等超文字資料的約定和規範。

與 HTTP 相關的各種協議

HTTP 雖然在當今網際網路通訊中佔據統計地位，但要讓它生效還必須依賴其他協議或規範的支援

1. URI 和 URL

首先既然我們要在兩點之間傳輸超文字，那這個超文字該怎麼表示？超文字即資源，網際網路上資源這麼多，如何唯一標記網際網路上的資源。

使用 URI（Uniform Resource Identifier） 即統一資源識別符號就可以唯一定位網際網路上的資源。URI 大家比較少聽過，大家更熟悉的可能是 URL（Uniform Resource Locator），即統一資源定位符，URL 其實是 URI 的一種子集，區別就是URI 定義資源，而 URL 不單定義這個資源，還定義瞭如何找到這個資源。

URL 主要由四個部分組成：協議、主機、埠、路徑

協議：即通訊雙方指定的傳輸協議，應用最廣的當然是本文要介紹的 http 協議，除此之外還有 ftp, mailto，file 等協議。

主機名：存放資源的伺服器主機名或 IP 地址，當前有時候伺服器由於安全原因還需要對使用者進行認證，需要提供使用者名稱和密碼，此時需要在 hostname前加 username:password。

埠：整數，可選，省略時使用方案的預設埠，各種傳輸協議都有預設的埠，如 HTTP 預設用的 80 埠，HTTPS 用的 443 埠，傳輸層協議正是利用這些埠號識別本機中正在進行通訊的應用程式，並準確地將資料傳輸。

路徑：即資源在主機上的存放路徑，一般表示主機的目錄或檔案地址

parameter：用於指定特殊引數的可選項。

query：查詢字串，可選，用於給動態網頁或介面傳遞引數，可有多個引數，用“&”符號隔開，每個引數的名和值用“=”符號隔開。

fragment：瀏覽器專用，用於指定網路資源中的片斷，指定後開啟網頁可直接定位到 fragment 對應的位置。

例子如下

2. TCP/IP 協議

在上述 URL 地址中，如果你指定了「www.example.com 」 這樣的主機名，最終會被 DNS 解析成 IP 地址然後才開始通訊，為啥主機名最終要被解析成 IP 地址才能通訊呢，因為 HTTP 協議使用的是 TCP/IP 協議棧，協議棧就是這樣規定的，一起來看看 TCP/IP 協議棧各層的功能。

TCP/IP 協議棧總共有四層

1. link layer: 連結層，負責在乙太網，WIFI 這樣的底層網路上傳送原始資料包，工作在網絡卡這一層，使用 MAC 地址來標記網路上的裝置，所以也叫 MAC 層
2. Internet layer: 網路層，IP 協議即處於這一層，提供路由和定址的功能，使兩終端系統能夠互連且決定最佳路徑，並具有一定的擁塞控制和流量控制的能力。相當於傳送郵件時需要地址一般重要
3. transport layer: 傳輸層，該層的協議為應用程序提供端到端的通訊服務，這層主要有 TCP，UDP 兩個協議，TCP 提供面向連線的資料流支援、可靠性、流量控制、多路複用等服務，UDP不提供複雜的控制機制，利用 IP 提供面向無連線的簡單訊息傳輸
4. application layer: 即應用層，前面三層已經為網路通訊打下了堅實的基礎，這層可發揮的空間就大很多了，應用層協議可以想象為不同的服務，每個應用層協議都是為了解決某一類應用問題而生的，每一個服務需要用不同的協議，規定應用程序在通訊時所遵循的協議。

我們可以把前面三層認為是高速公路的基礎設施，至於要傳什麼貨物，高速公路是否要關閉等則由應用層決定。

利用 TCP/IP 協議族進行網路通訊時，會通過分層順序與對方進行通訊。每個分層中，都會對所傳送的資料附加一個首部，在這個首部中包含了該層必要的資訊，如傳送的目標地址以及協議相關資訊。

接收方收到資料後，同樣的，每一層也會解析其首部欄位，直到應用層收到相應的資料。

通過這樣分層的方式，每個層各司其職，只要管好自己的工作即可，可擴充套件性很好，比如對於 HTTP 來說，它底層可以用 TCP，也可以用 UDP 來傳輸，哪天如果再出現了更牛逼的協議，也可以替換之，不影響上下層，這就是計算機中比較有名的分層理論：沒有什麼是分層解決不了的，如果有那就再分一層。

IP 包的首部中定義了32 位的源 IP 地址和目的 IP 地址，如下圖所示址

所以應用層在請求傳輸資料時必須事先要知道對方的 IP 地址，然後才能開始傳輸。

2. DNS 協議

由上一節可知請求時需要事先知道對方的 IP 地址，但 IP 地址是由「161.117.232.65」這樣的數字組成的，正常人根本記不住，想想看，如果我要上個百度，還要先知道它的 IP 地址，那豈不是要瘋掉，那怎麼辦，聯絡生活場景，想想看，如果我們要打某人電話，記不住他的電話號碼，是不是要先到電話本找某個人的名字，然後再打，電話本起的作用就是把姓名翻譯成電話號碼。

同樣的，正常人只會記住 baidu.com 這樣的網址，那就需要有類似電話本這樣的翻譯器把網址轉成 IP 地址，DNS（域名伺服器）就是幹這個事的

上面只是 DNS 的簡化版本，實際上 DNS 解析無法一步到位，比較複雜，要理解 DNS 的工作機制，首先我們要看懂域名的層級結構，類似 www.baidu.com 這樣的網址也叫域名，是一個有層次的結構, 最右邊的被稱為頂級域名，然後是二級域名，層級關係向左降低，最左邊的是主機名，通常用來表示主機的用途，比如 「www」 表示提供全球資訊網服務

當然這也不是絕對的，起名的關鍵只是方便我們記憶而已。

域名有層次之分，DNS 也是有層次之分，DNS 核心系統是一個三層的樹狀，分散式結構，基本對應域名結構。

1. 根域名伺服器（Root DNS Server）: 返回「com」,「cn」,「net」等頂級域名伺服器的 IP 地址，
2. 頂級域名伺服器（Top-level DNS Server）：管理各自域名下的權威域名伺服器，比如 com 頂級域名伺服器可以返回 apple.com 域名伺服器的 IP 地址；
3. 權威域名伺服器（Authoritative DNS Server）：管理自己域名下主機的 IP 地址，比如 apple.com 權威域名伺服器可以返回 www.apple.com 的 IP 地址。

根域名伺服器是關鍵，必須是眾所周知的，找到了它，下面的各級域名伺服器才能找到，否則域名解析就無從談起了。既然知道了 DNS 的層次之分，那麼不難猜出請求 www.apple.com 的 DNS 解析如下

1. 首先訪問根域名伺服器，獲取「com」頂級域名伺服器的地址
2. 請求「com」頂級域名伺服器，返回「apple.com」域名伺服器的地址
3. 然後返回「apple.com」域名伺服器，返回 www.apple.com 的地址

以上三層解析我們稱為 DNS 核心解析系統，那麼大家想想，全世界的 PC，app 等裝置多如牛毛，如果每發一次請求都要按上面的 DNS 解析來獲取 IP，那估計 DNS 解析系統就要炸了，如何緩解這種壓力呢，答案是用快取，事實上很多大公司，或網路運營商都會自建自己的 DNS 伺服器，作為使用者查詢的代理，代替使用者請求核心 DNS 系統，這樣如果查到的話可以快取查詢記錄，再次收到請求的號如果有快取結果或者快取未過期，則直接返回原來的快取結果，大家可能聽過 Google 的 8.8.8.8 DNS 解析伺服器，這種就是 Google 自建的，我們一般稱這種自建的為「非權威域名伺服器」。

除了非權威域名伺服器，還有瀏覽器快取，作業系統快取（大家熟知的 /etc/hosts 就是作業系統 DSN 快取的一種）

這樣的話如果請求 www.example.com，dns 的完整解析流程如下:

1、 瀏覽器中輸入 www.example.com 後，會先檢視 瀏覽器的 DNS 快取是否過期，未過期直接取快取的，已過期會繼續請求作業系統的快取（/etc/hosts 檔案等），還未找到，進入步驟 2

2、 請求本地地址配置的 DNS resolver（非權威域名伺服器），一般由使用者的 Internet 服務提供商 (ISP) 進行管理，例如有線 Internet 服務提供商、DSL 寬頻提供商或公司網，MAC 的同學可以開啟網路配置中的 DNS Servers 來看下預設 ISP 提供的域名伺服器（如果想用其他的非權威域名伺服器，填入即可，這樣就會覆蓋 ISP 提供的預設地址）

3、 DNS resolver 將 www.example.com 的請求轉發到 DNS 根名稱伺服器, 根伺服器返回「.com」頂級域名伺服器地址

4、 DNS resolver 再次轉發 www.example.com 的請求，這次轉發到步驟三獲取到的 .com 域的一個 TLD 名稱伺服器。.com 域的名稱伺服器使用與 example.com 域相關的四個 Amazon Route 53 名稱伺服器的名稱來響應該請求。

5、Amazon Route 53 名稱伺服器在 example.com 託管區域中查詢 www.example.com 記錄，獲得相關值，例如，Web 伺服器的 IP 地址 (192.0.2.44)，並將 IP 地址返回至 DNS 解析程式。

6、DNS resolver 最終獲得使用者需要的 IP 地址。解析程式將此值返回至 Web 瀏覽器。DNS 解析程式還會將 example.com 的 IP 地址快取 (儲存) 您指定的時長，以便它能夠在下次有人瀏覽 example.com 時更快地作出響應。

我們可以用 dig 工具來驗證一下上面的請求流程

可以看到請求流程確實與我們的流程圖一致！另外我們注意到 ip 地址返回了四個，這樣的話 client 可以隨機選擇其中一個請求，這就是我們常說的 DNS 負載均衡，可有效快取 server 壓力。

HTTP 報文格式

接下來我們再介紹下 HTTP 報文格式，通訊雙方要能正常通訊，就必須遵循協議才能理解對方的資訊，協議規定了 HTTP 請求和響應報文的格式。

請求和響應報文都由「起始行」，「頭部」，「空行」，「實體」 四個部分組成，只不過起始行稍有不同。

請求報文格式

先來看下請求報文的格式

示例如下:

請求方法比較常見的有以下幾類

1、 GET: 請求 URL 指定的資源，指定的資源經伺服器端解析後返回響應內容，GET 方法具有冪等性，即無論請求多次，都只會返回資源，而不會額外建立或改變資源， GET 請求只傳請求頭，不傳請求體。

2、 HEAD: 語義上與 GET 類似，但 HEAD 的響應只有請求頭，沒有請求體

3、 POST: 主要用來建立，修改，上傳資源，不具有冪等性，一般將要請求的資源附在請求體上傳輸

4、 PUT: 修改資源，基本上不用，因為 POST 也具有修改的語義，所以基本上線上大多用 POST 來代替。

5、 OPTIONS: 列出可對資源實行的方法，這個方法很少見，但在跨域中會用到，也比較重要，後文結合 Cookie 談到安全問題時我們會再提

協議版本指定了客戶端當前支援的 HTTP 版本，HTTP 目前通用的有 1.1, 2.0 三個版本，如果請求方指定了 1.1，應答方收到之後也會使用 HTTP 1.1 協議進行回覆。

響應報文格式

響應行的報文格式如下

示例如下

響應報文主要有如下五類狀態碼：

• 1××：提示資訊，表示目前是協議處理的中間狀態，還需要後續的操作；
• 2××：成功，報文已經收到並被正確處理；
• 3××：重定向，資源位置發生變動，需要客戶端重新發送請求；
• 4××：客戶端錯誤，請求報文有誤，伺服器無法處理；
• 5××：伺服器錯誤，伺服器在處理請求時內部發生了錯誤。

常用的狀態碼及其釋義如下（更詳細的可以參考文末參考連結）

瞭解這些狀態碼，我們定位排查問題就能成竹在胸，比如看到 5xx，就知道是 server 的邏輯有問題，看到 400 就知道是客戶端的請求引數有問題，另一端就不用傻傻去排查了。

請求和響應頭

請求和響應頭部報文的 header 格式基本都是一樣的，都是 key-value 的形式，key 和 value 都是用 「: 」分隔，此外 HTTP 頭欄位非常靈活，除了使用標準的 Host，Connection 等頭欄位外，也可以任意新增自定義頭，這就給 HTTP 協議帶來了無限的擴充套件可能！

常用頭欄位

HTTP 協議規定了非常多的頭欄位，可以實現各種各樣的功能，但基本上可以分為以下四類

1. 通用欄位：在請求頭和響應頭裡都可以出現；
2. 請求欄位：僅能出現在請求頭裡，進一步說明請求資訊或者額外的附加條件；
3. 響應欄位：僅能出現在響應頭裡，補充說明響應報文的資訊；
4. 實體欄位：它實際上屬於通用欄位，但專門描述 body 的額外資訊。

對 HTTP 報文的解析和處理其實本質上就是對頭欄位的處理，HTTP 的連線管理，快取控制，內容協商等都是通過頭欄位來處理的，理解了頭欄位，基本上也就理解了 HTTP，所以理解頭欄位非常重要。接下來我們就來看看這些頭部欄位的具體含義

1、通用欄位

2、請求首部欄位