開(kāi)頭

這篇文章通過(guò) FCC 上海線下和成都微信的分享，整理成文字稿順便湊一下更新，考慮到吃瓜讀者們不知道都了解到啥程度，以及我科普作者的身份（自己定的），我決定從入門(mén)到放棄的介紹一下，大致涉及：

• 什么是 CDN
• 為什么我們要用 CDN
• 訪問(wèn)原理
• 架構(gòu)
• 應(yīng)用與踩坑
• 現(xiàn)實(shí)世界的 CDN

由于每個(gè)地方都事無(wú)巨細(xì)講起來(lái)非常費(fèi)勁，費(fèi)勁就容易跳票，而且會(huì)導(dǎo)致篇幅過(guò)長(zhǎng)，所以其實(shí)都是科普向的，如果想要深入，在每個(gè)地方都會(huì)給出鏈接，可以進(jìn)行針對(duì)性的深入閱讀。

如果有說(shuō)的不對(duì)的地方請(qǐng)各位大佬指摘，粗體部分為超鏈接。

什么是 CDN

從一個(gè)簡(jiǎn)單的栗子說(shuō)起：

「非洲農(nóng)業(yè)不發(fā)達(dá)，人人都要金坷垃」——相信大家基本上都看過(guò)來(lái)自美國(guó)圣地亞哥的視頻，美國(guó)人、非洲人和日本人在一起搶來(lái)?yè)屓ァＨ绻鹂览辉谝粋€(gè)地方生產(chǎn)，那么非洲的運(yùn)輸成本和生產(chǎn)者的產(chǎn)能壓力都很大。

那么很簡(jiǎn)單，我們?cè)谑澜绲拿總€(gè)需要金坷垃的國(guó)家都開(kāi)代工廠，都生產(chǎn)金坷垃——我們的 CDN 就是生產(chǎn)金坷垃的公司，而一個(gè)個(gè)「節(jié)點(diǎn)」就是代工廠。

CDN，中文名叫做「內(nèi)容分發(fā)網(wǎng)絡(luò)」，它的作用是減少傳播時(shí)延，找最近的節(jié)點(diǎn)，實(shí)際上，盡管互聯(lián)網(wǎng)幫助我們實(shí)現(xiàn)了地球村，但是從中國(guó)到日本和從中國(guó)大陸到中國(guó)臺(tái)灣省的時(shí)延仍舊是不一樣的，這一點(diǎn)可以從 ping 和 traceroute 中看出。

CDN 的優(yōu)點(diǎn)

訪問(wèn)加速

CDN 作為前端性能經(jīng)典手段，相信大家已經(jīng)無(wú)腦使用了，正如前面所說(shuō)的，減少了時(shí)延，從很大程度上就能作為加速手段了。實(shí)際上，真正的 CDN 并不是前面舉例的一個(gè)國(guó)家一個(gè)節(jié)點(diǎn)，甚至是一個(gè)運(yùn)營(yíng)商，一個(gè)省份乃至地區(qū)都會(huì)有節(jié)點(diǎn)。



減輕源站（服務(wù)器）負(fù)載

一個(gè)非常簡(jiǎn)單就能想明白的問(wèn)題，如果 CDN 已經(jīng)能幫我返回?cái)?shù)據(jù)了，那么請(qǐng)求就不會(huì)到達(dá)源站，源站（服務(wù)器）的負(fù)載就減輕了。

抗住攻擊

既然源站的負(fù)載被減輕了，那么在受到 DDOS 攻擊的時(shí)候，也能談笑風(fēng)生。

當(dāng)年阮老師被 DDOS 鬧的滿城風(fēng)雨，后來(lái)阮老師就把內(nèi)容開(kāi)始遷移到 GayHub……

然后本來(lái)我不用更新內(nèi)容，就在最近，阮老師發(fā)布了一篇 DDOS 防御指南，然后接著被攻擊，又癱瘓了，防御指南中說(shuō)自己受到了 CC，然后遷移到了騰訊云，啪啪啪打了我的臉……當(dāng)然，其實(shí) CC 并沒(méi)有那么難防御，但是不在分享主題內(nèi)容中，感興趣的可以之后聊……

