HTTP協(xié)議的使用方式和設(shè)計(jì)原理講解

HTTP 協(xié)議在網(wǎng)絡(luò)知識(shí)中占據(jù)了重要的地位，HTTP 協(xié)議最基礎(chǔ)的就是請(qǐng)求和響應(yīng)的報(bào)文，而報(bào)文又是由報(bào)文頭（Header）和實(shí)體組成。大多數(shù) Http 協(xié)議的使用方式，都是依賴設(shè)置不同的 HTTP 請(qǐng)求/響應(yīng) 的 Header 來(lái)實(shí)現(xiàn)的。

本系列《實(shí)用 HTTP》就拋開常規(guī)的 Header 講解式的表述方式，從實(shí)際問(wèn)題出發(fā)，來(lái)分析這些 HTTP 協(xié)議的使用方式，到底是為了解決什么問(wèn)題？同時(shí)講解它是如何設(shè)計(jì)的和它實(shí)現(xiàn)原理。

HTTP 協(xié)議是一種無(wú)狀態(tài)的“松散協(xié)議”，它不會(huì)記錄不同請(qǐng)求的狀態(tài)，并且因?yàn)樗旧戆藘啥耍蛻舳撕头?wù)端），根據(jù)請(qǐng)求和響應(yīng)來(lái)區(qū)分，它大部分的內(nèi)容都只是一個(gè)建議，其實(shí)雙邊是可以不遵守此建議的。

“這里寫了建議零售價(jià) 2 元…”

“哦，不接受建議！”

在上一篇文章中，聊到了 HTTP 的緩存機(jī)制，其實(shí)緩存的主要起因就是為了減少網(wǎng)絡(luò)請(qǐng)求次數(shù)，來(lái)達(dá)到快速響應(yīng)的目的。而除了減少網(wǎng)絡(luò)請(qǐng)求之外，其實(shí)我們還可以通過(guò)對(duì)實(shí)體內(nèi)容，進(jìn)行編碼壓縮的方式，減少傳輸?shù)膬?nèi)容大小，從而加快響應(yīng)的速度。

本文就就繼續(xù)來(lái)聊聊 HTTP 的實(shí)體內(nèi)容壓縮編碼機(jī)制。

HTTP 的內(nèi)容編碼

2.1 為什么要對(duì)內(nèi)容進(jìn)行編碼？

編碼的目的就是為了壓縮報(bào)文實(shí)體內(nèi)容的大小，而通過(guò)壓縮服務(wù)器響應(yīng)報(bào)文傳輸?shù)膬?nèi)容實(shí)體，在一定程度上就可以加快響應(yīng)的速度。

畢竟傳輸一個(gè) 10kb 的內(nèi)容，會(huì)比傳輸一個(gè) 100kb 的內(nèi)容快很多。這就是需要使用內(nèi)容編碼進(jìn)行壓縮的原因。

2.2 壓縮編碼

說(shuō)到壓縮編碼，就先簡(jiǎn)單聊聊壓縮算法，對(duì)于壓縮算法而言，分為兩類：

無(wú)損壓縮算法

有損壓縮算法

從名稱上就可以理解，無(wú)損壓縮意味著它是可以被還原的，通常被應(yīng)用在文本，而有損壓縮會(huì)對(duì)原始數(shù)據(jù)進(jìn)行修改，以加大壓縮率的目的，對(duì)文件進(jìn)行有損失的壓縮，這是一種不可逆的操作，通常一些對(duì)質(zhì)量要求不高的圖片和視頻上，雖然壓縮以后可能會(huì)導(dǎo)致文件模糊，但是勉強(qiáng)還可以看。

而在 HTTP 協(xié)議中，通常我們只會(huì)對(duì)文本內(nèi)容，進(jìn)行壓縮編碼。一個(gè)主要的原因在于，壓縮本身是會(huì)消耗服務(wù)器資源的，而文件比多媒體文件輕便了很多。并且多媒體文件多數(shù)情況下，本身就已經(jīng)是高度壓縮的二進(jìn)制格式，再次進(jìn)行壓縮的意義也不大。

2.3 設(shè)計(jì)一個(gè)“壓縮協(xié)議”

前面提到，HTTP 協(xié)議是一種松散的 “協(xié)商協(xié)議”，需要客戶端和服務(wù)端雙端配合，才可以生效。而壓縮算法有很多種，到底應(yīng)該選擇哪一種，也是需要雙方協(xié)商的。

如果我們嘗試設(shè)計(jì)一下這個(gè) HTTP 的 “壓縮協(xié)議”，主要需要關(guān)注這兩點(diǎn)。

1. 通知服務(wù)端，客戶端支持的壓縮算法

