關於 cdn、回源等問題一網打盡

覆盤平常問題板的時候,看到了曾經聽到後端同窗討論的回源的問題。一直以來對 cdn 相關的知識只知其一;不知其二,藉此機會完全梳理一下。html

文章目錄:

  • 訪問 cdn 資源和不經過 cdn 訪問的過程有什麼不一樣
  • 回源是什麼意思?
  • 除了靜態資源,API 是否能夠緩存?
  • 資源的過時如何斷定?cdn 是如何更新數據的?
  • 幾個專業術語

訪問 cdn 資源和不經過 cdn 訪問的過程有什麼不一樣

通常的過程咱們都知道了,再也不贅述。下面咱們來看看訪問 cdn 的過程。 git

cdn 訪問過程(盜圖)
1.首先訪問本地的 DNS ,若是沒有命中,繼續遞歸或者迭代查找,直到命中拿到對應的 IP 地址。 2.拿到對應的 IP 地址以後服務器端發送請求到目的地址。注意這裏返回的不直接是 cdn 服務器的 IP 地址,而是全局負載均衡系統的 IP 地址 4.全局負載均衡系統會根據客戶端的 IP地址和請求的 url 和相應的區域負載均衡系統通訊 5.區域負載均衡系統拿着這兩個東西獲取距離客戶端最近且有相應資源的cdn 緩存服務器的地址,返回給全局負載均衡系統 6.全局負載均衡系統返回肯定的 cdn 緩存服務器的地址給客戶端。 7.客戶端請求緩存服務器上的文件

簡單來講,其實 cdn 就是個放服務端資源的一個倉庫。康師傅的泡麪若是不是有家門口的小賣部,咱們就得去人家的工廠門口拿。有了小賣部,咱們只須要去一個賣康師傅&&有貨的小賣部拿,就是這個道理。github

其中有一個比較重要的點,在過程1裏:這個過程當中,有一個 CNAME 的過程,咱們訪問 cdn 資源的地址通常是 a.cloud.com 或者相似的地址,是一個公司的訪問 cdn 的專用地址。可是咱們用的 cdn 的服務倒是第三方的,即其實資源在他們的地址上好比 tencent.cdn。這時候就須要在 dns 查詢的時候,須要把咱們訪問 a.cloud.com的地址映射到 tencent.cdn 的地址上,而後拿着映射後的地址再去走一遍 dns 解析,成功以後才獲取到第三方提供的全局負載均衡系統的 IP。再繼續走後面的流程。web

回源是什麼意思?

當 cdn 緩存服務器中沒有符合客戶端要求的資源的時候,緩存服務器會請求上一級緩存服務器,以此類推,直到獲取到。最後若是仍是沒有,就會回到咱們本身的服務器去獲取資源。 那都有哪些時候會回源呢?沒有資源,資源過時,訪問的資源是不緩存資源等都會致使回源。其餘狀況歡迎小夥伴們在評論區補充~數據庫

除了靜態資源,API 是否能夠緩存?

注意題目所描述的狀況不是 cdn 的動態加速。後端

動態加速的對象是動態生成的網頁,動態加速通常是對針對內容(如數據庫信息等)在用戶與- 源站之間創建高速通道,經過路由優化、TCP加速等技術手段對動態內容進行加速,下降節點到源站之間的時延,從而大大下降了用戶訪問動態網頁的延遲。api

其實這個問題我沒有找到比較合適的解答,下面我想說一下我我的的看法。 咱們使用 cdn 的緣由是,咱們常常有一些比較頻繁請求且容量比較大的文件,而且更新頻率不那麼高的文件。這些文件若是咱們都放在本身的服務器上,於客戶端問題在於訪問時間長,於服務器端是佔用服務器端的資源。因此咱們採用分佈式的方式扔在 cdn 上。可是 API 不一樣,首先他常更新,其次他多和用戶信息等相關聯,而且 cdn 判斷是否緩存是依靠 url,意味着他只能緩存 get 請求,因此他的應用範圍是有限的。而且 api 常更新,推送更新到全部 cdn 節點一樣是須要耗費資源的。因此 API 是不適合放在 cdn 上的。可是若是你的內容是相對靜態的,不涉及和用戶信息關聯,而且能在一段時間內容忍緩存,更新不頻繁,那麼也不是不能考慮。緩存

資源的過時如何斷定?cdn 是如何更新數據的?

資源過時時間就是根據咱們老生常談的請求頭部來斷定。這個後面會單拎出一篇文章帶你們複習一下。 那麼 cdn 是如何更新數據的?分兩種,主動(PUSH)和被動(PULL)。被動剛纔咱們已經提到過了,利用回源就能夠被動在途經的 cdn 節點緩存數據。 而主動指的是,咱們從服務器主動往 cdn 推送數據。服務器

幾個專業術語

邊緣節點:指距離最終用戶接入具備較少的中間環節的網絡節點網絡

參考文獻: CDN 學習中的一點小思考 CDN 命中率、回源率常見問題 CDN緩存那些事 讓 API 也上 CDN 吧 CDN的基本工做過程 CDN是什麼?使用CDN有什麼優點? cname記錄是什麼?他存在的意義是什麼? CDN工做原理(CNAME) 【CDN 最佳實踐】CDN緩存策略解讀和配置策略 CDN緩存那些事兒

相關文章
相關標籤/搜索