Hi捧弃，大家好赠叼，我是承香墨影！
HTTP 協(xié)議在網(wǎng)絡知識中占據(jù)了重要的地位违霞，HTTP 協(xié)議最基礎(chǔ)的就是請求和響應的報文嘴办，而報文又是由報文頭（Header）和實體組成。大多數(shù) Http 協(xié)議的使用方式买鸽，都是依賴設(shè)置不同的 HTTP 請求/響應 的 Header 來實現(xiàn)的涧郊。
本系列《實用 HTTP》就拋開常規(guī)的 Header 講解式的表述方式，從實際問題出發(fā)眼五，來分析這些 HTTP 協(xié)議的使用方式妆艘，到底是為了解決什么問題？同時講解它是如何設(shè)計的和它實現(xiàn)原理看幼。
HTTP 協(xié)議是一種無狀態(tài)的“松散協(xié)議”批旺，它不會記錄不同請求的狀態(tài)，并且因為它本身包含了兩端（客戶端和服務端）诵姜，根據(jù)請求和響應來區(qū)分汽煮，它大部分的內(nèi)容都只是一個建議，其實雙邊是可以不遵守此建議的棚唆。
“這里寫了建議零售價 2 元…”
“哦暇赤，不接受建議！”
在上一篇文章中宵凌，聊到了 HTTP 的緩存機制鞋囊，其實緩存的主要起因就是為了減少網(wǎng)絡請求次數(shù)，來達到快速響應的目的摆寄。而除了減少網(wǎng)絡請求之外失暴，其實我們還可以通過對實體內(nèi)容，進行編碼壓縮的方式微饥，減少傳輸?shù)膬?nèi)容大小逗扒，從而加快響應的速度。
本文就就繼續(xù)來聊聊 HTTP 的實體內(nèi)容壓縮編碼機制欠橘。
二矩肩、HTTP 的內(nèi)容編碼
2.1 為什么要對內(nèi)容進行編碼？
編碼的目的就是為了壓縮報文實體內(nèi)容的大小，而通過壓縮服務器響應報文傳輸?shù)膬?nèi)容實體黍檩，在一定程度上就可以加快響應的速度叉袍。
畢竟傳輸一個 10kb 的內(nèi)容，會比傳輸一個 100kb 的內(nèi)容快很多刽酱。這就是需要使用內(nèi)容編碼進行壓縮的原因喳逛。
2.2 壓縮編碼
說到壓縮編碼，就先簡單聊聊壓縮算法棵里，對于壓縮算法而言润文，分為兩類：
- 無損壓縮算法
- 有損壓縮算法
從名稱上就可以理解，無損壓縮意味著它是可以被還原的殿怜，通常被應用在文本典蝌，而有損壓縮會對原始數(shù)據(jù)進行修改，以加大壓縮率的目的头谜，對文件進行有損失的壓縮骏掀，這是一種不可逆的操作，通常一些對質(zhì)量要求不高的圖片和視頻上柱告，雖然壓縮以后可能會導致文件模糊截驮，但是勉強還可以看。
而在 HTTP 協(xié)議中际度，通常我們只會對文本內(nèi)容侧纯，進行壓縮編碼。一個主要的原因在于甲脏，壓縮本身是會消耗服務器資源的，而文件比多媒體文件輕便了很多妹笆。并且多媒體文件多數(shù)情況下块请，本身就已經(jīng)是高度壓縮的二進制格式，再次進行壓縮的意義也不大拳缠。
2.3 設(shè)計一個“壓縮協(xié)議”
前面提到墩新，HTTP 協(xié)議是一種松散的 “協(xié)商協(xié)議”，需要客戶端和服務端雙端配合窟坐，才可以生效海渊。而壓縮算法有很多種，到底應該選擇哪一種哲鸳，也是需要雙方協(xié)商的臣疑。
如果我們嘗試設(shè)計一下這個 HTTP 的 “壓縮協(xié)議”，主要需要關(guān)注這兩點徙菠。
- 通知服務端讯沈，客戶端支持的壓縮算法
一個 HTTP 事務，總是由客戶端發(fā)起請求婿奔，而服務端將響應返回缺狠。那么客戶端就要在發(fā)起請求的時候问慎，率先告知服務端，當前客戶端支持的壓縮算法挤茄。
通橙绲穑客戶端會支持多種壓縮算法，為了讓服務端有選擇的空間穷劈，應該允許傳遞多個支持的壓縮算法笼恰。既然有多選的空間，那么就一定要有優(yōu)先級的概念囚衔。
類似于我們在市場上交易挖腰，我接受人民幣、美元练湿、比特幣的交易猴仑，但是因為我使用人民幣更方便，所以我需要指明交易方肥哎，如果方便的話最好通過人民幣交易辽俗。
- 服務端選擇支持的壓縮算法壓縮內(nèi)容
服務端接受到客戶端的請求后，辨識出客戶端支持的壓縮算法篡诽，現(xiàn)在當前環(huán)境最優(yōu)的一種壓縮算法對響應內(nèi)容體進行壓縮崖飘，然后將壓縮后的內(nèi)容返回。
為了讓客戶端接收到響應后杈女，能明確知道服務端使用的壓縮算法朱浴，還需要在響應中明確指明，當前的響應實體的數(shù)據(jù)使用的壓縮算法（當然也可以不壓縮）达椰。
2.4 HTTP 的“壓縮協(xié)議”
前面我們自己設(shè)計的兩個條件翰蠢，都是基于 HTTP 報文中的報文頭來實現(xiàn)的。接下來我們看看 HTTP 協(xié)議中啰劲，是如何設(shè)計“壓縮協(xié)議”的梁沧。
- 請求頭中的 Accept-Encoding
客戶端為了告知服務端當前支持的壓縮編碼，可以在請求頭中蝇裤，增加 Accept-Encoding 這個頭部字段廷支，用來指定當前客戶端支持的壓縮編碼，如果有多個可以使用逗號 , 進行分割栓辜。
為了滿足優(yōu)先級恋拍，其實是可以通過 , 分割的順序來指定的。HTTP 協(xié)議中啃憎，還可以使用 Q 值來說明編碼的優(yōu)先級芝囤，Q 值的取值范圍是 0.0 ~ 1.0。0.0 表示客戶端不想接受此編碼，而 1.0 則表示希望使用此編碼悯姊，不過通常我們不需要明確的指定它羡藐，大家了解一下即可。
- 響應頭中的 content-encoding
服務端為了在響應報文里體現(xiàn)當前對內(nèi)容壓縮使用的編碼格式悯许，會在響應頭中使用 Content-Encoding 標記仆嗦，它是一個明確值，所以只可能有一個先壕。
編碼的目的就是為了壓縮瘩扼，所以當服務端選擇壓縮內(nèi)容實體的時候，同時還會修改 Content-Length 來明確表示當前實體被編碼壓縮后的長度垃僚。
發(fā)兩張壓縮前和壓縮后的流程圖集绰，就清晰了。
壓縮前：
壓縮后：
三谆棺、HTTP 的編碼類型
3.2 HTTP 編碼類型
HTTP 定義了一些標準的內(nèi)容編碼類型栽燕，并且可以擴展更多的編碼類型。由互聯(lián)網(wǎng)號碼分配機構(gòu)（IANA）對各種編碼進行標準化改淑，它給每個內(nèi)容編碼算法分配一個唯一的代號碍岔。
Content-Encoding 就是用這些標準化的代號來說明編碼使用的算法。
比較常用的算法有：
- gzip：表明實體采用 GNU zip 編碼朵夏。
- compress：表明實體采用 Unix 的文件壓縮程序蔼啦。
- deflate：表明使用是用 zlib 的格式壓縮的。
- br：表明實體使用 Brotli 算法的壓縮格式仰猖。
- identity：表明沒有對實體進行編碼捏肢，為默認值。
在這些算法中饥侵，除了 identity 之外猛计，都是無損壓縮，他們都是需要可還原成原始的文本內(nèi)容的爆捞。gzip 通常是效率最高的，使用最廣泛的勾拉。
但是 gzip 對媒體文件的壓縮效果相對較差煮甥，本身 JPG/PNG 這類文件已經(jīng)是一種高度壓縮的二進制文件，開啟 gzip 效果甚微還會浪費大量 CPU 資源藕赞。
瀏覽器的默認實現(xiàn)中成肘，這些壓縮編碼通常只會作用在文本內(nèi)容上，就是 Content-Type 為 text/Xxx 的請求上斧蜕，而對于一些媒體文件双霍，則不會使用這種方式對其進行壓縮。
3.2 GZIP
既然 gzip 是 HTTP 的內(nèi)容編碼中，比較常用的一種編碼方式洒闸，這里拋磚引玉染坯，簡單介紹一些 gzip，其他編碼方式丘逸，有興趣的可以自行查閱相關(guān)資料单鹿。
gzip 編碼是采用的 GNU Zip 編碼，是一種無損的壓縮算法深纲，用于減少傳輸報文實體的大小仲锄，它是可逆的壓縮算法，不會導致信息損失湃鹊。
gzip 的壓縮效率相對較高儒喊，并且使用也是最為廣泛的，我們在工作中如果不特殊說明币呵，說到的 HTTP 壓縮怀愧，通常就是指的 gzip。
gzip 的原理富雅，簡單來說掸驱，就是會去掃描整個文本的字符串，找到一樣的字符串没佑，就只保留一個并分配一個標識毕贼，然后將其他相同的字符串使用這個標識替換，使整個文件變小蛤奢。在還原的時候鬼癣，只需要將每個標識代表的字符串，替換還原啤贩，就可以還原成最初的內(nèi)容實體待秃。
這種壓縮算法，非常適用于現(xiàn)在的互聯(lián)網(wǎng)產(chǎn)品痹屹，HTML章郁、CSS、JavaScript 以及 Json 中志衍，都包含了大量重復的字符串暖庄，所以在這里使用 gzip 是非常合適的楼肪。
gzip 具體能壓縮多少培廓，完全取決于壓縮的實體內(nèi)容肩钠，內(nèi)容文本中，包含越多相同的字符串价匠，壓縮率就越高，相反則越低惫东。在理想狀態(tài)下毙石，gzip 的壓縮率能高達 70%。
四滞时、內(nèi)容編碼的完整過程
到此我們就算了解清楚 HTTP 對內(nèi)容編碼的完整流程了滤灯。大致流程如下圖。
再總結(jié)幾個關(guān)鍵點：
請求頭中窒百，通過 Accept-Encoding 來指定客戶端支持的內(nèi)容編碼格式豫尽。
服務端選擇一個支持的內(nèi)容編碼去壓縮原始響應內(nèi)容實體。
修改響應頭美旧，增加 Content-Encoding 用于指定使用的編碼方式，并且修改 Content-Length 來表明壓縮后的內(nèi)容大小妄呕。
內(nèi)容壓縮的算法有很多嗽测，但是 gzip 是最常用的。
內(nèi)容壓縮算法优炬，都是基于無損壓縮厅贪，最終都需要在客戶端將內(nèi)容還原雅宾。
五葵硕、小結(jié)
一個報文通常會包含報文頭部和報文實體贯吓，而本文介紹的 HTTP 壓縮編碼，主要是針對報文實體內(nèi)容中介评，文本內(nèi)容的壓縮編碼爬舰，并為涉及到報文頭部的壓縮。主要是因為在 HTTP/1中坪仇，報文頭部始終是以 ASCII 文本傳輸垃你，沒有經(jīng)過任何壓縮，而在 HTTP/2 中才對其實現(xiàn)了解決方案惜颇，所以 HTTP 的編碼壓縮只是針對報文實體的凌摄，這句話并不全對，這個有機會以后再說望伦。
除了內(nèi)容編碼之外，HTTP 還有傳輸編碼腿箩，這個同樣也是有機會再說劣摇。
在本文中，說明了 HTTP 對報文實體內(nèi)容的壓縮策略和方法钧惧，希望對你有幫助勾习。