一個(gè) HTTP 事務(wù)，總是由客戶端發(fā)起請(qǐng)求，而服務(wù)端將響應(yīng)返回。那么客戶端就要在發(fā)起請(qǐng)求的時(shí)候，率先告知服務(wù)端，當(dāng)前客戶端支持的壓縮算法。

通?？蛻舳藭?huì)支持多種壓縮算法，為了讓服務(wù)端有選擇的空間，應(yīng)該允許傳遞多個(gè)支持的壓縮算法。既然有多選的空間，那么就一定要有優(yōu)先級(jí)的概念。

類似于我們?cè)谑袌?chǎng)上交易，我接受人民幣、美元、比特幣的交易，但是因?yàn)槲沂褂萌嗣駧鸥奖悖晕倚枰该鹘灰追?，如果方便的話最好通過(guò)人民幣交易。

2. 服務(wù)端選擇支持的壓縮算法壓縮內(nèi)容

服務(wù)端接受到客戶端的請(qǐng)求后，辨識(shí)出客戶端支持的壓縮算法，現(xiàn)在當(dāng)前環(huán)境最優(yōu)的一種壓縮算法對(duì)響應(yīng)內(nèi)容體進(jìn)行壓縮，然后將壓縮后的內(nèi)容返回。

為了讓客戶端接收到響應(yīng)后，能明確知道服務(wù)端使用的壓縮算法，還需要在響應(yīng)中明確指明，當(dāng)前的響應(yīng)實(shí)體的數(shù)據(jù)使用的壓縮算法（當(dāng)然也可以不壓縮）。

2.4 HTTP 的“壓縮協(xié)議”

前面我們自己設(shè)計(jì)的兩個(gè)條件，都是基于 HTTP 報(bào)文中的報(bào)文頭來(lái)實(shí)現(xiàn)的。接下來(lái)我們看看 HTTP 協(xié)議中，是如何設(shè)計(jì)“壓縮協(xié)議”的。

1. 請(qǐng)求頭中的 Accept-Encoding

客戶端為了告知服務(wù)端當(dāng)前支持的壓縮編碼，可以在請(qǐng)求頭中，增加 Accept-Encoding 這個(gè)頭部字段，用來(lái)指定當(dāng)前客戶端支持的壓縮編碼，如果有多個(gè)可以使用逗號(hào) ， 進(jìn)行分割。

為了滿足優(yōu)先級(jí)，其實(shí)是可以通過(guò) ， 分割的順序來(lái)指定的。HTTP 協(xié)議中，還可以使用 Q 值來(lái)說(shuō)明編碼的優(yōu)先級(jí)，Q 值的取值范圍是 0.0 ~ 1.0。0.0 表示客戶端不想接受此編碼，而 1.0 則表示希望使用此編碼，不過(guò)通常我們不需要明確的指定它，大家了解一下即可。

2. 響應(yīng)頭中的 content-encoding

服務(wù)端為了在響應(yīng)報(bào)文里體現(xiàn)當(dāng)前對(duì)內(nèi)容壓縮使用的編碼格式，會(huì)在響應(yīng)頭中使用 Content-Encoding 標(biāo)記，它是一個(gè)明確值，所以只可能有一個(gè)。

編碼的目的就是為了壓縮，所以當(dāng)服務(wù)端選擇壓縮內(nèi)容實(shí)體的時(shí)候，同時(shí)還會(huì)修改 Content-Length 來(lái)明確表示當(dāng)前實(shí)體被編碼壓縮后的長(zhǎng)度。

發(fā)兩張壓縮前和壓縮后的流程圖，就清晰了。

壓縮前：

壓縮后：

HTTP 的編碼類型

3.2 HTTP 編碼類型

HTTP 定義了一些標(biāo)準(zhǔn)的內(nèi)容編碼類型，并且可以擴(kuò)展更多的編碼類型。由互聯(lián)網(wǎng)號(hào)碼分配機(jī)構(gòu)（IANA）對(duì)各種編碼進(jìn)行標(biāo)準(zhǔn)化，它給每個(gè)內(nèi)容編碼算法分配一個(gè)唯一的代號(hào)。

Content-Encoding 就是用這些標(biāo)準(zhǔn)化的代號(hào)來(lái)說(shuō)明編碼使用的算法。

比較常用的算法有：

gzip：表明實(shí)體采用 GNU zip 編碼。

compress：表明實(shí)體采用 Unix 的文件壓縮程序。

deflate：表明使用是用 zlib 的格式壓縮的。

br：表明實(shí)體使用 Brotli 算法的壓縮格式。

