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

我相信你看完這篇文章后對(duì)緩存會(huì)有一個(gè)全新的認(rèn)識(shí),，如果沒(méi)有那就再看一遍。

文章目錄

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DNS 緩存

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

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

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

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

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

DNS Prefetch

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

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

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

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

可能涉及面試題

問(wèn)：瀏覽器 DNS 緩存的時(shí)間一般不會(huì)太長(zhǎng),，一分鐘左右。為什么緩存不設(shè)置較長(zhǎng)時(shí)間呢,？

答：雖然 DNS 緩存可以提高獲取 DNS 的速度,，但緩存時(shí)間過(guò)長(zhǎng)也會(huì)影響 DNS 在 IP 變更時(shí)不能及時(shí)解析到最新的 IP。

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

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

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

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

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

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

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

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

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

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

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

接收緩沖區(qū)

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

接收緩沖區(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)前的接收能力來(lái)調(diào)整發(fā)送端的發(fā)送速度,。

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

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

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

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

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

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

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

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

這兩個(gè)字段同時(shí)使用的時(shí)候 Cache-Control 的優(yōu)先級(jí)會(huì)更高一點(diǎn),。

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

在請(qǐng)求頭中使用 Cache-Control 時(shí)，它可選的值有：

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

可緩存性

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

到期

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

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

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

其他

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

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

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

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

Etag 和 If-None-Match

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

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

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

Etag 的問(wèn)題

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

靜態(tài)資源和動(dòng)態(tài)資源的請(qǐng)求過(guò)程解析

靜態(tài)資源

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

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

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

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

第二次請(qǐng)求該資源的時(shí)候，就直接是從緩存中讀取的：

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

動(dòng)態(tài)資源

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

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

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

小結(jié)

好了,，以上就是今天介紹的全部?jī)?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 請(qǐng)求緩存（ CDN 節(jié)點(diǎn)緩存、代理服務(wù)器緩存,、瀏覽器緩存,、后端動(dòng)態(tài)計(jì)算結(jié)果緩存等 ）