受到阮老師啟發(fā)，于是我糊了一個(gè)架構(gòu)圖，一個(gè)博客系統(tǒng)的思路圖，基本上和市面上的 Jekyll 和 Hexo 一樣，當(dāng)時(shí)我的設(shè)想是，把評(píng)論之類的全部抽出來(lái)，這樣打的時(shí)候最多打掛評(píng)論之類的，對(duì)于博文本身不會(huì)有任何影響。后來(lái)我回去查了一下，發(fā)現(xiàn)這不就和市面上的一樣嘛——不錯(cuò)！

那么既然靜態(tài)資源能上 CDN，我們的 API，我們的 MVC 頁(yè)面能不能也上 CDN？答案是可以的，關(guān)鍵就是這個(gè)叫全站加速的東西。

啥玩樣兒？其實(shí) CDN 就是一個(gè)緩存，區(qū)別只是這個(gè)緩存是放在網(wǎng)絡(luò)服務(wù)提供商節(jié)點(diǎn)的。

最簡(jiǎn)單的模型像這張圖，這張圖來(lái)自《大型網(wǎng)站技術(shù)架構(gòu) 核心原理與案例分析》一書(shū)。

訪問(wèn)原理

從我們發(fā)起請(qǐng)求，到到達(dá) CDN 節(jié)點(diǎn)，到底經(jīng)過(guò)了哪些東西，CDN 是怎么加速我們的請(qǐng)求的呢？



這張圖也是網(wǎng)上找來(lái)的。

首先我們?cè)诘刂窓阪I入一個(gè)網(wǎng)址，瀏覽器發(fā)現(xiàn)本地沒(méi)有關(guān)于這個(gè)網(wǎng)址的 DNS 緩存，所以向網(wǎng)站的 DNS 服務(wù)器發(fā)起請(qǐng)求。

網(wǎng)站的 DNS 服務(wù)器設(shè)置了 CNAME，指向了某個(gè) CDN 服務(wù)器，也就是我們常見(jiàn)的阿里云、騰訊云、Cloudflare 之類的，去請(qǐng)求 CDN 中的智能 DNS 均衡負(fù)載系統(tǒng)。

均衡負(fù)載系統(tǒng)解析域名，把對(duì)用戶響應(yīng)最快的節(jié)點(diǎn)返回給用戶，然后用戶向該節(jié)點(diǎn)發(fā)出請(qǐng)求。

如果是第一次訪問(wèn)該內(nèi)容，CDN 服務(wù)器會(huì)向源站請(qǐng)求數(shù)據(jù)并緩存，否則的話，直接在緩存節(jié)點(diǎn)中找到該數(shù)據(jù)，將請(qǐng)求結(jié)果發(fā)給用戶。

對(duì)于最簡(jiǎn)單的 CDN 系統(tǒng)而言，只要一臺(tái) DNS 調(diào)度服務(wù)器和一個(gè)節(jié)點(diǎn)服務(wù)器即可，但在復(fù)雜的應(yīng)用中，會(huì)存在多級(jí)緩存，多臺(tái) Cache 來(lái)協(xié)同工作。

這里我之前在博客里寫(xiě)過(guò)類似的內(nèi)容（實(shí)際上就是摘抄的）

架設(shè)原理

如果你要架設(shè)一個(gè) CDN，大概需要怎么做？記住我們剛才介紹的內(nèi)容，重點(diǎn)是，CDN 仍然是一個(gè)緩存。



拿來(lái)阿里云 CDN 的架構(gòu)圖口胡一下，我也沒(méi)有搭建過(guò)，如果解釋的不對(duì)請(qǐng)大家指出。

既然是緩存，那么很明顯，也就是均衡負(fù)載加上緩存調(diào)度的搭配，根據(jù)我們剛才所說(shuō)的訪問(wèn)原理，其實(shí)主要的重點(diǎn)除了均衡負(fù)載與緩存外，就是一個(gè)中央的 DNS 調(diào)度器。

