緩存是一項(xiàng)用來提高網(wǎng)站性能不可或缺的技術(shù)，利用這項(xiàng)技術(shù)可以很好地提高 web 的性能。 緩存可以很有效地降低網(wǎng)絡(luò)的時延，同時也會減少大量請求對于服務(wù)器的壓力。

我相信你看完這篇文章后對緩存會有一個全新的認(rèn)識，如果沒有那就再看一遍。

文章目錄

1. 緩存的優(yōu)點(diǎn)
2. 地址欄網(wǎng)址緩存
3. HSTS 預(yù)加載
4. DNS 緩存
5. ARP（地址解析協(xié)議）緩存
6. TCP 發(fā)送緩沖區(qū) & 接收緩沖區(qū)
7. HTTP 請求緩存（ CDN 節(jié)點(diǎn)緩存、代理服務(wù)器緩存、瀏覽器緩存、后端動態(tài)計算結(jié)果緩存等 ）

緩存的優(yōu)點(diǎn)

緩存總結(jié)起來主要有以下幾大優(yōu)勢：

1. 減少冗余的數(shù)據(jù)傳輸，可節(jié)省流量
2. 緩解帶寬瓶頸問題，可更快加載頁面
3. 緩解瞬間擁塞，可緩解原始服務(wù)器的壓力
4. 降低距離延時，加快響應(yīng)速度

地址欄網(wǎng)址緩存

輸入 url 后遇到的第一個緩存環(huán)節(jié)就是地址欄網(wǎng)址緩存。

但我們輸入一個常用的網(wǎng)址時，經(jīng)常會有這樣的情況，我們只是輸入了幾個字母，瀏覽器就自動補(bǔ)全了該網(wǎng)址。如下圖：我只輸入 i，瀏覽器就會給出相應(yīng)的瀏覽地址：

當(dāng)我們使用這個自動補(bǔ)全的網(wǎng)址時，你會發(fā)現(xiàn)請求的相關(guān)的靜態(tài)資源也是從緩存中取得的。

你可以在 Chrome 的地址欄中輸入 Chrome://cache 查看緩存的信息

轉(zhuǎn)換非 ASCII 的 Unicode 字符

瀏覽器檢查輸入是否含有不是 a-z，A-Z，0-9， - 或者 . 的字符；如果有的話，瀏覽器會對主機(jī)名部分使用 Punycode 編碼

檢查 HSTS 預(yù)加載列表

HSTS（ HTTP Strict Transport Security ）國際互聯(lián)網(wǎng)工程組織 IETE 正在推行一種新的 Web 安全協(xié)議，作用是強(qiáng)制客戶端（如瀏覽器）使用 HTTPS 與服務(wù)器創(chuàng)建連接。

采用 HSTS 后：支持這個協(xié)議的瀏覽器，在輸入 URL 后會檢查自帶的 HSTS 預(yù)加載列表（這個列表里包含了那些請求瀏覽器只使用 HTTPS 進(jìn)行連接的域名），若網(wǎng)站在這個列表里，瀏覽器會使用 HTTPS 協(xié)議并且返回碼為 307。而不支持 HSTS 的瀏覽器訪問我們的網(wǎng)站，則不會產(chǎn)生跳轉(zhuǎn)，從而提高了兼容性。這個機(jī)制對于不支持 HTTPS 的搜索引擎來說是非常友好的！

如掘金輸入 http://www.baidu.com 會跳轉(zhuǎn)到 https://www.baidu.com:

如果你想查看 HSTS 預(yù)加載列表是否存在你想訪問的域名，你可以在輸入 chrome://net-internals/#hsts，若存在會返回信息：

DNS 緩存

當(dāng)你輸入 baidu.com 按下回車后，就開始對 baidu.com 進(jìn)行域名解析。域名解析最少涉及了三個地方的緩存：

