[[383004]]

本文轉載自微信公眾號「小林coding」，作者小林coding 。轉載本文請聯系小林coding公眾號。

 問你一句：「你知道 HTTP/1.1 該如何優化嗎?」

我想你第一時間想到的是，使用 KeepAlive 將 HTTP/1.1 從短連接改成長鏈接。

這個確實是一個優化的手段，它是從底層的傳輸層這一方向入手的，通過減少 TCP 連接建立和斷開的次數，來減少了網絡傳輸的延遲，從而提高 HTTP/1.1 協議的傳輸效率。

但其實還可以從其他方向來優化 HTTP/1.1 協議，比如有如下 3 種優化思路：

• 盡量避免發送 HTTP 請求;
• 在需要發送 HTTP 請求時，考慮如何減少請求次數;
• 減少服務器的 HTTP 響應的數據大小;

下面，就針對這三種思路具體看看有哪些優化方法。

1 如何避免發送 HTTP 請求?

這個思路你看到是不是覺得很奇怪，不發送 HTTP 請求，那還客戶端還怎么和服務器交互數據?小林你這不是耍流氓嘛?

冷靜冷靜，你說的沒錯，客戶端當然要向服務器發送請求的。

但是，對于一些具有重復性的 HTTP 請求，比如每次請求得到的數據都一樣的，我們可以把這對「請求-響應」的數據都緩存在本地，那么下次就直接讀取本地的數據，不必在通過網絡獲取服務器的響應了，這樣的話 HTTP/1.1 的性能肯定肉眼可見的提升。

所以，避免發送 HTTP 請求的方法就是通過緩存技術，HTTP 設計者早在之前就考慮到了這點，因此 HTTP 協議的頭部有不少是針對緩存的字段。

那緩存是如何做到的呢?

客戶端會把第一次請求以及響應的數據保存在本地磁盤上，其中將請求的 URL 作為 key，而響應作為 value，兩者形成映射關系。

這樣當后續發起相同的請求時，就可以先在本地磁盤上通過 key 查到對應的 value，也就是響應，如果找到了，就直接從本地讀取該響應。毋庸置疑，讀取本次磁盤的速度肯定比網絡請求快得多，如下圖：

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

放心，這個問題 HTTP 設計者早已考慮到。

所以，服務器在發送 HTTP 響應時，會估算一個過期的時間，并把這個信息放到響應頭部中，這樣客戶端在查看響應頭部的信息時，一旦發現緩存的響應是過期的，則就會重新發送網絡請求。HTTP 關于緩說明會的頭部字段很多，這部分內容留在下次文章，這次暫時不具體說明。

如果客戶端從第一次請求得到的響應頭部中發現該響應過期了，客戶端重新發送請求，假設服務器上的資源并沒有變更，還是老樣子，那么你覺得還要在服務器的響應帶上這個資源嗎?

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

只需要客戶端在重新發送請求時，在請求的 Etag 頭部帶上第一次請求的響應頭部中的摘要，這個摘要是唯一標識響應的資源，當服務器收到請求后，會將本地資源的摘要與請求中的摘要做個比較。

如果不同，那么說明客戶端的緩存已經沒有價值，服務器在響應中帶上最新的資源。

如果相同，說明客戶端的緩存還是可以繼續使用的，那么服務器僅返回不含有包體的 304 Not Modified 響應，告訴客戶端仍然有效，這樣就可以減少響應資源在網絡中傳輸的延時，如下圖：

緩存真的是性能優化的一把萬能鑰匙，小到 CPU Cache、Page Cache、Redis Cache，大到 HTTP 協議的緩存。

2 如何減少 HTTP 請求次數?

減少 HTTP 請求次數自然也就提升了 HTTP 性能，可以從這 3 個方面入手：

• 減少重定向請求次數;
• 合并請求;
• 延遲發送請求;

2.1 減少重定向請求次數

我們先來看看什么是重定向請求?

