【前端詞典】從輸入 URL 到展示涉及哪些緩存環節(很是詳細)

前言

緩存是一項用來提升網站性能不可或缺的技術，利用這項技術能夠很好地提升 web 的性能。 緩存能夠頗有效地下降網絡的時延，同時也會減小大量請求對於服務器的壓力。 你們在繼續看下去以前能夠先思考一下 「從輸入 URL 到頁面加載完成的過程當中都發生了什麼事情」。你如今所看到的其實就是這個熱點問題的一個變種問題。

不過這個問題對緩存會有一個更詳盡的解釋。我相信你看完這篇文章後對緩存會有一個全新的認識，若是沒有那就再看一遍。

入題

在這篇文章，我會詳盡的描述從輸入 URL 到展示涉及到的緩存環節，不過因爲本人知識有限，極可能有某些隱藏的緩存機制在下遺漏了，還請大佬不吝賜教。

在講「從輸入 URL 到展示涉及到的緩存環節」以前，咱們先了解下緩存的優勢：

緩存的幾個優勢

1. 減小冗餘的數據傳輸，可節省流量
2. 緩解帶寬瓶頸問題，可更快加載頁面
3. 緩解瞬間擁塞，可緩解原始服務器的壓力
4. 下降距離延時，加快響應速度

目錄

1. 地址欄網址緩存
2. 檢查 HSTS 預加載列表
3. DNS 緩存
4. ARP（地址解析協議）緩存
5. TCP 發送緩衝區 & 接收緩衝區
6. HTTP 請求緩存（ CDN 節點緩存、代理服務器緩存、瀏覽器緩存、後端動態計算結果緩存等 ）

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

1、地址欄網址緩存

輸入 url 後遇到的第一個緩存環節就是地址欄網址緩存。

但咱們輸入一個經常使用的網址時，常常會有這樣的狀況，咱們只是輸入了幾個字母，瀏覽器就自動補全了該網址。以下圖：我只輸入 j，就自動給我補全了 juejin.im：

當咱們使用這個自動補全的網址時，你會發現請求的相關的靜態資源也是從緩存中取得的。

注意：不論何時，咱們獲取的主頁面資源 timeline, 都應該是從新請求服務器而得到的，不可使用本地瀏覽器的緩存。至於爲何？你看到靜態資源文件名的 hash 值你就應該清楚了。

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

轉換非 ASCII 的 Unicode 字符

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

2、 檢查 HSTS 預加載列表

HSTS（ HTTP Strict Transport Security ）國際互聯網工程組織 IETE 正在推行一種新的 Web 安全協議，做用是強制客戶端（如瀏覽器）使用 HTTPS 與服務器建立鏈接。

採用 HSTS 後：支持這個協議的瀏覽器，在輸入 URL 後會檢查自帶的 HSTS 預加載列表（這個列表裏包含了那些請求瀏覽器只使用 HTTPS 進行鏈接的域名），若網站在這個列表裏，瀏覽器會使用 HTTPS 協議而且返回碼爲 307。而不支持 HSTS 的瀏覽器訪問咱們的網站，則不會產生跳轉，從而提升了兼容性。這個機制對於不支持 HTTPS 的搜索引擎來講是很是友好的！

如掘金輸入 http://juejin.im/timeline 會跳轉到 https://juejin.im/timeline:

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

3、DNS 緩存

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

1. 瀏覽器的 DNS 緩存
2. 操做系統中的 DNS 緩存
3. 索操做系統的 hosts 文件（可手動寫入的緩存）

域名解析的具體過程

1. 瀏覽器搜索本身的 DNS 緩存（瀏覽器維護一張域名與 IP 地址的對應表）；若是沒有命中，進入下一步；
2. 搜索操做系統中的 DNS 緩存；若是沒有命中，進入下一步；
3. 搜索操做系統的 hosts 文件（ Windows 環境下，維護一張域名與 IP 地址的對應表）；若是沒有命中，進入下一步；

