小男孩‘自慰网亚洲一区二区,亚洲一级在线播放毛片,亚洲中文字幕av每天更新,黄aⅴ永久免费无码,91成人午夜在线精品,色网站免费在线观看,亚洲欧洲wwwww在线观看

分享

底層網(wǎng)絡知識詳解-陌生的數(shù)據(jù)中心3-CDN

 小世界的野孩子 2022-10-12 發(fā)布于北京

上一節(jié),我們看到了網(wǎng)站的一般訪問模式。

當一個用戶想訪問一個網(wǎng)站的時候,指定這個網(wǎng)站的域名,DNS 就會將這個域名解析為地址,然后用戶請求這個地址,返回一個網(wǎng)頁。就像你要買個東西,首先要查找商店的位置,然后去商店里面找到自己想要的東西,最后拿著東西回家。

那這里面還有沒有可以優(yōu)化的地方呢?

例如你去電商網(wǎng)站下單買個東西,這個東西一定要從電商總部的中心倉庫送過來嗎?原來基本是這樣的,每一單都是單獨配送,所以你可能要很久才能收到你的寶貝。但是后來電商網(wǎng)站的物流系統(tǒng)學聰明了,他們在全國各地建立了很多倉庫,而不是只有總部的中心倉庫才可以發(fā)貨。

電商網(wǎng)站根據(jù)統(tǒng)計大概知道,北京、上海、廣州、深圳、杭州等地,每天能夠賣出去多少書籍、衛(wèi)生紙、包、電器等存放期比較長的物品。這些物品用不著從中心倉庫發(fā)出,所以平時就可以將它們分布在各地倉庫里,客戶一下單,就近的倉庫發(fā)出,第二天就可以收到了。

這樣,用戶體驗大大提高。當然,這里面也有個難點就是,生鮮這類東西保質(zhì)期太短,如果提前都備好貨,但是沒有人下單,那肯定就壞了。這個問題,我后文再說。

我們先說,我們的網(wǎng)站訪問可以借鑒“就近配送”這個思路。

全球有這么多的數(shù)據(jù)中心,無論在哪里上網(wǎng),臨近不遠的地方基本上都有數(shù)據(jù)中心。是不是可以在這些數(shù)據(jù)中心里部署幾臺機器,形成一個緩存的集群來緩存部分數(shù)據(jù),那么用戶訪問數(shù)據(jù)的時候,就可以就近訪問了呢?

當然是可以的。這些分布在各個地方的各個數(shù)據(jù)中心的節(jié)點,就稱為邊緣節(jié)點。

由于邊緣節(jié)點數(shù)目比較多,但是每個集群規(guī)模比較小,不可能緩存下來所有東西,因而可能無法命中,這樣就會在邊緣節(jié)點之上。有區(qū)域節(jié)點,規(guī)模就要更大,緩存的數(shù)據(jù)會更多,命中的概率也就更大。在區(qū)域節(jié)點之上是中心節(jié)點,規(guī)模更大,緩存數(shù)據(jù)更多。如果還不命中,就只好回源網(wǎng)站訪問了。

 

 這就是 CDN 分發(fā)系統(tǒng)的架構。CDN 系統(tǒng)的緩存,也是一層一層的,能不訪問后端真正的源,就不打擾它。這也是電商網(wǎng)站物流系統(tǒng)的思路,北京局找不到,找華北局,華北局找不到,再找北方局。

有了這個分發(fā)系統(tǒng)之后,接下來,客戶端如何找到相應的邊緣節(jié)點進行訪問呢?

還記得我們講過的基于 DNS 的全局負載均衡嗎?這個負載均衡主要用來選擇一個就近的同樣運營商的服務器進行訪問。你會發(fā)現(xiàn),CDN 分發(fā)網(wǎng)絡也是一個分布在多個區(qū)域、多個運營商的分布式系統(tǒng),也可以用相同的思路選擇最合適的邊緣節(jié)點。

 

 在沒有 CDN 的情況下,用戶向瀏覽器輸入 www.web.com 這個域名,客戶端訪問本地 DNS 服務器的時候,如果本地 DNS 服務器有緩存,則返回網(wǎng)站的地址;如果沒有,遞歸查詢到網(wǎng)站的權威 DNS 服務器,這個權威 DNS 服務器是負責 web.com 的,它會返回網(wǎng)站的 IP 地址。本地 DNS 服務器緩存下 IP 地址,將 IP 地址返回,然后客戶端直接訪問這個 IP 地址,就訪問到了這個網(wǎng)站。