1. 瀏覽器的 DNS 緩存
2. 操作系統(tǒng)中的 DNS 緩存
3. 索操作系統(tǒng)的 hosts 文件（可手動寫入的緩存）

域名解析的具體過程(以下是網(wǎng)上找的一張流程圖)：

1. 瀏覽器搜索自己的 DNS 緩存（瀏覽器維護(hù)一張域名與 IP 地址的對應(yīng)表）；如果沒有命中，進(jìn)入下一步；
2. 搜索操作系統(tǒng)中的 DNS 緩存；如果沒有命中，進(jìn)入下一步；
3. 搜索操作系統(tǒng)的 hosts 文件（ Windows 環(huán)境下，維護(hù)一張域名與 IP 地址的對應(yīng)表）；如果沒有命中，進(jìn)入下一步；

• 操作系統(tǒng)將域名發(fā)送至 LDNS （本地區(qū)域名服務(wù)器），LDNS 查詢自己的 DNS 緩存（一般命中率在 80% 左右），查找成功則返回結(jié)果，失敗則發(fā)起一個迭代 DNS 解析請求：
• LDNS向 Root Name Server（根域名服務(wù)器，如com、net、im 等的頂級域名服務(wù)器的地址）發(fā)起請求，此處，Root Name Server 返回 com 域的頂級域名服務(wù)器的地址；
• LDNS 向 com 域的頂級域名服務(wù)器發(fā)起請求，返回 baidu.com 域名服務(wù)器地址；
• LDNS 向 baidu.com 域名服務(wù)器發(fā)起請求，得到 baidu.com 的 IP 地址；
• LDNS 將得到的 IP 地址返回給操作系統(tǒng)，同時自己也將 IP 地址緩存起來；操作系統(tǒng)將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來。

DNS Prefetch

即 DNS 預(yù)獲取，是前端優(yōu)化的一部分。一般來說，在前端優(yōu)化中與 DNS 有關(guān)的有兩點(diǎn)：

1. 減少 DNS 的請求次數(shù)
2. 進(jìn)行 DNS 預(yù)獲取

典型的一次 DNS 解析需要耗費(fèi) 20-120 毫秒，減少DNS解析時間和次數(shù)是個很好的優(yōu)化方式。DNS Prefetching 是讓具有此屬性的域名不需要用戶點(diǎn)擊鏈接就在后臺解析，而域名解析和內(nèi)容載入是串行的網(wǎng)絡(luò)操作，所以這個方式能減少用戶的等待時間，提升用戶體驗(yàn)。

你可以通過 chrome://net-internals/#dns 查找目前系統(tǒng)中的 DNS 緩存和 Chrome 中使用的情況。

可能涉及面試題

問：瀏覽器 DNS 緩存的時間一般不會太長，一分鐘左右。為什么緩存不設(shè)置較長時間呢？

答：雖然 DNS 緩存可以提高獲取 DNS 的速度，但緩存時間過長也會影響 DNS 在 IP 變更時不能及時解析到最新的 IP。

ARP（地址解析協(xié)議）緩存

ARP 是一種用以解釋地址的協(xié)議，根據(jù)通信方的 IP 地址就可以反查出對應(yīng)方的 MAC 地址。

ARP 緩存是個用來儲存 IP 地址和 MAC 地址的緩沖區(qū)，其本質(zhì)就是一個 IP 地址與 MAC 地址的對應(yīng)表，表中每一個條目分別記錄了其他主機(jī)的 IP 地址和對應(yīng)的 MAC 地址。

當(dāng)?shù)刂方馕鰠f(xié)議被詢問一個已知 IP 地址節(jié)點(diǎn)的 MAC 地址時，先在 AR 緩存中查看，若存在，就直接返回與之對應(yīng)的MAC地址；若不存在，才發(fā)送 ARP 請求查詢。

具體的 ARP 請求查詢感興趣的同學(xué)可以自行研究。

TCP 發(fā)送緩沖區(qū) & 接收緩沖區(qū)

