[[383004]]

本文轉(zhuǎn)載自微信公眾號(hào)「小林coding」，作者小林coding 。轉(zhuǎn)載本文請(qǐng)聯(lián)系小林coding公眾號(hào)。

 問(wèn)你一句：「你知道 HTTP/1.1 該如何優(yōu)化嗎?」

我想你第一時(shí)間想到的是，使用 KeepAlive 將 HTTP/1.1 從短連接改成長(zhǎng)鏈接。

這個(gè)確實(shí)是一個(gè)優(yōu)化的手段，它是從底層的傳輸層這一方向入手的，通過(guò)減少 TCP 連接建立和斷開(kāi)的次數(shù)，來(lái)減少了網(wǎng)絡(luò)傳輸?shù)难舆t，從而提高 HTTP/1.1 協(xié)議的傳輸效率。

但其實(shí)還可以從其他方向來(lái)優(yōu)化 HTTP/1.1 協(xié)議，比如有如下 3 種優(yōu)化思路：

• 盡量避免發(fā)送 HTTP 請(qǐng)求;
• 在需要發(fā)送 HTTP 請(qǐng)求時(shí)，考慮如何減少請(qǐng)求次數(shù);
• 減少服務(wù)器的 HTTP 響應(yīng)的數(shù)據(jù)大小;

下面，就針對(duì)這三種思路具體看看有哪些優(yōu)化方法。

1 如何避免發(fā)送 HTTP 請(qǐng)求?

這個(gè)思路你看到是不是覺(jué)得很奇怪，不發(fā)送 HTTP 請(qǐng)求，那還客戶端還怎么和服務(wù)器交互數(shù)據(jù)?小林你這不是耍流氓嘛?

冷靜冷靜，你說(shuō)的沒(méi)錯(cuò)，客戶端當(dāng)然要向服務(wù)器發(fā)送請(qǐng)求的。

但是，對(duì)于一些具有重復(fù)性的 HTTP 請(qǐng)求，比如每次請(qǐng)求得到的數(shù)據(jù)都一樣的，我們可以把這對(duì)「請(qǐng)求-響應(yīng)」的數(shù)據(jù)都緩存在本地，那么下次就直接讀取本地的數(shù)據(jù)，不必在通過(guò)網(wǎng)絡(luò)獲取服務(wù)器的響應(yīng)了，這樣的話 HTTP/1.1 的性能肯定肉眼可見(jiàn)的提升。

所以，避免發(fā)送 HTTP 請(qǐng)求的方法就是通過(guò)緩存技術(shù)，HTTP 設(shè)計(jì)者早在之前就考慮到了這點(diǎn)，因此 HTTP 協(xié)議的頭部有不少是針對(duì)緩存的字段。

那緩存是如何做到的呢?

客戶端會(huì)把第一次請(qǐng)求以及響應(yīng)的數(shù)據(jù)保存在本地磁盤(pán)上，其中將請(qǐng)求的 URL 作為 key，而響應(yīng)作為 value，兩者形成映射關(guān)系。

這樣當(dāng)后續(xù)發(fā)起相同的請(qǐng)求時(shí)，就可以先在本地磁盤(pán)上通過(guò) key 查到對(duì)應(yīng)的 value，也就是響應(yīng)，如果找到了，就直接從本地讀取該響應(yīng)。毋庸置疑，讀取本次磁盤(pán)的速度肯定比網(wǎng)絡(luò)請(qǐng)求快得多，如下圖：

聰明的你可能想到了，萬(wàn)一緩存的響應(yīng)不是最新的，而客戶端并不知情，那么該怎么辦呢?

放心，這個(gè)問(wèn)題 HTTP 設(shè)計(jì)者早已考慮到。