然而有了 CDN 之后,情況發(fā)生了變化。在 web.com 這個權威 DNS 服務器上,會設置一個 CNAME 別名,指向另外一個域名 www.web.cdn.com,返回給本地 DNS 服務器。

當本地 DNS 服務器拿到這個新的域名時,需要繼續(xù)解析這個新的域名。這個時候,再訪問的就不是 web.com 的權威 DNS 服務器了,而是 web.cdn.com 的權威 DNS 服務器,這是 CDN 自己的權威 DNS 服務器。在這個服務器上,還是會設置一個 CNAME,指向另外一個域名,也即 CDN 網(wǎng)絡的全局負載均衡器。

接下來,本地 DNS 服務器去請求 CDN 的全局負載均衡器解析域名,全局負載均衡器會為用戶選擇一臺合適的緩存服務器提供服務,選擇的依據(jù)包括:

  • 根據(jù)用戶 IP 地址,判斷哪一臺服務器距用戶最近;
  • 用戶所處的運營商;
  • 根據(jù)用戶所請求的 URL 中攜帶的內(nèi)容名稱,判斷哪一臺服務器上有用戶所需的內(nèi)容;
  • 查詢各個服務器當前的負載情況,判斷哪一臺服務器尚有服務能力。

基于以上這些條件,進行綜合分析之后,全局負載均衡器會返回一臺緩存服務器的 IP 地址。

本地 DNS 服務器緩存這個 IP 地址,然后將 IP 返回給客戶端,客戶端去訪問這個邊緣節(jié)點,下載資源。緩存服務器響應用戶請求,將用戶所需內(nèi)容傳送到用戶終端。如果這臺緩存服務器上并沒有用戶想要的內(nèi)容,那么這臺服務器就要向它的上一級緩存服務器請求內(nèi)容,直至追溯到網(wǎng)站的源服務器將內(nèi)容拉到本地。

CDN 可以進行緩存的內(nèi)容有很多種。

保質(zhì)期長的日用品比較容易緩存,因為不容易過期,對應到就像電商倉庫系統(tǒng)里,就是靜態(tài)頁面、圖片等,因為這些東西也不怎么變,所以適合緩存。

 

 還記得這個接入層緩存的架構嗎?在進入數(shù)據(jù)中心的時候,我們希望通過最外層接入層的緩存,將大部分靜態(tài)資源的訪問攔在邊緣。而 CDN 則更進一步,將這些靜態(tài)資源緩存到離用戶更近的數(shù)據(jù)中心。越接近客戶,訪問性能越好,時延越低。

但是靜態(tài)內(nèi)容中,有一種特殊的內(nèi)容,也大量使用了 CDN,這個就是前面講過的流媒體。

CDN 支持流媒體協(xié)議,例如前面講過的 RTMP 協(xié)議。在很多情況下,這相當于一個代理,從上一級緩存讀取內(nèi)容,轉(zhuǎn)發(fā)給用戶。由于流媒體往往是連續(xù)的,因而可以進行預先緩存的策略,也可以預先推送到用戶的客戶端。

對于靜態(tài)頁面來講,內(nèi)容的分發(fā)往往采取拉取的方式,也即當發(fā)現(xiàn)未命中的時候,再去上一級進行拉取。但是,流媒體數(shù)據(jù)量大,如果出現(xiàn)回源,壓力會比較大,所以往往采取主動推送的模式,將熱點數(shù)據(jù)主動推送到邊緣節(jié)點。

對于流媒體來講,很多 CDN 還提供預處理服務,也即文件在分發(fā)之前,經(jīng)過一定的處理。例如將視頻轉(zhuǎn)換為不同的碼流,以適應不同的網(wǎng)絡帶寬的用戶需求;再如對視頻進行分片,降低存儲壓力,也使得客戶端可以選擇使用不同的碼率加載不同的分片。這就是我們常見的,“我要看超清、標清、流暢等”。

對于流媒體 CDN 來講,有個關鍵的問題是防盜鏈問題。因為視頻是要花大價錢買版權的,為了掙點錢,收點廣告費,如果流媒體被其他的網(wǎng)站盜走,在人家的網(wǎng)站播放,那損失可就大了。