1. 操做系統將域名發送至 LDNS （本地區域名服務器），LDNS 查詢本身的 DNS 緩存（通常命中率在 80% 左右），查找成功則返回結果，失敗則發起一個迭代 DNS 解析請求：
2. LDNS向 Root Name Server（根域名服務器，如com、net、im 等的頂級域名服務器的地址）發起請求，此處，Root Name Server 返回 im 域的頂級域名服務器的地址；
3. LDNS 向 im 域的頂級域名服務器發起請求，返回 juejin.im 域名服務器地址；
4. LDNS 向 juejin.im 域名服務器發起請求，獲得 juejin.im 的 IP 地址；
5. LDNS 將獲得的 IP 地址返回給操做系統，同時本身也將 IP 地址緩存起來；操做系統將 IP 地址返回給瀏覽器，同時本身也將 IP 地址緩存起來。

DNS Prefetch

即 DNS 預獲取，是前端優化的一部分。通常來講，在前端優化中與 DNS 有關的有兩點：

1. 減小 DNS 的請求次數
2. 進行 DNS 預獲取

典型的一次 DNS 解析須要耗費 20-120 毫秒，減小DNS解析時間和次數是個很好的優化方式。DNS Prefetching 是讓具備此屬性的域名不須要用戶點擊連接就在後臺解析，而域名解析和內容載入是串行的網絡操做，因此這個方式能減小用戶的等待時間，提高用戶體驗。

你能夠經過 chrome://net-internals/#dns 查找目前系統中的 DNS 緩存和 Chrome 中使用的狀況。

提個問題

問：瀏覽器 DNS 緩存的時間通常不會太長，一分鐘左右。爲何緩存不設置較長時間呢？

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

4、ARP（地址解析協議）緩存

ARP 是一種用以解釋地址的協議，根據通訊方的 IP 地址就能夠反查出對應方的 MAC 地址。

ARP 緩存是個用來儲存 IP 地址和 MAC 地址的緩衝區，其本質就是一個 IP 地址與 MAC 地址的對應表，表中每個條目分別記錄了其餘主機的 IP 地址和對應的 MAC 地址。

當地址解析協議被詢問一個已知 IP 地址節點的 MAC 地址時，先在 AR 緩存中查看，若存在，就直接返回與之對應的MAC地址；若不存在，才發送 ARP 請求查詢。

具體的 ARP 請求查詢感興趣的同窗能夠自行研究。

5、TCP 發送緩衝區 & 接收緩衝區

創建 TCP 鏈接這一步也涉及到緩存 —— 用來臨時存放雙方通訊的數據，保證通訊數據不會丟包。

每一個 TCP 鏈接在內核中都有一個發送緩衝區和接收緩衝區，TCP 的全雙工的工做模式以及 TCP 的流量(擁塞)控制即是依賴於這兩個獨立的 buffer 以及 buffer 的填充狀態。

發送緩衝區

發送緩衝區存放的是 send() 方法從應用緩衝區拷貝過來的數據。

內核基本上是按照 MSS（Maximum Segment Size，最大報文段長度） 從緩衝區中取數據發送出去，當緩衝區中數據小於 MSS，則將剩餘數據所有發送出去。TCP 的發送緩衝區必須爲已發送的數據保留一個副本，直到它被對端確認爲止，才能從緩衝區中刪掉已確認的數據。

接收緩衝區

接收緩衝區被 TCP 用來保存接收到的數據，直到應用程序來讀取。

接收緩衝區把數據緩存入內核，等待 recv() 方法讀取，recv() 方法所作的工做，就是把內核緩衝區中的數據拷貝到應用層用戶的 buffer 裏面，拷貝後就刪掉已確認的數據。

流控制(Flow Control)

A mechanism to prevent a TCP sender from overwhelming a TCP receiver.
TCP 流控制主要用於匹配發送端和接收端的速度，即根據接收端當前的接收能力來調整發送端的發送速度。