服務器上的一個資源可能由于遷移、維護等原因從 url1 移至 url2 后，而客戶端不知情，它還是繼續請求 url1，這時服務器不能粗暴地返回錯誤，而是通過 302 響應碼和 Location 頭部，告訴客戶端該資源已經遷移至 url2 了，于是客戶端需要再發送 url2 請求以獲得服務器的資源。

那么，如果重定向請求越多，那么客戶端就要多次發起 HTTP 請求，每一次的 HTTP 請求都得經過網絡，這無疑會越降低網絡性能。

另外，服務端這一方往往不只有一臺服務器，比如源服務器上一級是代理服務器，然后代理服務器才與客戶端通信，這時客戶端重定向就會導致客戶端與代理服務器之間需要 2 次消息傳遞，如下圖：

如果重定向的工作交由代理服務器完成，就能減少 HTTP 請求次數了，如下圖：

而且當代理服務器知曉了重定向規則后，可以進一步減少消息傳遞次數，如下圖：

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

其中，301 和 308 響應碼是告訴客戶端可以將重定向響應緩存到本地磁盤，之后客戶端就自動用 url2 替代 url1 訪問服務器的資源。

2.2 合并請求

如果把多個訪問小文件的請求合并成一個大的請求，雖然傳輸的總資源還是一樣，但是減少請求，也就意味著減少了重復發送的 HTTP 頭部。

另外由于 HTTP/1.1 是請求響應模型，如果第一個發送的請求，未收到對應的響應，那么后續的請求就不會發送，于是為了防止單個請求的阻塞，所以一般瀏覽器會同時發起 5-6 個請求，每一個請求都是不同的 TCP 連接，那么如果合并了請求，也就會減少 TCP 連接的數量，因而省去了 TCP 握手和慢啟動過程耗費的時間。

接下來，具體看看合并請求的幾種方式。

有的網頁會含有很多小圖片、小圖標，有多少個小圖片，客戶端就要發起多少次請求。那么對于這些小圖片，我們可以考慮使用 CSS Image Sprites 技術把它們合成一個大圖片，這樣瀏覽器就可以用一次請求獲得一個大圖片，然后再根據 CSS 數據把大圖片切割成多張小圖片。

圖來源于：墨染楓林的CSDN

這種方式就是通過將多個小圖片合并成一個大圖片來減少 HTTP 請求的次數，以減少 HTTP 請求的次數，從而減少網絡的開銷。

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

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

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

這樣客戶端收到 HTML 后，就可以直接解碼出數據，然后直接顯示圖片，就不用再發起圖片相關的請求，這樣便減少了請求的次數。

圖來源于：陳健平的CSDN

可以看到，合并請求的方式就是合并資源，以一個大資源的請求替換多個小資源的請求。

但是這樣的合并請求會帶來新的問題，當大資源中的某一個小資源發生變化后，客戶端必須重新下載整個完整的大資源文件，這顯然帶來了額外的網絡消耗。

2.3 延遲發送請求

不要一口氣吃成大胖子，一般 HTML 里會含有很多 HTTP 的 URL，當前不需要的資源，我們沒必要也獲取過來，于是可以通過「按需獲取」的方式，來減少第一時間的 HTTP 請求次數。

請求網頁的時候，沒必要把全部資源都獲取到，而是只獲取當前用戶所看到的頁面資源，當用戶向下滑動頁面的時候，再向服務器獲取接下來的資源，這樣就達到了延遲發送請求的效果。

3 如何減少 HTTP 響應的數據大小?

對于 HTTP 的請求和響應，通常 HTTP 的響應的數據大小會比較大，也就是服務器返回的資源會比較大。

于是，我們可以考慮對響應的資源進行壓縮，這樣就可以減少響應的數據大小，從而提高網絡傳輸的效率。

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

• 無損壓縮;
• 有損壓縮;

3.1 無損壓縮

無損壓縮是指資源經過壓縮后，信息不被破壞，還能完全恢復到壓縮前的原樣，適合用在文本文件、程序可執行文件、程序源代碼。