建立 TCP 連接這一步也涉及到緩存 —— 用來臨時存放雙方通信的數(shù)據(jù)，保證通信數(shù)據(jù)不會丟包。

每個 TCP 連接在內(nèi)核中都有一個發(fā)送緩沖區(qū)和接收緩沖區(qū)，TCP 的全雙工的工作模式以及 TCP 的流量(擁塞)控制便是依賴于這兩個獨(dú)立的 buffer 以及 buffer 的填充狀態(tài)。

發(fā)送緩沖區(qū)

發(fā)送緩沖區(qū)存放的是 send() 方法從應(yīng)用緩沖區(qū)拷貝過來的數(shù)據(jù)。

內(nèi)核基本上是按照 MSS（Maximum Segment Size，最大報文段長度） 從緩沖區(qū)中取數(shù)據(jù)發(fā)送出去，當(dāng)緩沖區(qū)中數(shù)據(jù)小于 MSS，則將剩余數(shù)據(jù)全部發(fā)送出去。TCP 的發(fā)送緩沖區(qū)必須為已發(fā)送的數(shù)據(jù)保留一個副本，直到它被對端確認(rèn)為止，才能從緩沖區(qū)中刪掉已確認(rèn)的數(shù)據(jù)。

接收緩沖區(qū)

接收緩沖區(qū)被 TCP 用來保存接收到的數(shù)據(jù)，直到應(yīng)用程序來讀取。

接收緩沖區(qū)把數(shù)據(jù)緩存入內(nèi)核，等待 recv() 方法讀取，recv() 方法所做的工作，就是把內(nèi)核緩沖區(qū)中的數(shù)據(jù)拷貝到應(yīng)用層用戶的 buffer 里面，拷貝后就刪掉已確認(rèn)的數(shù)據(jù)。

流控制(Flow Control)

TCP 流控制主要用于匹配發(fā)送端和接收端的速度，即根據(jù)接收端當(dāng)前的接收能力來調(diào)整發(fā)送端的發(fā)送速度。

由于發(fā)送速度可能大于接收速度，接收端的應(yīng)用程序未能及時從接收緩沖區(qū)讀取數(shù)據(jù)，接收緩沖區(qū)不夠大不能緩存所有接收到的報文等原因，TCP接收端的接收緩沖區(qū)很快就會被塞滿；從而導(dǎo)致不能接收后續(xù)的數(shù)據(jù)，發(fā)送端此后發(fā)送數(shù)據(jù)是無效的，因此需要流控制。

TCP 的緩存就講到這里，感興趣的可以自己翻閱資料。

HTTP 請求緩存（ CDN 節(jié)點(diǎn)緩存、代理服務(wù)器緩存、瀏覽器緩存等 ）

在建立了 TCP 連接之后，就開始 HTTP 請求了；而 HTTP 緩存是優(yōu)化性能不可忽視的一部分，這一部分我會著重講解。

再講具體過程之前，我再講一遍強(qiáng)緩存和協(xié)商緩存。

強(qiáng)緩存 ( Cache-Control 和 Expires )

強(qiáng)緩存主要是采用響應(yīng)頭中的 Cache-Control 和 Expires 兩個字段進(jìn)行控制的。

其中 Expires 是 HTTP 1.0 中定義的，它指定了一個絕對的過期時期。而 Cache-Control 是 HTTP 1.1 時出現(xiàn)的緩存控制字段。 由于 Expires 是 HTTP1.0 時代的產(chǎn)物，因此設(shè)計之初就存在著一些缺陷，如果本地時間和服務(wù)器時間相差太大，就會導(dǎo)致緩存錯亂。

這兩個字段同時使用的時候 Cache-Control 的優(yōu)先級會更高一點(diǎn)。

