詳談HTTP的緩存機制與原理

時間 2019-12-04

原文原文鏈接

概述

緩存的重要性不言而喻，經過網絡請求資源緩慢而且下降了客戶端的用戶體驗，增添了服務端的負擔。不少短時間以內不會常常發生變化的資源文件不必每次訪問都想服務端進行數據請求，而緩存策略的使用就是爲了改善客戶端的呈現時間，下降服務端的負擔。html

對於HTTP的緩存機制來講，策略體如今HTTP的頭部信息的字段上，而這些策略根據是否須要從新向服務器端發起請求能夠分爲強緩存和協商緩存兩大類。接下來用UML時序圖的形式來呈現這兩大類緩存策略的大致過程。java

Tips: Vscode 配合插件 plantUML畫（寫）UML圖很爽。相比以前用的ProcessOn拖拽的形式，你只須要熟悉plantUML的語法，在你的電腦上安裝一下java，Graphviz 的環境，不用操心樣式的展示UML真心舒服。下面的圖我就是用這個工具去畫的，很推薦。git

強緩存

強緩存緊密聯繫着一個緩存時間期限，當瀏覽器請求資源的時候會查看緩存中的資源是否存在而且肯定該緩存的資源是否過了「保質期」，若沒有超過保質期則將取得緩存中的資源進行下一步處理github

協商緩存

可見協商緩存不管如何都會和服務器交互，比較強緩存稍微要複雜一點，可是兩者是相輔相成而且能夠共同存在的，強緩存優先級較高，意味着請求一個資源時會先比較強緩存的字段，若是命中則不會再執行接下來的協商緩存的過程。express

接下來就是要介紹，兩類緩存相關HTTP header相關字段的控制實現了。瀏覽器

細節

1.強緩存

與強緩存相關的HTTP header 的字段有兩個 Expires以及Cache-Control緩存

Expires

expires 字段規定了緩存的資源的過時時間，在此時間以前，緩存中的資源都是有效的，該字段的 value 是一個格林威治時間格式（GMT)的時間,即世界標準時間，js 經過 new Date().toUTCString()可獲得，形如 Tue, 27 Feb 2018 06:37:48 GMT。他的缺點很明顯，時間期限是服務器生成，存在着客戶端和服務器的時間偏差，固定時間，HTTP 1.0時的規範。相比較接下來介紹的cache-control優先級較低。服務器

cache-control

該字段的值（默認爲private）：網絡

其中最經常使用的值max-age單位爲秒，對比expires體現着一個相對時間,即多少秒後這個強緩存機制下的緩存資源失效。app

public和private區別在因而否有中間商賺差價（是否容許CDN代理服務器緩存）

須要注意的一點是該字段值定義爲no-cache並非說，不許使用緩存，而是須要走接下來的優先級相對較低的另外一類--協商緩存。真正決定不用緩存內的資源是將該值定義爲no-store

2.協商緩存

協商緩存是經過客戶端和服務端進行HTTP通訊時，所在響應頭和請求頭中互相表達「曖昧」的，相互通氣，互送緩存標識。

Last-Modified 和 If-Modified-Since

第一次請求某一個資源時，因爲必定不會走緩存，因此服務器端會在資源的響應頭中加上一個形如Last-Modified:Mon, 26 Feb 2018 06:37:41 GMT的字段告訴客戶端瀏覽器，這個資源上次最後修改的時間；刷新頁面再次請求，這時候的協商緩存會在請求頭中加上一個形如If-Modified-Since:Mon, 26 Feb 2018 06:37:41 GMT，字面翻譯就是，是否在上個「曖昧」時間後修改了，值毫無疑問是服務端上一次響應給他的時間，讓服務器去判斷是否在此時間以後資源內容發生了變化。

整個過程也很簡單，最後的結果也很簡短。若是服務端發現改變了資源，就伴着200的 statuscode 和新鮮的資源給到客戶端，如果沒有修改，304 Not Modified讓客戶端從緩存中取。

Etag 和 If-None-Match

一樣，第一次客戶端請求一個資源文件時，服務端隨資源在響應頭部中甩來一個字段 Etag ，形如ETag:W/"1823823287"該字段的值是該資源在服務器端的惟一標識，生成的Etag值的策略有服務端決定，總之是資源的一個惟一的標識。資源發生變化則該值也發生變化。下一次客戶端請求同一個資源的時候，在請求頭將此次獲得的值放在請求頭中一個叫 If-None-Match 的字段中甩給服務端。

上述兩個方式中，Etag 和 If-None-Match的優先級要高於Last-Modified 和 If-Modified-Since，進而會衍生出一個思考，兩者相比功能相同，可是表達形式決定了 Etag 解決了 Last-Modified 存在的一些問題，好比Last-Modified 是比較時間，精確到秒，如果毫秒級的改變則無法兼顧，存在着週期性更改的資源，然而有可能資源自己的內容並無改變，那若是從新請求響應意義並非那麼的大。因此不難理解Etag具備高優先級有他的合理之處。

簡單操練一下

使用Node的Express框架可以輕鬆的觀察到這些字段帶來的影響實驗。接下來經過使用Express4.x依舊保留下來的中間件express.static搭建一個建議的靜態文件響應服務器。

其中 public 文件夾裏面放着一個主頁面和兩張不同的圖片用來改變

//app.js
const express = require('express')
const path = require('path')

const app = express()

app.use(express.static(path.join(__dirname, "public"), {
    etag: false,
    lastModified:false, 
    cacheControl: false,  
    setHeaders:function(res,path,stat) {
        res.set({
            expires: new Date(Date.now() + 60000),
        })
    }
}))

app.listen(3000, () => {
    console.log('App listening on port 3000!');
});

//index.html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Document</title>
</head>
<body>
    <h1>Hello World</h1>
    <img src="./stream.jpg">
</body>
</html>

詳細的express.static的細節請參考文檔，這裏不過多贅述。

以前咱們提到過，expires這個選項是優先級相比較其餘的控制選項，因此想要種 expires 觀察效果是記得向上述app.js同樣把其餘的都關掉，由於他們都是默認爲 true的。

而後啓動服務器，訪問3000端口，打開開發人員工具，你就會看到以下被種了expires的響應頭了。

以後，你改變圖片的名稱，調換兩張圖片的名字，你就會發如今 expires 的時間到以前圖片都不會發生變化，而且可見，他是從緩存中取得

接下來，改變app.js

app.use(express.static(path.join(__dirname, "public"), {
    etag: false,
    maxAge:30000,
    lastModified:false,   
    setHeaders:function(res,path,stat) {
        res.set({
            expires: new Date(Date.now() + 600000),
        })
    }
}))

maxAge的單位是毫秒，此時因爲優先級的關係，覆蓋掉 expires 以後在30秒以內交換圖片名稱，從新刷新瀏覽器將不會看到資源發生變化，知道maxAge的時間到。對應的響應頭以下：

繼續修改app.js:

app.use(express.static(path.join(__dirname, "public"), {
    etag: false,
    maxAge:30000,
    cacheControl: false,
    lastModified:true,   
}))

你須要刪掉對強緩存的設置，由於強緩存的設置會比協商緩存被先執行，一樣的操做你將看到接下來的響應頭和請求頭。

隨後，你將上述優先級最高的 Etag 字段改成 true,獲得的響應頭和請求頭信息以下：

此外你也會發現以下狀況：

這種現象就解釋了，協商緩存雖然老是要訪問服務器，可是當資源沒有變更的時候，服務端只會返回帶着304狀態碼的很小的一個頭部，並不會像第一次攜帶文件資源那麼大了。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。