所以，服務(wù)器在發(fā)送 HTTP 響應(yīng)時(shí)，會(huì)估算一個(gè)過(guò)期的時(shí)間，并把這個(gè)信息放到響應(yīng)頭部中，這樣客戶端在查看響應(yīng)頭部的信息時(shí)，一旦發(fā)現(xiàn)緩存的響應(yīng)是過(guò)期的，則就會(huì)重新發(fā)送網(wǎng)絡(luò)請(qǐng)求。HTTP 關(guān)于緩說(shuō)明會(huì)的頭部字段很多，這部分內(nèi)容留在下次文章，這次暫時(shí)不具體說(shuō)明。

如果客戶端從第一次請(qǐng)求得到的響應(yīng)頭部中發(fā)現(xiàn)該響應(yīng)過(guò)期了，客戶端重新發(fā)送請(qǐng)求，假設(shè)服務(wù)器上的資源并沒(méi)有變更，還是老樣子，那么你覺(jué)得還要在服務(wù)器的響應(yīng)帶上這個(gè)資源嗎?

很顯然不帶的話，可以提高 HTTP 協(xié)議的性能，那具體如何做到呢?

只需要客戶端在重新發(fā)送請(qǐng)求時(shí)，在請(qǐng)求的 Etag 頭部帶上第一次請(qǐng)求的響應(yīng)頭部中的摘要，這個(gè)摘要是唯一標(biāo)識(shí)響應(yīng)的資源，當(dāng)服務(wù)器收到請(qǐng)求后，會(huì)將本地資源的摘要與請(qǐng)求中的摘要做個(gè)比較。

如果不同，那么說(shuō)明客戶端的緩存已經(jīng)沒(méi)有價(jià)值，服務(wù)器在響應(yīng)中帶上最新的資源。

如果相同，說(shuō)明客戶端的緩存還是可以繼續(xù)使用的，那么服務(wù)器僅返回不含有包體的 304 Not Modified 響應(yīng)，告訴客戶端仍然有效，這樣就可以減少響應(yīng)資源在網(wǎng)絡(luò)中傳輸?shù)难訒r(shí)，如下圖：

緩存真的是性能優(yōu)化的一把萬(wàn)能鑰匙，小到 CPU Cache、Page Cache、Redis Cache，大到 HTTP 協(xié)議的緩存。

2 如何減少 HTTP 請(qǐng)求次數(shù)?

減少 HTTP 請(qǐng)求次數(shù)自然也就提升了 HTTP 性能，可以從這 3 個(gè)方面入手：

• 減少重定向請(qǐng)求次數(shù);
• 合并請(qǐng)求;
• 延遲發(fā)送請(qǐng)求;

2.1 減少重定向請(qǐng)求次數(shù)

我們先來(lái)看看什么是重定向請(qǐng)求?

服務(wù)器上的一個(gè)資源可能由于遷移、維護(hù)等原因從 url1 移至 url2 后，而客戶端不知情，它還是繼續(xù)請(qǐng)求 url1，這時(shí)服務(wù)器不能粗暴地返回錯(cuò)誤，而是通過(guò) 302 響應(yīng)碼和 Location 頭部，告訴客戶端該資源已經(jīng)遷移至 url2 了，于是客戶端需要再發(fā)送 url2 請(qǐng)求以獲得服務(wù)器的資源。

那么，如果重定向請(qǐng)求越多，那么客戶端就要多次發(fā)起 HTTP 請(qǐng)求，每一次的 HTTP 請(qǐng)求都得經(jīng)過(guò)網(wǎng)絡(luò)，這無(wú)疑會(huì)越降低網(wǎng)絡(luò)性能。

另外，服務(wù)端這一方往往不只有一臺(tái)服務(wù)器，比如源服務(wù)器上一級(jí)是代理服務(wù)器，然后代理服務(wù)器才與客戶端通信，這時(shí)客戶端重定向就會(huì)導(dǎo)致客戶端與代理服務(wù)器之間需要 2 次消息傳遞，如下圖：

如果重定向的工作交由代理服務(wù)器完成，就能減少 HTTP 請(qǐng)求次數(shù)了，如下圖：

而且當(dāng)代理服務(wù)器知曉了重定向規(guī)則后，可以進(jìn)一步減少消息傳遞次數(shù)，如下圖：