因爲發送速度可能大於接收速度，接收端的應用程序未能及時從接收緩衝區讀取數據，接收緩衝區不夠大不能緩存全部接收到的報文等緣由，TCP接收端的接收緩衝區很快就會被塞滿；從而致使不能接收後續的數據，發送端此後發送數據是無效的，所以須要流控制。

TCP 的緩存就講到這裏，感興趣的能夠本身翻閱資料。

6、HTTP 請求緩存（ CDN 節點緩存、代理服務器緩存、瀏覽器緩存、後端動態計算結果緩存等 ）

在創建了 TCP 鏈接以後，就開始 HTTP 請求了；而 HTTP 緩存是優化性能不可忽視的一部分，這一部分我會着重講解。

再講具體過程以前，我再講一遍強緩存和協商緩存。

強緩存 ( Cache-Control 和 Expires )

強緩存主要是採用響應頭中的 Cache-Control 和 Expires 兩個字段進行控制的。

其中 Expires 是 HTTP 1.0 中定義的，它指定了一個絕對的過時時期。而 Cache-Control 是 HTTP 1.1 時出現的緩存控制字段。 因爲 Expires 是 HTTP1.0 時代的產物，所以設計之初就存在着一些缺陷，若是本地時間和服務器時間相差太大，就會致使緩存錯亂。

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

這兩個字段的效果是相似的，客戶端都會經過對比本地時間和服務器返回的生存時間來檢測緩存是否可用。若是緩存沒有超出它的生存時間，客戶端就會直接採用本地的緩存。若是生存日期已通過了，這個緩存也就宣告失效。接着客戶端將再次與服務器進行通訊來驗證這個緩存是否須要更新。

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

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

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

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

可緩存性

1. public：響應能夠被任何對象（客戶端、代理服務器等）緩存
2. private：只能被單個用戶緩存，不能做爲共享緩存
3. no-cache：使用緩存副本以前，須要將請求提交給原始服務器進行驗證，驗證經過纔可使用
4. only-if-cached：客戶端只接受已緩存的響應，而且不向原始服務器檢查是否有更新的拷貝

到期

1. max-age=<seconds>：緩存存儲的最大週期，超過這個時間緩存被認爲過時(單位秒)。與 Expires 相反，時間是相對於請求的時間
2. s-maxage=<seconds>：覆蓋 max-age 或者 Expires 頭，可是僅適用於共享緩存(好比各個代理)，而且私有緩存中它被忽略
3. max-stale[=<seconds>]：代表客戶端願意接收一個已通過期的資源。可選的設置一個時間(單位秒)，表示響應不能超過的過期時間
4. min-fresh=<seconds>：表示客戶端但願在指定的時間內獲取最新的響應

從新驗證和從新加載

1. must-revalidate：緩存必須在使用以前驗證舊資源的狀態，而且不可以使用過時資源。
2. proxy-revalidate：與 must-revalidate 做用相同，但它僅適用於共享緩存（例如代理），並被私有緩存忽略

其餘

1. no-store：完全得禁用緩衝，本地和代理服務器都不緩衝，每次都從服務器獲取
2. no-transform：不得對資源進行轉換或轉變。Content-Encoding, Content-Range, Content-Type 等 HTTP 頭不能由代理修改。

協商緩存 ( Last-Modified 和 Etag )

協商緩存機制下，瀏覽器須要向服務器去詢問緩存的相關信息，進而判斷是從新發起請求仍是從本地獲取緩存的資源。若是服務端提示緩存資源未改動（ Not Modified ），資源會被重定向到瀏覽器緩存，這種狀況下網絡請求對應的狀態碼是 304。

**Last-Modified 和 If-Modified-Since **

基於資源在服務器修改時間而驗證緩存的過時機制

當客戶端再次請求該資源的時候，會在其請求頭上附帶上 If-Modified-Since 字段（值就是第一次獲取請求資源時響應頭中返回的 Last-Modified 值）。若是修改時間未改變則代表資源未過時，命中緩存，服務器就直接返回 304 狀態碼，客戶端直接使用本地的資源。不然，服務器從新發送響應資源，從而保證資源的有效性。

