HTTP前端優化之壓縮與緩存

1.壓縮

現代的瀏覽器以及服務器都支持壓縮技術，惟一須要協商的是採用的壓縮算法。 爲了選擇採用的壓縮算法，瀏覽器和服務器之間會使用主動協商機制

• 瀏覽器發送Accept-Encoding首部，（其中包含它所支持的壓縮算法，以及各自優先級）
• 服務器則從中選擇一種，使用該算法對響應消息主體進行壓縮，而且發送Content-Encoding首部來告知瀏覽器它使用了哪種算法

因爲該內容協商過程是基於編碼類型來選擇資源的展示形式的，在響應中，Vary（渲染引擎）首部中至少要包含Accept-Encoding;這樣，緩存服務器就能夠對資源的不一樣的展示形式進行緩存。

以下圖：

也就是：

• 客戶端（HTTP請求頭） -------> accept-encoding: gzip,deflate,br,sdch
• 服務器（HTTP響應頭） -------> content-encoding:gzip

實例

gzip(filePath, req, res, statObj) {
        let encoding = req.headers["accept-encoding"]
        if (encoding) {
            if (encoding.match(/gzip/)) {
                res.setHeader("Content-Encoding","gzip")
                return zlib.createGzip()
            } else if (encoding.match(/deflate/)) {
                res.setHeader("Content-Encoding","deflate")
                return zlib.createDeflate()
            }
            return false
        }
        return false
    }
   let flag = this.gzip(filePath, req, res, statObj)
   let type = mime.getType(filePath) || "text/plain"  
   res.setHeader("Content-Type", type + "; charset=utf8")
   if(!flag){
        fs.createReadStream(filePath).pipe(res)
    }else{
        fs.createReadStream(filePath).pipe(flag).pipe(res)
     }

複製代碼

壓縮的優缺點

• 優勢：減小HTTP響應時間，提高傳輸效率
• 壓縮過程佔用服務器額外的CPU週期，客戶端也要對壓縮文件進行解壓縮，這也須要佔用部分時間。

總結：

請求頭：

• Accept-Encoding: gzip,deflate,br,sdch；告知服務器本身支持的壓縮格式
• user-agent: 不一樣設備自動帶上這個頭，能夠判斷什麼樣的設備，重定向到相同的項目，實現不一樣設備響應不一樣項目

響應頭：

• COntent-encoding:gzip; 告知瀏覽器，服務器使用的壓縮格式
• Content-Type： 服務器給瀏覽器響應內容的類型
• Location: 重定向到某個地方

2.緩存

假設瀏覽器存在一個緩存數據庫，用於存儲緩存信息。

在客戶端第一次請求數據時，此時緩存數據庫中沒用對應的緩存數據，須要請求服務器，服務器返回後，將數據存儲至緩存數據庫中。

HTTP緩存有多種規則，根據是否須要從新向服務器發起請求進行分類 將其分爲兩大類（**強制緩存，對比緩存又叫協商緩存）

1. 已存在緩存數據，僅基於強制緩存，請求數據以下

2. 已存在緩存數據，僅基於對比緩存，請求數據以下

兩類緩存規則不一樣：

• 強制緩存若是生效，不須要再和服務器發生交互
• 對比緩存（協商緩存）不論是否生效，都須要與服務器端發生交互

**兩類緩存規則同時存在時，強制緩存優先級高於對比緩存，也就是說，當執行強制緩存的規則時，若是緩存生效，直接使用緩存，再也不執行對比緩存規則

強制緩存

在沒有緩存數據時，瀏覽器向服務器請求數據時，服務器會將數據和緩存規則一併返回，緩存規則信息包含在響應header中；

對於強制緩存來講，響應頭中會有連個字段表名失效規則（Expires/Cache-Control）

Expires

Expries的值爲服務器端返回的到期時間，即下一次請求時，請求的時間小於服務端返回到期時間，直接使用緩存數據。不過Expries是HTTP1.0的東西，如今瀏覽器默認使用的是HTTP1.1，因此它的做用基本忽略

另外一個問題，到期時間使用服務端生成的，可是客戶端時間可能跟服務端時間有偏差，這就致使了緩存命中的偏差，所以，HTTP1.1版本中，使用了Cache-Control替代

Cache-Control

Cache-Control是最重要的規則，其常見取值：

• private：客戶端能夠緩存
• public：客戶端和代理服務器均可緩存
• max-age=xxx：緩存的內容將在xxx秒後失效
• no-cache：須要使用對比緩存來驗證緩存數據
• no-store：全部內容都不會緩存，強制緩存，對比緩存都不觸發，

實例：

圖中Cache-Control僅指定了max-age，全部默認是private，緩存時間是31536000秒（365天） 也就是說，在365天內再次請求這條數據，都會直接獲取緩存數據庫中的數據，直接使用。

對比緩存（協商緩存）

