天天看點
傳回

CDN緩存的了解

CDN緩存的了解

CDN

即内容分發網絡

Content Delivery Network

，

CDN

的基本原理是廣泛采用各種緩存伺服器，将這些緩存伺服器分布到使用者通路相對集中的地區或網絡中，在使用者通路網站時，利用全局負載技術将使用者的通路指向距離最近的工作正常的緩存伺服器上，由緩存伺服器直接響應使用者請求，

CDN

的基本思路是盡可能避開網際網路上有可能影響資料傳輸速度和穩定性的瓶頸和環節，使内容傳輸的更快、更穩定，通過在網絡各處放置節點伺服器所構成的在現有的網際網路基礎之上的一層虛拟網絡，

CDN

系統能夠實時地根據網絡流量和各節點的連接配接、負載狀況以及到使用者的距離和響應時間等綜合資訊将使用者的請求重新導向離使用者最近的服務節點上，其目的是使使用者可就近取得所需内容，解決

Internet

網絡擁擠的狀況，提高使用者通路網站的響應速度。

組成

  • 從功能上看，

    CDN

     系統由分發服務系統、負載均衡系統和營運管理系統組成：分發服務系統主要負責資源的響應、緩存和同步。負載均衡系統主要負責均衡單點多個内容緩存裝置的負載，并對内容進行緩存負載平衡及通路控制，以及對使用者請求進行排程以及路由。營運管理系統則負責營運需求管理和網絡系統管理。
  • 從節點分布上看，

    CDN

     系統主要分為邊緣層和中心層，邊緣層分布在

    CDN

     網絡的邊緣位置，給使用者提供就近通路服務，中心層則負責完成資源同步和營運管理等功能。中心層儲存了加速域名的相關配置資訊比如源站域名，也緩存了加速域名下的各種資源，在邊緣層節點未命中緩存時，需要向中心層節點發起請求，而中心層節點未能命中緩存時，需要查找對應的源站域名，并向該源站域名發起請求，然後再逐層傳回并緩存使用者請求的資源。

功能

  • 節省骨幹網帶寬，減少帶寬需求量。
  • 降低通信風暴的影響，提高網絡通路的穩定性。
  • 提供伺服器端加速，解決由于使用者通路量大造成的伺服器過載問題。
  • 能克服網站使用者分布不均的問題，并且能降低網站自身建設和維護成本。
  • 提供資源通路緩存，實作相同對象的通路降低響應延遲，并減少主幹網帶寬占用。

關鍵技術

  • 緩存算法決定命中率、源伺服器壓力、

    POP

     節點存儲能力。
  • 分發能力取決于

    IDC

     能力和

    IDC

     政策性分布。
  • 負載均衡決定最佳路由、響應時間、可用性、服務品質。
  • 基于

    DNS

     的負載均衡以

    CNAME

     實作最優節點服務。
  • 緩存點有用戶端浏覽器緩存、本地

    DNS

     伺服器緩存。
  • 緩存内容有

    DNS

     位址緩存、客戶請求内容緩存、動态内容緩存。
  • 支援協定如靜動态加速、圖檔加速、

    HTTPS

     帶證書加速、下載下傳加速等等。

配置

使用

CDN

服務提供商的

CDN

服務時，需要做一些配置：

  • 解析一個子域名，可以先随意解析到某個位址，例如是

    cdn.example.com

     。
  • 到服務提供商添加該域名，并設定源站域名，例如是

    www.example.com
  • 此時服務商一般會配置設定一個

    CNAME

     位址，例如是

    cdn.example.com.service.com
  • 将第一步的域名添加

    CNAME

     記錄為配置設定的

    CNAME

     位址。
  • 或者服務商在第一步即提供了

    CNAME

     位址，那麼直接解析即可。

通路流程

簡單的

CDN

的通路流程，這是一種

pull

的方式拉取緩存：

  • 通路資源時，從上述的子域名中加載資源檔案，

    DNS

     解析該域名。
  • 傳回

    CNAME

     位址，之後解析

    CNAME
  • 獲得

    CNAME

     域名對應的

    IP

     位址，指向

    CDN

     邊緣層節點。

  • CDN

     邊緣層節點未命中資源緩存，則向中心層節點請求。
  • 中心層節點未命中資源緩存，則進行回源，到源站域名伺服器擷取資源。
  • 成功擷取資源後逐層傳回并将資源緩存。
  • 在這個查找資源的過程中域名可能會發生變化，但是資源的

    path

     是不會變化的。
  • 之後再進行通路，則直接能夠從邊緣節點取得緩存而不用回源，加快資源通路速度。

緩存控制

在計算機中有兩大難題，一是緩存何時失效，二是如何命名，而

CDN

中緩存何時失效是一個比較麻煩的問題，假如源站的資源檔案發生變化，而使用者此時取得的資源是從緩存節點中取得的，此時就會造成資源檔案不一緻的現象，解決這個問題可以通過主動

push

重新整理所有

CDN

緩存的方式來實作，但是這種方式成本較高，比較簡單的解決方案就是在固定時間段過後便使緩存失效，除了節點的緩存需要控制，還需要控制使用者本地緩存，在

