從輸入 URL 到展現(xiàn)涉及哪些緩存環(huán)節(jié)(非常詳細)

前言

緩存是一項用來提高網(wǎng)站性能不可或缺的技術(shù)，利用這項技術(shù)可以很好地提高 web 的性能。緩存可以很有效地降低網(wǎng)絡(luò)的時延，同時也會減少大量請求對于服務(wù)器的壓力。大家在繼續(xù)看下去之前可以先思考一下 “從輸入 URL 到頁面加載完成的過程中都發(fā)生了什么事情”。你現(xiàn)在所看到的其實就是這個熱點問題的一個變種問題。

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

入題

在這篇文章，我會詳盡的描述從輸入 URL 到展現(xiàn)涉及到的緩存環(huán)節(jié)，不過由于本人知識有限，很可能有某些隱藏的緩存機制在下遺漏了，還請大佬不吝賜教。

在講“從輸入 URL 到展現(xiàn)涉及到的緩存環(huán)節(jié)”之前，我們先了解下緩存的優(yōu)點：

緩存的幾個優(yōu)點

1. 減少冗余的數(shù)據(jù)傳輸，可節(jié)省流量

2. 緩解帶寬瓶頸問題，可更快加載頁面

3. 緩解瞬間擁塞，可緩解原始服務(wù)器的壓力

4. 降低距離延時，加快響應(yīng)速度

目錄

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

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

3. DNS 緩存

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

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

6. HTTP 請求緩存（ CDN 節(jié)點緩存、代理服務(wù)器緩存、瀏覽器緩存、后端動態(tài)計算結(jié)果緩存等 ）

接下來我們進入正題(帶著答案，口味更佳)：

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

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

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

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

注意：不論什么時候，我們獲取的主頁面資源 timeline, 都應(yīng)該是重新請求服務(wù)器而獲得的，不可以使用本地瀏覽器的緩存。至于為什么？你看到靜態(tài)資源文件名的 hash 值你就應(yīng)該清楚了。

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

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

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

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

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

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

如掘金輸入 http://juejin.im/timeline 會跳轉(zhuǎn)到 https://juejin.im/timeline:

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

三、DNS 緩存

但你輸入 juejin.im 按下回車后，就開始對 juejin.im 進行域名解析。域名解析最少涉及了三個地方的緩存：

1. 瀏覽器的 DNS 緩存

2. 操作系統(tǒng)中的 DNS 緩存

3. 索操作系統(tǒng)的 hosts 文件（可手動寫入的緩存）

域名解析的具體過程

1. 瀏覽器搜索自己的 DNS 緩存（瀏覽器維護一張域名與 IP 地址的對應(yīng)表）；如果沒有命中，進入下一步；

2. 搜索操作系統(tǒng)中的 DNS 緩存；如果沒有命中，進入下一步；

3. 搜索操作系統(tǒng)的 hosts 文件（ Windows 環(huán)境下，維護一張域名與 IP 地址的對應(yīng)表）；如果沒有命中，進入下一步；

1. 操作系統(tǒng)將域名發(fā)送至 LDNS （本地區(qū)域名服務(wù)器），LDNS 查詢自己的 DNS 緩存（一般命中率在 80% 左右），查找成功則返回結(jié)果，失敗則發(fā)起一個迭代 DNS 解析請求：

2. LDNS向 Root Name Server（根域名服務(wù)器，如com、net、im 等的頂級域名服務(wù)器的地址）發(fā)起請求，此處，Root Name Server 返回 im 域的頂級域名服務(wù)器的地址；

3. LDNS 向 im 域的頂級域名服務(wù)器發(fā)起請求，返回 juejin.im 域名服務(wù)器地址；

4. LDNS 向 juejin.im 域名服務(wù)器發(fā)起請求，得到 juejin.im 的 IP 地址；

5. LDNS 將得到的 IP 地址返回給操作系統(tǒng)，同時自己也將 IP 地址緩存起來；操作系統(tǒng)將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來。

DNS Prefetch

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

1. 減少 DNS 的請求次數(shù)

2. 進行 DNS 預(yù)獲取

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

你可以通過 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)表，表中每一個條目分別記錄了其他主機的 IP 地址和對應(yīng)的 MAC 地址。

當(dāng)?shù)刂方馕鰠f(xié)議被詢問一個已知 IP 地址節(jié)點的 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 的流量(擁塞)控制便是依賴于這兩個獨立的 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)

A mechanism to prevent a TCP sender from overwhelming a TCP receiver.
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é)點緩存、代理服務(wù)器緩存、瀏覽器緩存、后端動態(tài)計算結(jié)果緩存等 ）

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

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