瀏覽器第一次請求數據時，服務器會將緩存標識u數據一塊兒返回給客戶端，客戶端將兩者備份至緩存數據庫中， 再次請求數據時，客戶端將備份的數據標識發送給服務器，服務器根據緩存標識進行判斷，判斷成功後，返回304狀態碼，通知客戶端比較成功，可使用緩存數據

經過兩圖對比，可發現，在對比緩存生效時，狀態碼是304，而且報文大小和請求時間大大減小。 緣由是，服務器在進行標識比較後，只返回header部分，經過狀態碼通知客戶端使用緩存，再也不須要將報文主體部分返回給客戶端。

緩存標識：

Last-Modified/If-Modified-Since

Last-Modified:

服務器在響應請求時，告訴瀏覽器資源的最後修改時間。

If-Modified-Since:

再次請求服務器時，經過此字段通知服務器上次請求時，服務器返回的資源最後的修改時間。 服務器收到請求後發現頭有 If-Modified-Since 則與請求資源的最後修改時間進行對比。 若資源的最後修改時間大於 If-Modified-since ，說明資源又被改動過，則響應整片資源內容，返回狀態碼200； 若資源的最後修改時間小於或等於 If-Modified-Since ，說明資源沒有新修改過，則響應HTTP304，告訴繼續使用緩存中的數據

**Etag/If-None-Match

優先級高於 Last-Modified/If-Modified-Since

Etag:

服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（摘要）

If-None-Match：

再次請求服務器時，經過此字段通知服務器客戶端緩存數據的惟一標識， 服務器收到請求後發現請求頭中有 If-None-Match 則與被請求資源的惟一標識進行比對， 不一樣，說明資源又被改動過，則響應整片資源內容，返回狀態碼200； 相同，說明資源沒有新修改過，則響應HTTP304，告知瀏覽器使用緩存數據

總結

對於強制緩存，服務器通知瀏覽器一個緩存時間，在緩存時間內，下次請求，直接用緩存，不在時間內，執行比較緩存策略：

• Expries/Cache-Control:max-age=xxx > Etag/If-None-Match > Last-Modified/If-Modified-Since

對於比較緩存，將緩存信息中的Etage和Last-Modified經過請求發送給服務器，由服務器校驗，返回304狀態碼時，瀏覽器直接使用緩存數據。

瀏覽器第一次請求：

瀏覽器再次請求時：

實例：

cache(filePath, req, res, statObj){
        let lastModified = statObj.ctime.toGMTString()
        let ifModifiedSince = req.headers['if-modified-since']
        let Etag =             crypto.createHash("md5").update(fs.readFileSync(filePath)).digest("base64")

        res.setHeader("Last-Modified",lastModified)
        // Etag是響應頭
        res.setHeader("Etag",Etag)
        // if-none-match 當你修改服務器上的文件時，請求頭上面會自動添加這個頭
        // console.log(req.headers['if-none-match'],"match")
        // console.log(Etag)
        // if-none-match： NISthsES8P9vzWjdFT/xyg== match

        // console.log(req.headers['if-none-match'])
        // T9hRJPsOY4/I9QhWp+NFlQ==

        // 若是if-none-match存在，說明你改動服務器上的文件中的內容
        // T9hRJPsOY4/I9QhWp+NFlQ==

        // console.log("Etag--->",Etag)
        // console.log("if-none-match--->",req.headers['if-none-match'])
        let ifNoneMatch = req.headers['if-none-match']
        // // 根據內容摘要判斷是否須要緩存
        // if(ifNoneMatch){
        // // ifNoneMatch說明修改了內容
        // // return false;

        // if(ifNoneMatch !== Etag){
        // // 修改了內容，而且沒恢復，走網絡
        // return false; // 不走緩存
        // }else{
        // // 修改了內容，而且修改完後，把內容恢復，至關於沒有修改
        // return true; // 仍是從緩存中取數據
        // }
        // }else{
        // // 說明內容沒有改變 
        // return true // 
        // }
        // // 根據修改時間來判斷是否緩存
        // if(ifModifiedSince){
        // if(ifModifiedSince !== lastModified){
        // // 上一次修改的時間和最新修改的時間不同
        // return false // 不走緩存
        // }
        // }
        // 壓縮和緩存是後端程序乾的 
        if(ifModifiedSince && ifNoneMatch){
            if(ifNoneMatch !== Etag && ifModifiedSince !== lastModified){
                return false
            }
        }else{
            return false
        }

        return true

    }
 sendFile(filePath, req, res, statObj) {
        res.setHeader("Cache-Control","no-cache");

        let cache = this.cache(filePath, req, res, statObj)
        if(cache){
            res.statusCode = 304;
            return res.end()
        }

        let flag = this.gzip(filePath, req, res, statObj)
        let type = mime.getType(filePath) || "text/plain"  
        res.setHeader("Content-Type", type + "; charset=utf8")
        if(!flag){
            fs.createReadStream(filePath).pipe(res)
        }else{
            fs.createReadStream(filePath).pipe(flag).pipe(res)
        }
    }
複製代碼