實(shí)際上，和計(jì)算機(jī)的多級(jí)緩存設(shè)計(jì)以及后端的多級(jí)緩存設(shè)計(jì)一樣，每一層的 cache 一級(jí)比一級(jí)大，可以存儲(chǔ)更多資源，但是響應(yīng)一個(gè)比一個(gè)耗時(shí)，如果在 L1 中無(wú)法命中，那么我們就會(huì)去 L2 找，L2 無(wú)法命中才會(huì)回到源站，這樣可以有效的避免回到源站過(guò)于頻繁的問(wèn)題。



接下來(lái)這張圖，我就有點(diǎn)編不下去了，在阿里，主要使用 LVS + Tengine 做負(fù)載均衡，然后用 Swift 做 HTTP 緩存。這是他們自己說(shuō)的，但是和我沒(méi)什么關(guān)系，我主要講的是左邊那個(gè)花括號(hào)的一致性 Hash。

一致性 Hash 就是把對(duì)象映射在 232 個(gè)桶空間里，像一個(gè)閉合的圓環(huán)，當(dāng)然，實(shí)際上，我們將機(jī)器也映射到這個(gè)圓環(huán)中，比如利用別名或者 IP，順時(shí)針將對(duì)象將內(nèi)容存儲(chǔ)到離自己最近的機(jī)器中，刪除和添加節(jié)點(diǎn)也一樣，添加和刪除節(jié)點(diǎn)之后，根據(jù)順時(shí)針遷移，原來(lái)的對(duì)象會(huì)進(jìn)行重新計(jì)算。

關(guān)于這點(diǎn)需要詳細(xì)了解可以看這篇：https://blog.csdn.net/cywosp/article/details/23397179



然后說(shuō)完這個(gè)關(guān)鍵性算法，我們就差不多消化了——隔壁阿里云 CDN 是怎么搞出來(lái)的。

當(dāng)然這依舊和我們沒(méi)啥關(guān)系……

應(yīng)用與踩坑

最常見(jiàn)的應(yīng)用，就是用于前端靜態(tài)資源的加速，實(shí)際上，利用 CDN，我們甚至可以做出一套屬于自己的 jsDelivr。

不過(guò)，使用 CDN 的時(shí)候，有一些基本法需要我們了解。

緩存設(shè)置

第一，緩存的設(shè)置，max-age 我們都用過(guò)，在 Cache-Control 中經(jīng)常用于緩存的控制，可是 max-age 設(shè)置的緩存會(huì)應(yīng)用于一個(gè)請(qǐng)求經(jīng)過(guò)的每一級(jí)，如果我們希望 CDN 不緩存那么久，要怎么辦呢？那就是 s-maxage，它用于設(shè)置代理服務(wù)器的緩存時(shí)間，會(huì)覆蓋 max-age 的設(shè)置，這樣我們可以把 max-age 用于本地緩存，把 s-maxage 用于 CDN 緩存時(shí)間，避免臟數(shù)據(jù)的產(chǎn)生。

緩存命中率

對(duì)于一個(gè)緩存而言，還有一點(diǎn)很重要，就是你的緩存到底有沒(méi)有用，衡量這個(gè)東西的就是緩存命中率。如果只是靜態(tài)資源，在刷新緩存之后，可能會(huì)導(dǎo)致命中率下降，因此 CDN 的資源不適合經(jīng)常刷新，換句話說(shuō)，如果一個(gè)請(qǐng)求結(jié)果會(huì)經(jīng)常進(jìn)行變更，那么 CDN 基本就沒(méi)什么存在的意義。

判斷是否命中緩存

無(wú)論是我們自己在開(kāi)發(fā)過(guò)程中，還是幫客戶 debug 的過(guò)程中，我們都會(huì)考慮一件事——這個(gè)資源是否命中了CDN，是否是因?yàn)镃DN導(dǎo)致的問(wèn)題，這個(gè)時(shí)候就要秀一波操作了。



在各大廠商的 CDN 返回的數(shù)據(jù)中都會(huì)有一個(gè) X-Cache，上面內(nèi)容是 Hit 或者 Miss，還會(huì)加上諸如 Memory 或者 Disk 的縮寫(xiě)表示內(nèi)存還是磁盤(pán)，如果出現(xiàn) Upstream 或者 Miss 則表示沒(méi)有命中。

資源預(yù)熱