最常用也最簡單的方法就是 HTTP 頭的 referer 字段, 當瀏覽器發(fā)送請求的時候,一般會帶上 referer,告訴服務器是從哪個頁面鏈接過來的,服務器基于此可以獲得一些信息用于處理。如果 refer 信息不是來自本站,就阻止訪問或者跳到其它鏈接。

referer 的機制相對比較容易破解,所以還需要配合其他的機制。

一種常用的機制是時間戳防盜鏈。使用 CDN 的管理員可以在配置界面上,和 CDN 廠商約定一個加密字符串。

客戶端取出當前的時間戳,要訪問的資源及其路徑,連同加密字符串進行簽名算法得到一個字符串,然后生成一個下載鏈接,帶上這個簽名字符串和截止時間戳去訪問 CDN。

在 CDN 服務端,根據(jù)取出過期時間,和當前 CDN 節(jié)點時間進行比較,確認請求是否過期。然后 CDN 服務端有了資源及路徑,時間戳,以及約定的加密字符串,根據(jù)相同的簽名算法計算簽名,如果匹配則一致,訪問合法,才會將資源返回給客戶。

然而比如在電商倉庫中,我在前面提過,有關生鮮的緩存就是非常麻煩的事情,這對應著就是動態(tài)的數(shù)據(jù),比較難以緩存。怎么辦呢?現(xiàn)在也有動態(tài) CDN,主要有兩種模式。

  • 一種為生鮮超市模式,也即邊緣計算的模式。既然數(shù)據(jù)是動態(tài)生成的,所以數(shù)據(jù)的邏輯計算和存儲,也相應的放在邊緣的節(jié)點。其中定時從源數(shù)據(jù)那里同步存儲的數(shù)據(jù),然后在邊緣進行計算得到結果。就像對生鮮的烹飪是動態(tài)的,沒辦法事先做好緩存,因而將生鮮超市放在你家旁邊,既能夠送貨上門,也能夠現(xiàn)場烹飪,也是邊緣計算的一種體現(xiàn)。
  • 另一種是冷鏈運輸模式,也即路徑優(yōu)化的模式。數(shù)據(jù)不是在邊緣計算生成的,而是在源站生成的,但是數(shù)據(jù)的下發(fā)則可以通過 CDN 的網(wǎng)絡,對路徑進行優(yōu)化。因為 CDN 節(jié)點較多,能夠找到離源站很近的邊緣節(jié)點,也能找到離用戶很近的邊緣節(jié)點。中間的鏈路完全由 CDN 來規(guī)劃,選擇一個更加可靠的路徑,使用類似專線的方式進行訪問。

對于常用的 TCP 連接,在公網(wǎng)上傳輸?shù)臅r候經(jīng)常會丟數(shù)據(jù),導致 TCP 的窗口始終很小,發(fā)送速度上不去。根據(jù)前面的 TCP 流量控制和擁塞控制的原理,在 CDN 加速網(wǎng)絡中可以調(diào)整 TCP 的參數(shù),使得 TCP 可以更加激進地傳輸數(shù)據(jù)。

可以通過多個請求復用一個連接,保證每次動態(tài)請求到達時。連接都已經(jīng)建立了,不必臨時三次握手或者建立過多的連接,增加服務器的壓力。另外,可以通過對傳輸數(shù)據(jù)進行壓縮,增加傳輸效率。

所有這些手段就像冷鏈運輸,整個物流優(yōu)化了,全程冷凍高速運輸。不管生鮮是從你旁邊的超市送到你家的,還是從產(chǎn)地送的,保證到你家是新鮮的。

 

小結

  • CDN 和電商系統(tǒng)的分布式倉儲系統(tǒng)一樣,分為中心節(jié)點、區(qū)域節(jié)點、邊緣節(jié)點,而數(shù)據(jù)緩存在離用戶最近的位置。
  • CDN 最擅長的是緩存靜態(tài)數(shù)據(jù),除此之外還可以緩存流媒體數(shù)據(jù),這時候要注意使用防盜鏈。它也支持動態(tài)數(shù)據(jù)的緩存,一種是邊緣計算的生鮮超市模式,另一種是鏈路優(yōu)化的冷鏈運輸模式。

 

    本站是提供個人知識管理的網(wǎng)絡存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導購買等信息,謹防詐騙。如發(fā)現(xiàn)有害或侵權內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多