Etag 和 If-None-Match

基於資源校驗碼（通常爲md5值）而驗證緩存的過時機制

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

須要注意的是當響應頭中同時存在 Etag 和 Last-Modified 的時候，會先對 Etag 進行比對，隨後纔是 Last-Modified。

Etag 的問題
相同的資源，在兩臺服務器產生的 Etag 是否是相同的，因此對於使用服務器集羣來處理請求的網站來講，Etag 的匹配機率會大幅下降。所在在這種狀況下，使用 Etag 來處理緩存，反而會有更大的開銷。

靜態資源和動態資源的請求過程解析

靜態資源
第一次請求確定是從服務器請求過來的資源，這個沒有什麼疑問，咱們先看看第一次請求的響應頭的內容：

咱們發現第一次的響應頭中包含可強緩存的相關字段 cache-control ,同時也包含了協商緩存的相關字段 etag 和 last-modified;

當強緩存和協商緩存字段同時存在時會進行如下步驟來請求資源：

1. 強緩存和協商緩存同時存在，若是強緩存還在有效期內則直接使用緩存；若是強緩存不在有效期，協商緩存生效。
   即：強緩存優先級 > 協商緩存優先級

2. 強緩存的 expires 和 cache-control 同時存在時，cache-control 會覆蓋 expires 的效果，expires 不管有沒有過時，都無效。
   即：cache-control 優先級 > expires 優先級。

3. 協商緩存的 Etag 和 Last-Modified 同時存在時，會先對 Etag 進行比對，隨後纔是 Last-Modified。 即：ETag 優先級 > Last-Modified 優先級。

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

其實咱們第一次獲取的資源極有多是從 CDN 節點的緩存中獲取的，也頗有多是從中間代理服務器（nginx，node 等）的緩存中讀取的；其中的好處不言而喻。

動態資源

因爲動態資源的返回結果不一致，因此這個咱們確定不會在瀏覽器（中間代理服務器）緩存動態的結果。

不過這裏咱們能夠在後端緩存一些重複率比較高的相關的計算結果。

如：這裏有 60 只股票，用戶能夠選擇其中幾隻股票做爲本身的股票投資池。用戶選擇完股票後提交，會經過相關的算法計算其預期收益效果等指標。咱們知道每次計算的時間可能會比較久，因此在這步咱們能夠在後端將可能的組合結果先計算好緩存起來，當咱們請求的時候就後端就能夠直接返回已經計算好的結果給前端。至於計算結果的緩存時間也就徹底由服務器控制了。

關於動態資源通常前端是不作緩存的。

後端緩存主要經過保留數據庫鏈接，存儲處理結果等方式縮短處理時間，儘快響應客戶端請求。

成功得到資源後就開始客戶端渲染，接下來的相關解析過程這裏我就不講了，有興趣的同窗能夠留言交流。

前端詞典系列

《前端詞典》這個系列會持續更新，每一期我都會講一個出現頻率較高的知識點。但願你們在閱讀的過程中能夠斧正文中出現不嚴謹或是錯誤的地方，本人將不勝感激；若經過本系列而有所得，本人亦將不勝欣喜。

若是你以爲個人文章寫的還不錯，能夠關注個人微信公衆號，公衆號裏會提早劇透呦。

你也能夠添加個人微信 wqhhsd， 歡迎交流。

傳送門

1. 【前端詞典】和媳婦講代理後的意外收穫
2. 【前端詞典】滾動穿透問題的解決方案
3. 繼承（一） - 原型鏈你真的懂嗎？
4. 【前端詞典】繼承（二） - 回的八種寫法·面試必問
5. 【前端詞典】進階必備的網絡基礎（上）
6. 【前端詞典】進階必備的網絡基礎（下）
7. 【前端詞典】F5 同 Ctrl+F5 的區別你可瞭解
8. 【前端詞典】實現 Canvas 下雪背景引起的性能思考