idenTIty：表明沒(méi)有對(duì)實(shí)體進(jìn)行編碼，為默認(rèn)值。

在這些算法中，除了 idenTIty 之外，都是無(wú)損壓縮，他們都是需要可還原成原始的文本內(nèi)容的。gzip 通常是效率最高的，使用最廣泛的。

但是 gzip 對(duì)媒體文件的壓縮效果相對(duì)較差，本身 JPG/PNG 這類文件已經(jīng)是一種高度壓縮的二進(jìn)制文件，開啟 gzip 效果甚微還會(huì)浪費(fèi)大量 CPU 資源。

瀏覽器的默認(rèn)實(shí)現(xiàn)中，這些壓縮編碼通常只會(huì)作用在文本內(nèi)容上，就是 Content-Type 為 text/Xxx 的請(qǐng)求上，而對(duì)于一些媒體文件，則不會(huì)使用這種方式對(duì)其進(jìn)行壓縮。

3.2 GZIP

既然 gzip 是 HTTP 的內(nèi)容編碼中，比較常用的一種編碼方式，這里拋磚引玉，簡(jiǎn)單介紹一些 gzip，其他編碼方式，有興趣的可以自行查閱相關(guān)資料。

gzip 編碼是采用的 GNU Zip 編碼，是一種無(wú)損的壓縮算法，用于減少傳輸報(bào)文實(shí)體的大小，它是可逆的壓縮算法，不會(huì)導(dǎo)致信息損失。

gzip 的壓縮效率相對(duì)較高，并且使用也是最為廣泛的，我們?cè)诠ぷ髦腥绻惶厥庹f(shuō)明，說(shuō)到的 HTTP 壓縮，通常就是指的 gzip。

gzip 的原理，簡(jiǎn)單來(lái)說(shuō)，就是會(huì)去掃描整個(gè)文本的字符串，找到一樣的字符串，就只保留一個(gè)并分配一個(gè)標(biāo)識(shí)，然后將其他相同的字符串使用這個(gè)標(biāo)識(shí)替換，使整個(gè)文件變小。在還原的時(shí)候，只需要將每個(gè)標(biāo)識(shí)代表的字符串，替換還原，就可以還原成最初的內(nèi)容實(shí)體。

這種壓縮算法，非常適用于現(xiàn)在的互聯(lián)網(wǎng)產(chǎn)品，HTML、CSS、JavaScript 以及 Json 中，都包含了大量重復(fù)的字符串，所以在這里使用 gzip 是非常合適的。

gzip 具體能壓縮多少，完全取決于壓縮的實(shí)體內(nèi)容，內(nèi)容文本中，包含越多相同的字符串，壓縮率就越高，相反則越低。在理想狀態(tài)下，gzip 的壓縮率能高達(dá) 70%。

四、內(nèi)容編碼的完整過(guò)程

到此我們就算了解清楚 HTTP 對(duì)內(nèi)容編碼的完整流程了。大致流程如下圖。

再總結(jié)幾個(gè)關(guān)鍵點(diǎn)：

1. 請(qǐng)求頭中，通過(guò) Accept-Encoding 來(lái)指定客戶端支持的內(nèi)容編碼格式。

2. 服務(wù)端選擇一個(gè)支持的內(nèi)容編碼去壓縮原始響應(yīng)內(nèi)容實(shí)體。

3. 修改響應(yīng)頭，增加 Content-Encoding 用于指定使用的編碼方式，并且修改 Content-Length 來(lái)表明壓縮后的內(nèi)容大小。

4. 內(nèi)容壓縮的算法有很多，但是 gzip 是最常用的。

5. 內(nèi)容壓縮算法，都是基于無(wú)損壓縮，最終都需要在客戶端將內(nèi)容還原。

小結(jié)

一個(gè)報(bào)文通常會(huì)包含報(bào)文頭部和報(bào)文實(shí)體，而本文介紹的 HTTP 壓縮編碼，主要是針對(duì)報(bào)文實(shí)體內(nèi)容中，文本內(nèi)容的壓縮編碼，并為涉及到報(bào)文頭部的壓縮。主要是因?yàn)樵?HTTP/1中，報(bào)文頭部始終是以 ASCII 文本傳輸，沒(méi)有經(jīng)過(guò)任何壓縮，而在 HTTP/2 中才對(duì)其實(shí)現(xiàn)了解決方案，所以 HTTP 的編碼壓縮只是針對(duì)報(bào)文實(shí)體的，這句話并不全對(duì)，這個(gè)有機(jī)會(huì)以后再說(shuō)。

除了內(nèi)容編碼之外，HTTP 還有傳輸編碼，這個(gè)同樣也是有機(jī)會(huì)再說(shuō)。