除了 302 重定向響應(yīng)碼，還有其他一些重定向的響應(yīng)碼，你可以從下圖看到：

其中，301 和 308 響應(yīng)碼是告訴客戶端可以將重定向響應(yīng)緩存到本地磁盤(pán)，之后客戶端就自動(dòng)用 url2 替代 url1 訪問(wèn)服務(wù)器的資源。

2.2 合并請(qǐng)求

如果把多個(gè)訪問(wèn)小文件的請(qǐng)求合并成一個(gè)大的請(qǐng)求，雖然傳輸?shù)目傎Y源還是一樣，但是減少請(qǐng)求，也就意味著減少了重復(fù)發(fā)送的 HTTP 頭部。

另外由于 HTTP/1.1 是請(qǐng)求響應(yīng)模型，如果第一個(gè)發(fā)送的請(qǐng)求，未收到對(duì)應(yīng)的響應(yīng)，那么后續(xù)的請(qǐng)求就不會(huì)發(fā)送，于是為了防止單個(gè)請(qǐng)求的阻塞，所以一般瀏覽器會(huì)同時(shí)發(fā)起 5-6 個(gè)請(qǐng)求，每一個(gè)請(qǐng)求都是不同的 TCP 連接，那么如果合并了請(qǐng)求，也就會(huì)減少 TCP 連接的數(shù)量，因而省去了 TCP 握手和慢啟動(dòng)過(guò)程耗費(fèi)的時(shí)間。

接下來(lái)，具體看看合并請(qǐng)求的幾種方式。

有的網(wǎng)頁(yè)會(huì)含有很多小圖片、小圖標(biāo)，有多少個(gè)小圖片，客戶端就要發(fā)起多少次請(qǐng)求。那么對(duì)于這些小圖片，我們可以考慮使用 CSS Image Sprites 技術(shù)把它們合成一個(gè)大圖片，這樣瀏覽器就可以用一次請(qǐng)求獲得一個(gè)大圖片，然后再根據(jù) CSS 數(shù)據(jù)把大圖片切割成多張小圖片。

圖來(lái)源于：墨染楓林的CSDN

這種方式就是通過(guò)將多個(gè)小圖片合并成一個(gè)大圖片來(lái)減少 HTTP 請(qǐng)求的次數(shù)，以減少 HTTP 請(qǐng)求的次數(shù)，從而減少網(wǎng)絡(luò)的開(kāi)銷(xiāo)。

除了將小圖片合并成大圖片的方式，還有服務(wù)端使用 webpack 等打包工具將 js、css 等資源合并打包成大文件，也是能達(dá)到類似的效果。

另外，還可以將圖片的二進(jìn)制數(shù)據(jù)用 base64 編碼后，以 URL 的形式潛入到 HTML 文件，跟隨 HTML 文件一并發(fā)送.

<image src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAPoAAAFKCAIAAAC7M9WrAAAACXBIWXMAA ... /> 

這樣客戶端收到 HTML 后，就可以直接解碼出數(shù)據(jù)，然后直接顯示圖片，就不用再發(fā)起圖片相關(guān)的請(qǐng)求，這樣便減少了請(qǐng)求的次數(shù)。

圖來(lái)源于：陳健平的CSDN

可以看到，合并請(qǐng)求的方式就是合并資源，以一個(gè)大資源的請(qǐng)求替換多個(gè)小資源的請(qǐng)求。

但是這樣的合并請(qǐng)求會(huì)帶來(lái)新的問(wèn)題，當(dāng)大資源中的某一個(gè)小資源發(fā)生變化后，客戶端必須重新下載整個(gè)完整的大資源文件，這顯然帶來(lái)了額外的網(wǎng)絡(luò)消耗。

2.3 延遲發(fā)送請(qǐng)求

不要一口氣吃成大胖子，一般 HTML 里會(huì)含有很多 HTTP 的 URL，當(dāng)前不需要的資源，我們沒(méi)必要也獲取過(guò)來(lái)，于是可以通過(guò)「按需獲取」的方式，來(lái)減少第一時(shí)間的 HTTP 請(qǐng)求次數(shù)。

