Hi，大家好，我是承香墨影！
HTTP 協議在網路知識中佔據了重要的地位，HTTP 協議最基礎的就是請求和響應的報文，而報文又是由報文頭（Header）和實體組成。大多數 Http 協議的使用方式，都是依賴設定不同的 HTTP 請求/響應 的 Header 來實現的。
本系列《實用 HTTP》就拋開常規的 Header 講解式的表述方式，從實際問題出發，來分析這些 HTTP 協議的使用方式，到底是為了解決什麼問題？同時講解它是如何設計的和它實現原理。
HTTP 協議是一種無狀態的“鬆散協議”，它不會記錄不同請求的狀態，並且因為它本身包含了兩端（客戶端和服務端），根據請求和響應來區分，它大部分的內容都只是一個建議，其實雙邊是可以不遵守此建議的。
“這裡寫了建議零售價 2 元…”
“哦，不接受建議！”
在上一篇文章中，聊到了 HTTP 的快取機制，其實快取的主要起因就是為了減少網路請求次數，來達到快速響應的目的。而除了減少網路請求之外，其實我們還可以通過對實體內容，進行編碼壓縮的方式，減少傳輸的內容大小，從而加快響應的速度。
本文就就繼續來聊聊 HTTP 的實體內容壓縮編碼機制。
二、HTTP 的內容編碼
2.1 為什麼要對內容進行編碼？
編碼的目的就是為了壓縮報文實體內容的大小，而通過壓縮伺服器響應報文傳輸的內容實體，在一定程度上就可以加快響應的速度。
畢竟傳輸一個 10kb 的內容，會比傳輸一個 100kb 的內容快很多。這就是需要使用內容編碼進行壓縮的原因。
2.2 壓縮編碼
說到壓縮編碼，就先簡單聊聊壓縮演算法，對於壓縮演算法而言，分為兩類：
- 無失真壓縮演算法
- 有失真壓縮演算法
從名稱上就可以理解，無失真壓縮意味著它是可以被還原的，通常被應用在文字，而有失真壓縮會對原始資料進行修改，以加大壓縮率的目的，對檔案進行有損失的壓縮，這是一種不可逆的操作，通常一些對質量要求不高的圖片和視訊上，雖然壓縮以後可能會導致檔案模糊，但是勉強還可以看。
而在 HTTP 協議中，通常我們只會對文字內容，進行壓縮編碼。一個主要的原因在於，壓縮本身是會消耗伺服器資源的，而檔案比多媒體檔案輕便了很多。並且多媒體檔案多數情況下，本身就已經是高度壓縮的二進位制格式，再次進行壓縮的意義也不大。
2.3 設計一個“壓縮協議”
前面提到，HTTP 協議是一種鬆散的 “協商協議”，需要客戶端和服務端雙端配合，才可以生效。而壓縮演算法有很多種，到底應該選擇哪一種，也是需要雙方協商的。
如果我們嘗試設計一下這個 HTTP 的 “壓縮協議”，主要需要關注這兩點。
1. 通知服務端，客戶端支援的壓縮演算法
一個 HTTP 事務，總是由客戶端發起請求，而服務端將響應返回。那麼客戶端就要在發起請求的時候，率先告知服務端，當前客戶端支援的壓縮演算法。
通常客戶端會支援多種壓縮演算法，為了讓服務端有選擇的空間，應該允許傳遞多個支援的壓縮演算法。既然有多選的空間，那麼就一定要有優先順序的概念。
類似於我們在市場上交易，我接受人民幣、美元、比特幣的交易，但是因為我使用人民幣更方便，所以我需要指明交易方，如果方便的話最好通過人民幣交易。
2. 服務端選擇支援的壓縮演算法壓縮內容
服務端接受到客戶端的請求後，辨識出客戶端支援的壓縮演算法，現在當前環境最優的一種壓縮演算法對響應內容體進行壓縮，然後將壓縮後的內容返回。
為了讓客戶端接收到響應後，能明確知道服務端使用的壓縮演算法，還需要在響應中明確指明，當前的響應實體的資料使用的壓縮演算法（當然也可以不壓縮）。
2.4 HTTP 的“壓縮協議”
前面我們自己設計的兩個條件，都是基於 HTTP 報文中的報文頭來實現的。接下來我們看看 HTTP 協議中，是如何設計“壓縮協議”的。
1. 請求頭中的 Accept-Encoding
客戶端為了告知服務端當前支援的壓縮編碼，可以在請求頭中，增加 Accept-Encoding 這個頭部欄位，用來指定當前客戶端支援的壓縮編碼，如果有多個可以使用逗號 , 進行分割。
為了滿足優先順序，其實是可以通過 , 分割的順序來指定的。HTTP 協議中，還可以使用 Q 值來說明編碼的優先順序，Q 值的取值範圍是 0.0 ~ 1.0。0.0 表示客戶端不想接受此編碼，而 1.0 則表示希望使用此編碼，不過通常我們不需要明確的指定它，大家瞭解一下即可。
2. 響應頭中的 content-encoding
服務端為了在響應報文裡體現當前對內容壓縮使用的編碼格式，會在響應頭中使用 Content-Encoding 標記，它是一個明確值，所以只可能有一個。
編碼的目的就是為了壓縮，所以當服務端選擇壓縮內容實體的時候，同時還會修改 Content-Length 來明確表示當前實體被編碼壓縮後的長度。
發兩張壓縮前和壓縮後的流程圖，就清晰了。
壓縮前：
壓縮後：
三、HTTP 的編碼型別
3.2 HTTP 編碼型別
HTTP 定義了一些標準的內容編碼型別，並且可以擴充套件更多的編碼型別。由網際網路號碼分配機構（IANA）對各種編碼進行標準化，它給每個內容編碼演算法分配一個唯一的代號。
Content-Encoding 就是用這些標準化的代號來說明編碼使用的演算法。
比較常用的演算法有：
- gzip：表明實體採用 GNU zip 編碼。
- compress：表明實體採用 Unix 的檔案壓縮程式。
- deflate：表明使用是用 zlib 的格式壓縮的。
- br：表明實體使用 Brotli 演算法的壓縮格式。
- identity：表明沒有對實體進行編碼，為預設值。
在這些演算法中，除了 identity 之外，都是無失真壓縮，他們都是需要可還原成原始的文字內容的。gzip 通常是效率最高的，使用最廣泛的。
但是 gzip 對媒體檔案的壓縮效果相對較差，本身 JPG/PNG 這類檔案已經是一種高度壓縮的二進位制檔案，開啟 gzip 效果甚微還會浪費大量 CPU 資源。
瀏覽器的預設實現中，這些壓縮編碼通常只會作用在文字內容上，就是 Content-Type 為 text/Xxx 的請求上，而對於一些媒體檔案，則不會使用這種方式對其進行壓縮。
3.2 GZIP
既然 gzip 是 HTTP 的內容編碼中，比較常用的一種編碼方式，這裡拋磚引玉，簡單介紹一些 gzip，其他編碼方式，有興趣的可以自行查閱相關資料。
gzip 編碼是採用的 GNU Zip 編碼，是一種無損的壓縮演算法，用於減少傳輸報文實體的大小，它是可逆的壓縮演算法，不會導致資訊損失。
gzip 的壓縮效率相對較高，並且使用也是最為廣泛的，我們在工作中如果不特殊說明，說到的 HTTP 壓縮，通常就是指的 gzip。
gzip 的原理，簡單來說，就是會去掃描整個文字的字串，找到一樣的字串，就只保留一個並分配一個標識，然後將其他相同的字串使用這個標識替換，使整個檔案變小。在還原的時候，只需要將每個標識代表的字串，替換還原，就可以還原成最初的內容實體。
這種壓縮演算法，非常適用於現在的網際網路產品，HTML、CSS、JavaScript 以及 Json 中，都包含了大量重複的字串，所以在這裡使用 gzip 是非常合適的。
gzip 具體能壓縮多少，完全取決於壓縮的實體內容，內容文字中，包含越多相同的字串，壓縮率就越高，相反則越低。在理想狀態下，gzip 的壓縮率能高達 70%。
四、內容編碼的完整過程
到此我們就算了解清楚 HTTP 對內容編碼的完整流程了。大致流程如下圖。
再總結幾個關鍵點：
1. 請求頭中，通過 Accept-Encoding 來指定客戶端支援的內容編碼格式。
2. 服務端選擇一個支援的內容編碼去壓縮原始響應內容實體。
3. 修改響應頭，增加 Content-Encoding 用於指定使用的編碼方式，並且修改 Content-Length 來表明壓縮後的內容大小。
4. 內容壓縮的演算法有很多，但是 gzip 是最常用的。
5. 內容壓縮演算法，都是基於無失真壓縮，最終都需要在客戶端將內容還原。
五、小結
一個報文通常會包含報文頭部和報文實體，而本文介紹的 HTTP 壓縮編碼，主要是針對報文實體內容中，文字內容的壓縮編碼，併為涉及到報文頭部的壓縮。主要是因為在 HTTP/1中，報文頭部始終是以 ASCII 文字傳輸，沒有經過任何壓縮，而在 HTTP/2 中才對其實現瞭解決方案，所以 HTTP 的編碼壓縮只是針對報文實體的，這句話並不全對，這個有機會以後再說。
除了內容編碼之外，HTTP 還有傳輸編碼，這個同樣也是有機會再說。
在本文中，說明了 HTTP 對報文實體內容的壓縮策略和方法，希望對你有幫助。
公眾號後臺回覆成長『成長』，將會得到我準備的學習資料，也能回覆『加群』，一起學習進步；你還能回覆『提問』，向我發起提問。
推薦閱讀：
- 小程式 UI 佈局指南（一）
- 程式設計師的密碼管理之道
- 手動重新整理 MediaStore，儲存的圖片立即出現在相簿中
- 虛擬碼、幽默和 Google 的藝術！
- 漫畫：App 防止 Fiddler 抓包小技巧！