緩存設(shè)計(jì)中，預(yù)熱是很重要的環(huán)節(jié)，在最初剛開(kāi)始啟動(dòng) CDN 的時(shí)候，CDN 上并沒(méi)有緩存數(shù)據(jù)，此刻大量的請(qǐng)求全部打向源站，肯定會(huì)把源站打掛，預(yù)熱就是實(shí)現(xiàn)緩存好熱門(mén)數(shù)據(jù)，這樣在業(yè)務(wù)上線時(shí)，CDN 上已經(jīng)有所需的數(shù)據(jù)了。

Vary

此外很多 CDN 都不支持 Vary 頭，這樣 CORS 需要的 Vary: Origin 就沒(méi)法保證了，遇到這種情況，比如你發(fā)現(xiàn) Origin 頭被緩存了，就只能把跨域頭改為 * 去匹配。

Range

另外如果是很大的文件，往往是用 RANGE 頭分片載入的，但如果 CDN 沒(méi)有進(jìn)行分片，就會(huì)重復(fù)向源站請(qǐng)求完整資源，CDN 就白搞了，啟用 RANGE 回源，就可以減少流量的損耗，正確的設(shè)置 RANGE 回源，就能夠正確的命中 CDN 緩存。

無(wú)私鑰 HTTPS

另外重點(diǎn)說(shuō)一下：這年頭上 HTTPS 已經(jīng)是常規(guī)基本法了，而不上 HTTPS 才是個(gè)噴點(diǎn)，CDN 為了避免篡改和劫持，當(dāng)然也得上 HTTPS，但這樣就導(dǎo)致我們必須要將證書(shū)和私鑰傳輸?shù)?CDN 的平臺(tái)中去，對(duì)于安全性是一個(gè)隱患。

所以就有了無(wú)私鑰解決方案，用戶搭建私鑰服務(wù)器，由 CDN 方去請(qǐng)求簽名。圖為阿里云的實(shí)現(xiàn)，只要在自己的服務(wù)器上部署 KeyServer 和配置就可以用了。



這里我在上海 FCC 分享的時(shí)候有同學(xué)想要具體了解一下，具體來(lái)說(shuō)的話涉及到很多 HTTPS 加密的事情，暫時(shí)不做展開(kāi)，可以看一下 CloudFlare 發(fā)的一篇文章，我正好找到了翻譯版：https://www.zcfy.cc/article/keyless-ssl-the-nitty-gritty-technical-details-967.html

現(xiàn)實(shí)世界的 CDN

比如，節(jié)點(diǎn)掛了，直接導(dǎo)致的是用戶的損失，尤其是體量大的公司依賴 CDN 進(jìn)行靜態(tài)資源管理的時(shí)候，發(fā)生這樣的事情后果會(huì)非常嚴(yán)重。

其次，便宜沒(méi)好貨：本來(lái)在只有網(wǎng)宿而沒(méi)有阿里云的時(shí)代，CDN 是很昂貴的，阿里騰訊在拉低 CDN 價(jià)格的同時(shí)，也拉低了 CDN 的質(zhì)量，部分節(jié)點(diǎn)的訪問(wèn)質(zhì)量不太高會(huì)導(dǎo)致有些用戶訪問(wèn)的網(wǎng)絡(luò)質(zhì)量非常差。

然后，一個(gè)微小的科普：什么是混合 CDN——混合 CDN 這個(gè)名詞看著很高端，實(shí)際上就是，我們用了多家廠商的 CDN，可能也包括自己建的，然后誰(shuí)好的選誰(shuí)，但是有的時(shí)候反而會(huì)造成服務(wù)不可控，進(jìn)一步劣化 CDN 的質(zhì)量。

總結(jié)

CDN 這個(gè)東西本質(zhì)就是一個(gè)緩存，只是這個(gè)緩存離你特別特別的近，作為用戶還是開(kāi)發(fā)都能從中享受到一點(diǎn)福利，但作為一個(gè)服務(wù)于企業(yè)的開(kāi)發(fā)人員，不僅要考慮 CDN 的優(yōu)點(diǎn)，也要知道 CDN 給我們帶來(lái)的坑，這樣才能靠譜的作為 CDN 的使用者。

總結(jié)

以上是生活随笔為你收集整理的cdn刷新api_闲话 CDN的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。