這兩個字段的效果是類似的，客戶端都會通過對比本地時間和服務(wù)器返回的生存時間來檢測緩存是否可用。如果緩存沒有超出它的生存時間，客戶端就會直接采用本地的緩存。如果生存日期已經(jīng)過了，這個緩存也就宣告失效。接著客戶端將再次與服務(wù)器進(jìn)行通信來驗(yàn)證這個緩存是否需要更新。

在請求頭中使用 Cache-Control 時，它可選的值有：

在響應(yīng)頭中使用 Cache-Control 時，它可選的值有：

可緩存性

1. public：響應(yīng)可以被任何對象（客戶端、代理服務(wù)器等）緩存
2. private：只能被單個用戶緩存，不能作為共享緩存
3. no-cache：使用緩存副本之前，需要將請求提交給原始服務(wù)器進(jìn)行驗(yàn)證，驗(yàn)證通過才可以使用
4. only-if-cached：客戶端只接受已緩存的響應(yīng)，并且不向原始服務(wù)器檢查是否有更新的拷貝

到期

1. max-age=<seconds>：緩存存儲的最大周期，超過這個時間緩存被認(rèn)為過期(單位秒)。與 Expires 相反，時間是相對于請求的時間
2. s-maxage=<seconds>：覆蓋 max-age 或者 Expires 頭，但是僅適用于共享緩存(比如各個代理)，并且私有緩存中它被忽略
3. max-stale[=<seconds>]：表明客戶端愿意接收一個已經(jīng)過期的資源?？蛇x的設(shè)置一個時間(單位秒)，表示響應(yīng)不能超過的過時時間
4. min-fresh=<seconds>：表示客戶端希望在指定的時間內(nèi)獲取最新的響應(yīng)

重新驗(yàn)證和重新加載

1. must-revalidate：緩存必須在使用之前驗(yàn)證舊資源的狀態(tài)，并且不可使用過期資源。
2. proxy-revalidate：與 must-revalidate 作用相同，但它僅適用于共享緩存（例如代理），并被私有緩存忽略

其他

1. no-store：徹底得禁用緩沖，本地和代理服務(wù)器都不緩沖，每次都從服務(wù)器獲取
2. no-transform：不得對資源進(jìn)行轉(zhuǎn)換或轉(zhuǎn)變。Content-Encoding, Content-Range, Content-Type 等 HTTP 頭不能由代理修改。

協(xié)商緩存 ( Last-Modified 和 Etag )

協(xié)商緩存機(jī)制下，瀏覽器需要向服務(wù)器去詢問緩存的相關(guān)信息，進(jìn)而判斷是重新發(fā)起請求還是從本地獲取緩存的資源。如果服務(wù)端提示緩存資源未改動（ Not Modified ），資源會被重定向到瀏覽器緩存，這種情況下網(wǎng)絡(luò)請求對應(yīng)的狀態(tài)碼是 304。

當(dāng)客戶端再次請求該資源的時候，會在其請求頭上附帶上 If-Modified-Since 字段（值就是第一次獲取請求資源時響應(yīng)頭中返回的 Last-Modified 值）。如果修改時間未改變則表明資源未過期，命中緩存，服務(wù)器就直接返回 304 狀態(tài)碼，客戶端直接使用本地的資源。否則，服務(wù)器重新發(fā)送響應(yīng)資源，從而保證資源的有效性。

Etag 和 If-None-Match

基于資源校驗(yàn)碼（一般為md5值）而驗(yàn)證緩存的過期機(jī)制

當(dāng)客戶端再次請求該資源的時候，會在其請求頭上附帶上 If-None-Match 字段（值就是第一次獲取請求資源時響應(yīng)頭中返回的 Etag 值），其值與服務(wù)器端資源文件的驗(yàn)證碼進(jìn)行對比，如果匹配成功直接返回 304 狀態(tài)碼，從瀏覽器本地緩存取資源文件。如果不匹配，服務(wù)器會把新的驗(yàn)證碼放在請求頭的 Etag 字段中，并且以 200 狀態(tài)碼返回資源。