請(qǐng)求網(wǎng)頁(yè)的時(shí)候，沒(méi)必要把全部資源都獲取到，而是只獲取當(dāng)前用戶所看到的頁(yè)面資源，當(dāng)用戶向下滑動(dòng)頁(yè)面的時(shí)候，再向服務(wù)器獲取接下來(lái)的資源，這樣就達(dá)到了延遲發(fā)送請(qǐng)求的效果。

3 如何減少 HTTP 響應(yīng)的數(shù)據(jù)大小?

對(duì)于 HTTP 的請(qǐng)求和響應(yīng)，通常 HTTP 的響應(yīng)的數(shù)據(jù)大小會(huì)比較大，也就是服務(wù)器返回的資源會(huì)比較大。

于是，我們可以考慮對(duì)響應(yīng)的資源進(jìn)行壓縮，這樣就可以減少響應(yīng)的數(shù)據(jù)大小，從而提高網(wǎng)絡(luò)傳輸?shù)男省?/p>

壓縮的方式一般分為 2 種，分別是：

• 無(wú)損壓縮;
• 有損壓縮;

3.1 無(wú)損壓縮

無(wú)損壓縮是指資源經(jīng)過(guò)壓縮后，信息不被破壞，還能完全恢復(fù)到壓縮前的原樣，適合用在文本文件、程序可執(zhí)行文件、程序源代碼。

首先，我們針對(duì)代碼的語(yǔ)法規(guī)則進(jìn)行壓縮，因?yàn)橥ǔ４a文件都有很多換行符或者空格，這些是為了幫助程序員更好的閱讀，但是機(jī)器執(zhí)行時(shí)并不要這些符，把這些多余的符號(hào)給去除掉。

接下來(lái)，就是無(wú)損壓縮了，需要對(duì)原始資源建立統(tǒng)計(jì)模型，利用這個(gè)統(tǒng)計(jì)模型，將常出現(xiàn)的數(shù)據(jù)用較短的二進(jìn)制比特序列表示，將不常出現(xiàn)的數(shù)據(jù)用較長(zhǎng)的二進(jìn)制比特序列表示，生成二進(jìn)制比特序列一般是「霍夫曼編碼」算法。

gzip 就是比較常見(jiàn)的無(wú)損壓縮?？蛻舳酥С值膲嚎s算法，會(huì)在 HTTP 請(qǐng)求中通過(guò)頭部中的 Accept-Encoding 字段告訴服務(wù)器：

Accept-Encoding: gzip, deflate, br 

服務(wù)器收到后，會(huì)從中選擇一個(gè)服務(wù)器支持的或者合適的壓縮算法，然后使用此壓縮算法對(duì)響應(yīng)資源進(jìn)行壓縮，最后通過(guò)響應(yīng)頭部中的 content-encoding 字段告訴客戶端該資源使用的壓縮算法。

content-encoding: gzip 

gzip 的壓縮效率相比 Google 推出的 Brotli 算法還是差點(diǎn)意思，也就是上文中的 br，所以如果可以，服務(wù)器應(yīng)該選擇壓縮效率更高的 br 壓縮算法。

3.2 有損壓縮

與無(wú)損壓縮相對(duì)的就是有損壓縮，經(jīng)過(guò)此方法壓縮，解壓的數(shù)據(jù)會(huì)與原始數(shù)據(jù)不同但是非常接近。

有損壓縮主要將次要的數(shù)據(jù)舍棄，犧牲一些質(zhì)量來(lái)減少數(shù)據(jù)量、提高壓縮比，這種方法經(jīng)常用于壓縮多媒體數(shù)據(jù)，比如音頻、視頻、圖片。

可以通過(guò) HTTP 請(qǐng)求頭部中的 Accept 字段里的「 q 質(zhì)量因子」，告訴服務(wù)器期望的資源質(zhì)量。