HTTP

協定中提供了如下緩存控制的方式：

強緩存

強緩存是通過

Expires

與

Cache-Control

來控制緩存在本地的有效期。

Expires

Expires

是

HTTP 1.0

提出的一個表示資源過期時間的

Header

，它描述的是一個絕對時間，由伺服器傳回。

Expires

受限于本地時間，如果修改了本地時間，可能會造成緩存失效.對于資源的請求，如果在

Expires

之内，則浏覽器會直接讀取緩存，不再請求伺服器。

Expires: Sun, 14 Jun 2020 02:50:57 GMT

Cache-Control

Cache-Control

出現于

HTTP 1.1

，優先級高于

Expires

，表示的是相對時間，請求頭和響應頭都支援這個屬性，通過它提供的不同的值來定義緩存政策。

Cache-Control: max-age=300

  • Cache-Control: no-store

     : 緩存中不得存儲任何關于用戶端請求和服務端響應的内容，每次由用戶端發起的請求都會下載下傳完整的響應内容。

  • Cache-Control: no-cache

     : 緩存中會存儲服務端響應的内容，隻是在與服務端進行新鮮度再驗證之前，該緩存不能夠提供給浏覽器使用。簡單來說，就是浏覽器會将服務端響應的資源進行緩存，但是在每次請求時，緩存都要向服務端評估緩存響應的有效性，協商緩存是否可用，根據響應是

    304

     還是

    200

     判斷是使用本地緩存資源還是使用伺服器響應的資源。

  • Cache-Control: public || private

     :

    public

     表示該響應可以被任何中間人比如中間代理、

    CDN

     等緩存。預設響應為

    private

    private

     表示該響應是專用的，中間人不能緩存此響應，該響應隻能應用于浏覽器私有緩存中。

  • Cache-Control: max-age=31536000

     : 響應為最大的過期時間，其指令是

    max-age=<seconds>

     ，表示資源能夠被緩存即保持新鮮的最大時間，

    max-age

     是距離請求發起的時間的秒數。

  • Cache-Control: must-revalidate

     : 當使用了

    must-revalidate

     指令，那就意味着緩存在考慮使用一個陳舊的資源時，必須先驗證它的狀态，已過期的緩存将不被使用。在正常情況下是沒有必要使用這個指令的，因為在強緩存過期的情況下會進行協商緩存，但是

    HTTP

     規範是允許用戶端在某些特殊情況下直接使用過期緩存的，比如校驗請求發送失敗的時候，還比如有配置一些特殊指令

    stale-while-revalidate

     、

    stale-if-error

     等的時候，

    must-revalidate

     指令就是讓緩存在過期後的任何情況下都必須重新驗證。

協商緩存

當浏覽器對某個資源的請求沒有命中強緩存，就會發一個請求到伺服器，驗證協商緩存是否命中，如果協商緩存命中，請求響應傳回的

HTTP

狀态為

304 (Not Modified)

，該請求不攜帶實體資料，若未命中，則傳回

200

并攜帶資源實體資料。協商緩存是利用的是

Last-Modified，If-Modified-Since

和

ETag、If-None-Match

這兩對

Header

來管理的。

Last-Modified If-Modified-Since

Last-Modified，If-Modified-Since

HTTP 1.0

引入的，

Last-Modified

表示本地檔案最後修改日期，浏覽器會在請求頭加上

If-Modified-Since

即上次響應的

Last-Modified

的值，詢問伺服器在該日期後資源是否有更新，有更新的話就會将新的資源發送回來，但是如果在本地打開緩存檔案，就會造成

Last-Modified

被修改，是以在

HTTP 1.1

出現了

ETag

ETag If-None-Match

Etag

就像一個指紋，資源變化都會導緻

ETag

變化，跟最後修改時間沒有關系，

ETag

可以保證每一個資源是唯一的，

If-None-Match

的請求頭字段會将上次傳回的

Etag

發送給伺服器，詢問該資源的

Etag

是否有更新，有變動就會發送新的資源回來。

ETag

的優先級比

Last-Modified

更高，具體使用

ETag

主要出于下面幾種情況考慮：

  • 一些檔案也許會周期性的更改，但是他的内容并不改變，比如僅僅改變的修改時間，這個時候我們并不希望用戶端認為這個檔案被修改了，而重新

    GET
  • 某些檔案修改非常頻繁，比如在秒以下的時間内進行修改，例如

    1s

     内修改了

    N

     次，

    If-Modified-Since

     能檢查到的粒度是秒級的，這種修改無法判斷。
  • 某些伺服器不能精确的得到檔案的最後修改時間。

每日一題 

https://github.com/WindrunnerMax/EveryDay

參考 

https://zhuanlan.zhihu.com/p/40682772
https://baike.baidu.com/item/CDN/420951
https://juejin.im/post/6844904190913822727
https://juejin.im/post/6844903906296725518
https://juejin.im/post/6844903605888090125
https://blog.csdn.net/pedrojuliet/article/details/78394732
上一篇: Document對象
下一篇: domReady的了解