需要注意的是當(dāng)響應(yīng)頭中同時存在 Etag 和 Last-Modified 的時候，會先對 Etag 進(jìn)行比對，隨后才是 Last-Modified。

Etag 的問題

相同的資源，在兩臺服務(wù)器產(chǎn)生的 Etag 是不同的，所以對于使用服務(wù)器集群來處理請求的網(wǎng)站來說，Etag 的匹配概率會大幅降低。所在在這種情況下，使用 Etag 來處理緩存，反而會有更大的開銷。

靜態(tài)資源和動態(tài)資源的請求過程解析

靜態(tài)資源

第一次請求肯定是從服務(wù)器請求過來的資源，這個沒有什么疑問，我們先看看第一次請求的響應(yīng)頭的內(nèi)容：

我們發(fā)現(xiàn)第一次的響應(yīng)頭中包含可強(qiáng)緩存的相關(guān)字段 cache-control ,同時也包含了協(xié)商緩存的相關(guān)字段 etag 和 last-modified;

當(dāng)強(qiáng)緩存和協(xié)商緩存字段同時存在時會進(jìn)行以下步驟來請求資源：

1. 強(qiáng)緩存和協(xié)商緩存同時存在，如果強(qiáng)緩存還在有效期內(nèi)則直接使用緩存；如果強(qiáng)緩存不在有效期，協(xié)商緩存生效。
2. 即：強(qiáng)緩存優(yōu)先級 > 協(xié)商緩存優(yōu)先級
3. 強(qiáng)緩存的 expires 和 cache-control 同時存在時，cache-control 會覆蓋 expires 的效果，expires 無論有沒有過期，都無效。
4. 即：cache-control 優(yōu)先級 > expires 優(yōu)先級。
5. 協(xié)商緩存的 Etag 和 Last-Modified 同時存在時， Etag 會覆蓋 Last-Modified的效果。
6. 即：ETag 優(yōu)先級 > Last-Modified 優(yōu)先級。

第二次請求該資源的時候，就直接是從緩存中讀取的：

其實(shí)我們第一次獲取的資源極有可能是從 CDN 節(jié)點(diǎn)的緩存中獲取的，也很有可能是從中間代理服務(wù)器（nginx，node 等）的緩存中讀取的；其中的好處不言而喻。

動態(tài)資源

由于動態(tài)資源的返回結(jié)果不一致，所以這個我們肯定不會在瀏覽器（中間代理服務(wù)器）緩存動態(tài)的結(jié)果。

不過這里我們可以在后端緩存一些重復(fù)率比較高的相關(guān)的計算結(jié)果。

舉個例子：這里有 60 只股票，用戶可以選擇其中幾只股票作為自己的股票投資池。用戶選擇完股票后提交，會通過相關(guān)的算法計算其預(yù)期收益效果等指標(biāo)。我們知道每次計算的時間可能會比較久，所以在這步我們可以在后端將可能的組合結(jié)果先計算好緩存起來，當(dāng)我們請求的時候就后端就可以直接返回已經(jīng)計算好的結(jié)果給前端。至于計算結(jié)果的緩存時間也就完全由服務(wù)器控制了。

小結(jié)

好了，以上就是今天介紹的全部內(nèi)容，下面在一起總結(jié)以下：

1. 緩存所具有的幾大優(yōu)點(diǎn)
2. 地址欄網(wǎng)址緩存的示例及分析
3. HSTS 預(yù)加載的表現(xiàn)形式
4. DNS 緩存的流程演示及原理分析
5. ARP（地址解析協(xié)議）緩存的講解
6. TCP 發(fā)送緩沖區(qū) & 接收緩沖區(qū)的分析講解
7. HTTP 請求緩存（ CDN 節(jié)點(diǎn)緩存、代理服務(wù)器緩存、瀏覽器緩存、后端動態(tài)計算結(jié)果緩存等 ）