摘要:支持流媒體協(xié)議。流媒體數(shù)據(jù)量大,如果出現(xiàn)回源,壓力會(huì)比較大,所以往往采取主動(dòng)推送的模式,將熱點(diǎn)數(shù)據(jù)主動(dòng)推送到邊緣節(jié)點(diǎn)。除此之外,流媒體還有個(gè)關(guān)鍵的防盜鏈問(wèn)題。在服務(wù)端,取出過(guò)期時(shí)間,和當(dāng)前節(jié)點(diǎn)時(shí)間進(jìn)行比較,確認(rèn)請(qǐng)求是否過(guò)期。
【前五篇】系列文章傳送門(mén):
網(wǎng)絡(luò)協(xié)議 13 - HTTPS 協(xié)議:加密路上無(wú)盡頭
網(wǎng)絡(luò)協(xié)議 14 - 流媒體協(xié)議:要說(shuō)愛(ài)你不容易
網(wǎng)絡(luò)協(xié)議 15 - P2P 協(xié)議:小種子大學(xué)問(wèn)
網(wǎng)絡(luò)協(xié)議 16 - DNS 協(xié)議:網(wǎng)絡(luò)世界的地址簿
網(wǎng)絡(luò)協(xié)議 17 - HTTPDNS:私人定制的 DNS 服務(wù)
????到現(xiàn)在為止,我們基本上已經(jīng)了解了網(wǎng)絡(luò)協(xié)議中的大部分常用協(xié)議,對(duì)于整個(gè) HTTP 請(qǐng)求流程也較為熟悉了。從無(wú)到有后,我們就要考慮如何優(yōu)化“有”這個(gè)過(guò)程,也就是我們常見(jiàn)的請(qǐng)求優(yōu)化。而現(xiàn)在的技術(shù)棧中,CDN 是最常用的一種方式。
????在了解 CDN 前,我們可以先了解下現(xiàn)代社會(huì)的物流配送。
????例如我們?nèi)ル娚叹W(wǎng)站下單買(mǎi)東西,這個(gè)東西一定要從電商總部的中心倉(cāng)庫(kù)送過(guò)來(lái)嗎?在電商剛興起的時(shí)候,所有的配送都是從中心倉(cāng)庫(kù)發(fā)貨,所以買(mǎi)家可能要很久才能收到貨。但是后來(lái)電商網(wǎng)站的物流系統(tǒng)學(xué)聰明了,他們?cè)谌珖?guó)各地建立了很多倉(cāng)庫(kù),而不是只有總部的中心倉(cāng)庫(kù)才可以發(fā)貨。
????電商網(wǎng)站根據(jù)統(tǒng)計(jì)大概知道,北京、上海、廣州、深圳、杭州等地,每天能夠賣(mài)出去多少書(shū)籍、紙巾、包、電器等存放期較長(zhǎng)的商品,就將這些商品分布存放在各地倉(cāng)庫(kù)中,客戶(hù)一下單,就從臨近的倉(cāng)庫(kù)發(fā)貨,大大減少了運(yùn)輸時(shí)間,提高了用戶(hù)體驗(yàn)。
????同樣的,互聯(lián)網(wǎng)也借鑒了“就近配送”這個(gè)思路。
CDN 就近配送????全球有那么多的數(shù)據(jù)中心,無(wú)論在哪里上網(wǎng),臨近不遠(yuǎn)的地方基本上都有數(shù)據(jù)中心??梢栽诿總€(gè)數(shù)據(jù)中心里部署幾臺(tái)機(jī)器,形成一個(gè)緩存集群來(lái)緩存部分熱數(shù)據(jù),這樣用戶(hù)訪(fǎng)問(wèn)數(shù)據(jù)的是,就可以就近訪(fǎng)問(wèn)了。
????這些分布在各個(gè)地方的各個(gè)數(shù)據(jù)中心的節(jié)點(diǎn),我們一般稱(chēng)為邊緣節(jié)點(diǎn)。
????由于邊緣節(jié)點(diǎn)數(shù)目比較多,但是每個(gè)集群規(guī)模比較小,不可能緩存下來(lái)所有東西,因而可能無(wú)法命中,這樣就會(huì)在邊緣節(jié)點(diǎn)之上,形成了區(qū)域節(jié)點(diǎn)。
????區(qū)域節(jié)點(diǎn)規(guī)模較大,緩存的數(shù)據(jù)也較多,命中的概率也就更大。而在區(qū)域節(jié)點(diǎn)之上是中心節(jié)點(diǎn),規(guī)模更大,緩存數(shù)據(jù)更多。
????就這樣,在這樣一層層的節(jié)點(diǎn)中緩存數(shù)據(jù),提高響應(yīng)速度。但是所有的節(jié)點(diǎn)都沒(méi)有緩存數(shù)據(jù),就只有進(jìn)行回源網(wǎng)站訪(fǎng)問(wèn)了。
????如上圖,就是 CDN 的分發(fā)系統(tǒng)的架構(gòu)。CDN 系統(tǒng)的緩存,是一層層的,能不訪(fǎng)問(wèn)源數(shù)據(jù),就不訪(fǎng)問(wèn)。這也是電商網(wǎng)站物流系統(tǒng)的思路,廣州找不到,找華南局,華南局找不到,再找南方局。
????有了這個(gè)分發(fā)系統(tǒng)之后,客戶(hù)端如何找到相應(yīng)的邊緣節(jié)點(diǎn)進(jìn)行訪(fǎng)問(wèn)呢?
????還記得咱們之前了解的基于 DNS 的全局負(fù)載均衡嗎?這個(gè)負(fù)載均衡主要用來(lái)選擇一個(gè)就近的相同運(yùn)營(yíng)商的服務(wù)器進(jìn)行訪(fǎng)問(wèn)。
????同樣的,CDN 分發(fā)網(wǎng)絡(luò)也可以用相同的思路選擇最合適的邊緣節(jié)點(diǎn)。
????如上圖,CDN 的負(fù)載均衡流程圖。
1)沒(méi)有 CDN 的情況(圖中虛線(xiàn)部分)。用戶(hù)向?yàn)g覽器輸入 www.web.com 這個(gè)域名,客戶(hù)端訪(fǎng)問(wèn)本地 DNS 服務(wù)器的時(shí)候,如果本地 DNS 服務(wù)器有緩存,則返回網(wǎng)站的地址。如果沒(méi)有,遞歸查詢(xún)到網(wǎng)站的權(quán)威 DNS 服務(wù)器,這個(gè)權(quán)威 DNS 服務(wù)器是負(fù)責(zé) web.com 的,它會(huì)返回網(wǎng)站的 IP 地址。本地 DNS 服務(wù)器緩存下 IP 地址,將 IP 地址返回,然后客戶(hù)端直接訪(fǎng)問(wèn)這個(gè) IP 地址,就訪(fǎng)問(wèn)到了網(wǎng)站。
2)有 CDN 的情況(圖中實(shí)線(xiàn)部分)。此時(shí),在 web.com 這個(gè)權(quán)威 DNS 服務(wù)器上,會(huì)設(shè)置一個(gè) CNAME 別名,指向另外一個(gè)域名 www.web.cdn.com,返回給本地 DNS 服務(wù)器。
????當(dāng)本地 DNS 服務(wù)器拿到這個(gè)新的域名時(shí),需要繼續(xù)解析這個(gè)新的域名。這個(gè)時(shí)候,再訪(fǎng)問(wèn)的就不是 web.com 這個(gè)權(quán)威 DNS 服務(wù)器了,而是 web.cdn.com 的權(quán)威 DNS 服務(wù)器,這是 CDN 自己的權(quán)威 DNS 服務(wù)器,在這個(gè)服務(wù)器上,還是會(huì)設(shè)置一個(gè) CNAME,指向另外一個(gè)域名,也就是 CDN 網(wǎng)絡(luò)的全局負(fù)載均衡器。
????接下來(lái),本地 DNS 服務(wù)器去請(qǐng)求 CDN 的全局負(fù)載均衡器解析域名。全局負(fù)載均衡器會(huì)為用戶(hù)選擇一臺(tái)合適的緩存服務(wù)器提供服務(wù),選擇的依據(jù)包括:
根據(jù)用戶(hù) IP 地址,判斷哪一臺(tái)服務(wù)器距用戶(hù)最近;
用戶(hù)所處的運(yùn)營(yíng)商;
根據(jù)用戶(hù)所請(qǐng)求的 URL 中攜帶的內(nèi)容名詞,判斷哪一臺(tái)服務(wù)器上有用戶(hù)所需的內(nèi)容;
查詢(xún)各個(gè)服務(wù)器當(dāng)前的負(fù)載情況,判斷哪一臺(tái)服務(wù)器尚有服務(wù)能力。
????基于以上這些條件,進(jìn)行綜合分析之后,全局負(fù)載均衡器會(huì)返回一臺(tái)緩存服務(wù)器的 IP 地址。
????本地 DNS 服務(wù)器緩存這個(gè) IP 地址,然后將 IP 返回給客戶(hù)端,客戶(hù)端去訪(fǎng)問(wèn)這個(gè)邊緣節(jié)點(diǎn),下載資源。
????緩存服務(wù)器響應(yīng)用戶(hù)請(qǐng)求,將用戶(hù)所需內(nèi)容傳送給用戶(hù)。如果這臺(tái)緩存服務(wù)器上沒(méi)有用戶(hù)想要的內(nèi)容,那么這臺(tái)服務(wù)器就要向它的上一級(jí)緩存服務(wù)器請(qǐng)求內(nèi)容,直至追溯到網(wǎng)站的源服務(wù)器,將內(nèi)容拉到本地。
CDN 緩存內(nèi)容????保質(zhì)期長(zhǎng)的日用品因?yàn)椴蝗菀走^(guò)期,因此比較容易緩存。同樣的,互聯(lián)網(wǎng)中的靜態(tài)頁(yè)面、圖片等,幾乎不怎么改變,所以也適合緩存。而像生鮮之類(lèi)的保存時(shí)間較短的,對(duì)應(yīng)互聯(lián)網(wǎng)中的動(dòng)態(tài)資源,就需要用到動(dòng)態(tài) CDN 。
靜態(tài)資源緩存????還記得上圖這個(gè)接入層緩存的架構(gòu)嗎?在進(jìn)入數(shù)據(jù)中心的時(shí)候,我們希望通過(guò)最外層接入層的緩存,將大部分靜態(tài)資源的訪(fǎng)問(wèn)攔在邊緣。而 CDN 則更進(jìn)一步,將這些靜態(tài)資源緩存到離用戶(hù)更近的數(shù)據(jù)中心外??傮w來(lái)說(shuō),就是縮短用戶(hù)的“訪(fǎng)問(wèn)距離”。離客戶(hù)越近,客戶(hù)訪(fǎng)問(wèn)性能越好,時(shí)延越低。
????在靜態(tài)內(nèi)容中,流媒體也大量使用了 CDN。
????CDN 支持流媒體協(xié)議。例如前面講過(guò)的 RTMP 協(xié)議。在很多情況下,這相當(dāng)于一個(gè)代理,從上一級(jí)緩存讀取內(nèi)容,轉(zhuǎn)發(fā)給用戶(hù)。由于流媒體往往是連續(xù)的,因而可以進(jìn)行預(yù)先緩存的策略,也可以預(yù)先推送到用戶(hù)的客戶(hù)端。
????對(duì)于靜態(tài)頁(yè)面來(lái)講,內(nèi)容的分發(fā)往往采取拉取的方式。也即,當(dāng)發(fā)現(xiàn)緩存未命中的是,再去上一級(jí)進(jìn)行拉取。
????這個(gè)方式對(duì)于流媒體就不合適了。流媒體數(shù)據(jù)量大,如果出現(xiàn)回源,壓力會(huì)比較大,所以往往采取主動(dòng)推送的模式,將熱點(diǎn)數(shù)據(jù)主動(dòng)推送到邊緣節(jié)點(diǎn)。
????對(duì)于流媒體來(lái)講,很多 CDN 還提供預(yù)處理服務(wù)。也就是在文件分發(fā)之前,進(jìn)行一定的處理。例如將視頻轉(zhuǎn)換成不同的碼流,以適應(yīng)不同的網(wǎng)絡(luò)帶寬的用戶(hù)需求。再如對(duì)視頻進(jìn)行分片,降低存儲(chǔ)壓力,也使得客戶(hù)端可以選擇使用不同的碼率加載不同的分片。這就是我們常見(jiàn)的,超清、標(biāo)清、流暢等。
????除此之外,流媒體 CDN 還有個(gè)關(guān)鍵的防盜鏈問(wèn)題。因?yàn)橐曨l要花大價(jià)錢(qián)買(mǎi)版權(quán),如果流媒體被其他網(wǎng)站盜走,在其他網(wǎng)站的播放,那損失就大了。
????對(duì)于防盜鏈問(wèn)題,最常用也最簡(jiǎn)單的方法就是利用 HTTP 頭的 refer 字段。當(dāng)瀏覽器發(fā)送請(qǐng)求的時(shí)候,一般會(huì)帶上 refer。告訴服務(wù)器是從哪個(gè)頁(yè)面鏈接過(guò)來(lái)的,服務(wù)器基于此可以獲得一些信息用于處理。如果 refer 信息不是來(lái)自本站,就阻止訪(fǎng)問(wèn)或者跳到其它鏈接。
????refer 的機(jī)制相對(duì)比較容易破解,所以還需要其它的機(jī)制配合。
????一種常用的機(jī)制是時(shí)間戳防盜鏈。使用 CDN 的管理員可以在配置界面上,和 CDN 廠(chǎng)商約定一個(gè)加密字符串。
????客戶(hù)端訪(fǎng)問(wèn)時(shí),取出當(dāng)前的時(shí)間戳、要訪(fǎng)問(wèn)的資源極其路徑,聯(lián)通加密字符串進(jìn)行前面算法得到一個(gè)字符串,然后生成一個(gè)下載鏈接,帶上這個(gè)前面字符串和截止時(shí)間戳去訪(fǎng)問(wèn) CDN。
????在服務(wù)端,取出過(guò)期時(shí)間,和當(dāng)前 CDN 節(jié)點(diǎn)時(shí)間進(jìn)行比較,確認(rèn)請(qǐng)求是否過(guò)期。然后 CDN 服務(wù)端根據(jù)請(qǐng)求的資源及路徑、時(shí)間戳、和約定的加密字符串進(jìn)行簽名。只有簽名和客戶(hù)端發(fā)送的一致,才會(huì)將資源返回給客戶(hù)。
動(dòng)態(tài)資源緩存????對(duì)于動(dòng)態(tài)資源,用到動(dòng)態(tài) CDN。動(dòng)態(tài) CDN 主要有兩種模式:
1)“生鮮超市模式”,也就是邊緣計(jì)算模式。
????既然數(shù)據(jù)是動(dòng)態(tài)生成的,所以數(shù)據(jù)的邏輯計(jì)算和存儲(chǔ),也相應(yīng)的放在邊緣的節(jié)點(diǎn)。其中定時(shí)從源數(shù)據(jù)那里同步存儲(chǔ)的數(shù)據(jù),然后在邊緣節(jié)點(diǎn)進(jìn)行計(jì)算得到結(jié)果。
????這種方式很像現(xiàn)在的生鮮超市。新鮮的海鮮大餐是動(dòng)態(tài)的,很難事先做好緩存,因而將生鮮超市放在你家旁邊,既能夠送貨上門(mén),也能夠現(xiàn)場(chǎng)烹飪。這就是邊緣計(jì)算的一種體現(xiàn)。
2)“冷鏈運(yùn)輸模式”,也就是路徑優(yōu)化模式。數(shù)據(jù)不是在邊緣計(jì)算生成的,而是在源站生成的,但是數(shù)據(jù)的下發(fā)則可以通過(guò) CDN 的網(wǎng)絡(luò),對(duì)路徑進(jìn)行優(yōu)化。
????因?yàn)?CDN 節(jié)點(diǎn)較多,能夠找到離源站很近的邊緣節(jié)點(diǎn),也能找到離用戶(hù)很近的邊緣節(jié)點(diǎn)。中間的鏈路完全由 CDN 來(lái)規(guī)劃,選擇一個(gè)更加可靠的路徑,使用類(lèi)似專(zhuān)線(xiàn)的方式進(jìn)行訪(fǎng)問(wèn)。
????除此之外,這些資源進(jìn)行傳輸?shù)臅r(shí)候,由于 TCP 的流量控制和擁塞控制,可以在 CDN 加速網(wǎng)絡(luò)中調(diào)整 TCP 的參數(shù),使得 TC 可以更加激進(jìn)的傳輸數(shù)據(jù)。
????所有這些手段就像冷鏈傳輸,優(yōu)化整個(gè)物流運(yùn)輸,全程冷凍高速運(yùn)輸。不管是生鮮從你家旁邊超市送過(guò)去,還是從產(chǎn)地運(yùn)送,保證到你家是新鮮的。
小結(jié)CDN 和電商系統(tǒng)的分布式倉(cāng)儲(chǔ)系統(tǒng)一樣,分為中心節(jié)點(diǎn)、區(qū)域節(jié)點(diǎn)、邊緣節(jié)點(diǎn),從而將數(shù)據(jù)緩存在離用戶(hù)最近的位置。
CDN 最擅長(zhǎng)的緩存是緩存靜態(tài)數(shù)據(jù)。除此之外還可以緩存流媒體數(shù)據(jù)。這時(shí)候要注意防盜鏈問(wèn)題。它也支持動(dòng)態(tài)數(shù)據(jù)的緩存,一種是邊緣計(jì)算,另一種是鏈路優(yōu)化。
參考:
What is a CDN?;
[維基百科 - Content delivery network
](https://en.wikipedia.org/wiki...;
劉超 - 趣談網(wǎng)絡(luò)協(xié)議系列課;
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/29885.html
摘要:支持流媒體協(xié)議。流媒體數(shù)據(jù)量大,如果出現(xiàn)回源,壓力會(huì)比較大,所以往往采取主動(dòng)推送的模式,將熱點(diǎn)數(shù)據(jù)主動(dòng)推送到邊緣節(jié)點(diǎn)。除此之外,流媒體還有個(gè)關(guān)鍵的防盜鏈問(wèn)題。在服務(wù)端,取出過(guò)期時(shí)間,和當(dāng)前節(jié)點(diǎn)時(shí)間進(jìn)行比較,確認(rèn)請(qǐng)求是否過(guò)期。 【前五篇】系列文章傳送門(mén): 網(wǎng)絡(luò)協(xié)議 13 - HTTPS 協(xié)議:加密路上無(wú)盡頭 網(wǎng)絡(luò)協(xié)議 14 - 流媒體協(xié)議:要說(shuō)愛(ài)你不容易 網(wǎng)絡(luò)協(xié)議 15 - P2P 協(xié)...
摘要:傳輸協(xié)議問(wèn)題我們先解決第一個(gè),傳輸協(xié)議的問(wèn)題。信封里面的信分抬頭和正文板栗燜雞協(xié)議我們學(xué)過(guò),這個(gè)請(qǐng)求使用方法,發(fā)送一個(gè)格式為的正文給,從而下一個(gè)單,這個(gè)訂單封裝在的信封里面,并且表明這是一筆交易,而且訂單的詳情都已經(jīng)寫(xiě)明了。 【前五篇】系列文章傳送門(mén): 網(wǎng)絡(luò)協(xié)議 15 - P2P 協(xié)議:小種子大學(xué)問(wèn) 網(wǎng)絡(luò)協(xié)議 16 - DNS 協(xié)議:網(wǎng)絡(luò)世界的地址簿 網(wǎng)絡(luò)協(xié)議 17 - HTTPDN...
摘要:傳輸協(xié)議問(wèn)題我們先解決第一個(gè),傳輸協(xié)議的問(wèn)題。信封里面的信分抬頭和正文板栗燜雞協(xié)議我們學(xué)過(guò),這個(gè)請(qǐng)求使用方法,發(fā)送一個(gè)格式為的正文給,從而下一個(gè)單,這個(gè)訂單封裝在的信封里面,并且表明這是一筆交易,而且訂單的詳情都已經(jīng)寫(xiě)明了。 【前五篇】系列文章傳送門(mén): 網(wǎng)絡(luò)協(xié)議 15 - P2P 協(xié)議:小種子大學(xué)問(wèn) 網(wǎng)絡(luò)協(xié)議 16 - DNS 協(xié)議:網(wǎng)絡(luò)世界的地址簿 網(wǎng)絡(luò)協(xié)議 17 - HTTPDN...
閱讀 1766·2023-04-25 20:16
閱讀 4035·2021-10-09 09:54
閱讀 2784·2021-09-04 16:40
閱讀 2575·2019-08-30 15:55
閱讀 890·2019-08-29 12:37
閱讀 2797·2019-08-26 13:55
閱讀 2960·2019-08-26 11:42
閱讀 3221·2019-08-23 18:26