首先，我們針對代碼的語法規則進行壓縮，因為通常代碼文件都有很多換行符或者空格，這些是為了幫助程序員更好的閱讀，但是機器執行時并不要這些符，把這些多余的符號給去除掉。

接下來，就是無損壓縮了，需要對原始資源建立統計模型，利用這個統計模型，將常出現的數據用較短的二進制比特序列表示，將不常出現的數據用較長的二進制比特序列表示，生成二進制比特序列一般是「霍夫曼編碼」算法。

gzip 就是比較常見的無損壓縮。客戶端支持的壓縮算法，會在 HTTP 請求中通過頭部中的 Accept-Encoding 字段告訴服務器：

Accept-Encoding: gzip, deflate, br 

服務器收到后，會從中選擇一個服務器支持的或者合適的壓縮算法，然后使用此壓縮算法對響應資源進行壓縮，最后通過響應頭部中的 content-encoding 字段告訴客戶端該資源使用的壓縮算法。

content-encoding: gzip 

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

3.2 有損壓縮

與無損壓縮相對的就是有損壓縮，經過此方法壓縮，解壓的數據會與原始數據不同但是非常接近。

有損壓縮主要將次要的數據舍棄，犧牲一些質量來減少數據量、提高壓縮比，這種方法經常用于壓縮多媒體數據，比如音頻、視頻、圖片。

可以通過 HTTP 請求頭部中的 Accept 字段里的「 q 質量因子」，告訴服務器期望的資源質量。

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

關于圖片的壓縮，目前壓縮比較高的是 Google 推出的 WebP 格式，它與常見的 Png 格式圖片的壓縮比例對比如下圖：

來源于：https://isparta.github.io/compare-webp/index.html

可以發現，相同圖片質量下，WebP 格式的圖片大小都比 Png 格式的圖片小，所以對于大量圖片的網站，可以考慮使用 WebP 格式的圖片，這將大幅度提升網絡傳輸的性能。

關于音視頻的壓縮，音視頻主要是動態的，每個幀都有時序的關系，通常時間連續的幀之間的變化是很小的。

比如，一個在看書的視頻，畫面通常只有人物的手和書桌上的書是會有變化的，而其他地方通常都是靜態的，于是只需要在一個靜態的關鍵幀，使用增量數據來表達后續的幀，這樣便減少了很多數據，提高了網絡傳輸的性能。對于視頻常見的編碼格式有 H264、H265 等，音頻常見的編碼格式有 AAC、AC3。

總結

這次主要從 3 個方面介紹了優化 HTTP/1.1 協議的思路。

第一個思路是，通過緩存技術來避免發送 HTTP 請求。客戶端收到第一個請求的響應后，可以將其緩存在本地磁盤，下次請求的時候，如果緩存沒過期，就直接讀取本地緩存的響應數據。如果緩存過期，客戶端發送請求的時候帶上響應數據的摘要，服務器比對后發現資源沒有變化，就發出不帶包體的 304 響應，告訴客戶端緩存的響應仍然有效。

第二個思路是，減少 HTTP 請求的次數，有以下的方法：

將原本由客戶端處理的重定向請求，交給代理服務器處理，這樣可以減少重定向請求的次數;

將多個小資源合并成一個大資源再傳輸，能夠減少 HTTP 請求次數以及 頭部的重復傳輸，再來減少 TCP 連接數量，進而省去 TCP 握手和慢啟動的網絡消耗;

按需訪問資源，只訪問當前用戶看得到/用得到的資源，當客戶往下滑動，再訪問接下來的資源，以此達到延遲請求，也就減少了同一時間的 HTTP 請求次數。

第三思路是，通過壓縮響應資源，降低傳輸資源的大小，從而提高傳輸效率，所以應當選擇更優秀的壓縮算法。

不管怎么優化 HTTP/1.1 協議都是有限的，不然也不會出現 HTTP/2 和 HTTP/3 協議，后續我們再來介紹 HTTP/2 和 HTTP/3 協議。