Accept: audio/*; q=0.2, audio/basic 

關(guān)于圖片的壓縮，目前壓縮比較高的是 Google 推出的 WebP 格式，它與常見(jiàn)的 Png 格式圖片的壓縮比例對(duì)比如下圖：

來(lái)源于：https://isparta.github.io/compare-webp/index.html

可以發(fā)現(xiàn)，相同圖片質(zhì)量下，WebP 格式的圖片大小都比 Png 格式的圖片小，所以對(duì)于大量圖片的網(wǎng)站，可以考慮使用 WebP 格式的圖片，這將大幅度提升網(wǎng)絡(luò)傳輸?shù)男阅堋?/p>

關(guān)于音視頻的壓縮，音視頻主要是動(dòng)態(tài)的，每個(gè)幀都有時(shí)序的關(guān)系，通常時(shí)間連續(xù)的幀之間的變化是很小的。

比如，一個(gè)在看書(shū)的視頻，畫(huà)面通常只有人物的手和書(shū)桌上的書(shū)是會(huì)有變化的，而其他地方通常都是靜態(tài)的，于是只需要在一個(gè)靜態(tài)的關(guān)鍵幀，使用增量數(shù)據(jù)來(lái)表達(dá)后續(xù)的幀，這樣便減少了很多數(shù)據(jù)，提高了網(wǎng)絡(luò)傳輸?shù)男阅堋?duì)于視頻常見(jiàn)的編碼格式有 H264、H265 等，音頻常見(jiàn)的編碼格式有 AAC、AC3。

總結(jié)

這次主要從 3 個(gè)方面介紹了優(yōu)化 HTTP/1.1 協(xié)議的思路。

第一個(gè)思路是，通過(guò)緩存技術(shù)來(lái)避免發(fā)送 HTTP 請(qǐng)求?？蛻舳耸盏降谝粋€(gè)請(qǐng)求的響應(yīng)后，可以將其緩存在本地磁盤(pán)，下次請(qǐng)求的時(shí)候，如果緩存沒(méi)過(guò)期，就直接讀取本地緩存的響應(yīng)數(shù)據(jù)。如果緩存過(guò)期，客戶端發(fā)送請(qǐng)求的時(shí)候帶上響應(yīng)數(shù)據(jù)的摘要，服務(wù)器比對(duì)后發(fā)現(xiàn)資源沒(méi)有變化，就發(fā)出不帶包體的 304 響應(yīng)，告訴客戶端緩存的響應(yīng)仍然有效。

第二個(gè)思路是，減少 HTTP 請(qǐng)求的次數(shù)，有以下的方法：

將原本由客戶端處理的重定向請(qǐng)求，交給代理服務(wù)器處理，這樣可以減少重定向請(qǐng)求的次數(shù);

將多個(gè)小資源合并成一個(gè)大資源再傳輸，能夠減少 HTTP 請(qǐng)求次數(shù)以及 頭部的重復(fù)傳輸，再來(lái)減少 TCP 連接數(shù)量，進(jìn)而省去 TCP 握手和慢啟動(dòng)的網(wǎng)絡(luò)消耗;

按需訪問(wèn)資源，只訪問(wèn)當(dāng)前用戶看得到/用得到的資源，當(dāng)客戶往下滑動(dòng)，再訪問(wèn)接下來(lái)的資源，以此達(dá)到延遲請(qǐng)求，也就減少了同一時(shí)間的 HTTP 請(qǐng)求次數(shù)。

第三思路是，通過(guò)壓縮響應(yīng)資源，降低傳輸資源的大小，從而提高傳輸效率，所以應(yīng)當(dāng)選擇更優(yōu)秀的壓縮算法。

不管怎么優(yōu)化 HTTP/1.1 協(xié)議都是有限的，不然也不會(huì)出現(xiàn) HTTP/2 和 HTTP/3 協(xié)議，后續(xù)我們?cè)賮?lái)介紹 HTTP/2 和 HTTP/3 協(xié)議。