強緩存 ( Cache-Control 和 Expires )

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

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

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

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

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

指令	說明
no-cache	使用代理服務(wù)器的緩存之前提交原始服務(wù)器驗證，驗證通過才能使用
no-store	在客戶端或是代理服務(wù)器都不緩存請求或響應(yīng)的任何內(nèi)容
max-age=[秒]	告知服務(wù)器客戶端可接受資源的存在最大時間
max-stale(=[秒])	可接受（代理服務(wù)器緩存的）過期資源，參數(shù)可省略
min-fresh=[秒]	可接受（代理服務(wù)器緩存的）資源更新時間小于指定時間
no-transform	代理服務(wù)器不可以更改媒體類型
only-if-cached	客戶端只接受已緩存的響應(yīng)，若緩存不命中，則返回 504 錯誤
cache-extension	自定義擴展值，若服務(wù)器不知別該指令，就直接忽略

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

指令	說明
public	表明該資源可以給多個用戶使用
private(= name)	該資源是私有資源，指定的用戶可以使用的緩存
no-cache	強制每次請求直接發(fā)送給源服務(wù)器，而不經(jīng)過本地緩存版本的校驗。
no-store	在客戶端或是代理服務(wù)器都不緩存請求或響應(yīng)的任何內(nèi)容
no-transform	代理服務(wù)器不可以更改媒體類型
must-revalidate	可緩存但必須再向源服務(wù)器進行請求確認(rèn)
proxy-revalidate	要求緩存服務(wù)器返回緩存的時候向源服務(wù)器進行請求確認(rèn)
max-age=[秒]	告知客戶端該資源在規(guī)定時間內(nèi)是新鮮的，無需向服務(wù)器確認(rèn)
s-maxage=[秒]	告知緩存服務(wù)該資源在規(guī)定時間內(nèi)是新鮮的，無需向服務(wù)器確認(rèn)
cache-extension	自定義擴展值，若服務(wù)器不識別該指令，就直接忽略

可緩存性

1. public：響應(yīng)可以被任何對象（客戶端、代理服務(wù)器等）緩存

2. private：只能被單個用戶緩存，不能作為共享緩存

3. no-cache：使用緩存副本之前，需要將請求提交給原始服務(wù)器進行驗證，驗證通過才可以使用

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)

重新驗證和重新加載

1. must-revalidate：緩存必須在使用之前驗證舊資源的狀態(tài)，并且不可使用過期資源。

2. proxy-revalidate：與?must-revalidate?作用相同，但它僅適用于共享緩存（例如代理），并被私有緩存忽略

其他

1. no-store：徹底得禁用緩沖，本地和代理服務(wù)器都不緩沖，每次都從服務(wù)器獲取

2. no-transform：不得對資源進行轉(zhuǎn)換或轉(zhuǎn)變。?Content-Encoding,?Content-Range,?Content-Type?等?HTTP?頭不能由代理修改。

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

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

*Last-Modified 和 If-Modified-Since *

基于資源在服務(wù)器修改時間而驗證緩存的過期機制

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

Etag 和 If-None-Match

基于資源校驗碼（一般為md5值）而驗證緩存的過期機制

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

需要注意的是當(dāng)響應(yīng)頭中同時存在 Etag 和 Last-Modified 的時候，會先對 Etag 進行比對，隨后才是 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)頭中包含可強緩存的相關(guān)字段 cache-control ,同時也包含了協(xié)商緩存的相關(guān)字段 etag 和 last-modified;

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

1. 
   

   強緩存和協(xié)商緩存同時存在，如果強緩存還在有效期內(nèi)則直接使用緩存；如果強緩存不在有效期，協(xié)商緩存生效。
   即：強緩存優(yōu)先級 > 協(xié)商緩存優(yōu)先級

   
   

2. 
   

   強緩存的 expires 和 cache-control 同時存在時， cache-control 會覆蓋 expires 的效果， expires 無論有沒有過期，都無效。
   即：cache-control 優(yōu)先級 > expires 優(yōu)先級。

   
   

3. 
   

   協(xié)商緩存的 Etag 和 Last-Modified 同時存在時， Etag 會覆蓋 Last-Modified的效果。
   即：ETag 優(yōu)先級 > Last-Modified 優(yōu)先級。

   
   

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

其實我們第一次獲取的資源極有可能是從 CDN 節(jié)點的緩存中獲取的，也很有可能是從中間代理服務(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ù)器控制了。

關(guān)于動態(tài)資源一般前端是不做緩存的。

后端緩存主要通過保留數(shù)據(jù)庫連接，存儲處理結(jié)果等方式縮短處理時間，盡快響應(yīng)客戶端請求。