科普什么是CDN

開(kāi)頭

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

• 什么是 cdn/' target='_blank'>CDN
• 為什么我們要用 CDN
• 訪(fǎng)問(wèn)原理
• 架構
• 應用與踩坑
• 現實(shí)世界的 CDN

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

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

什么是 CDN

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

「非洲農業(yè)不發(fā)達，人人都要金坷垃」——相信大家基本上都看過(guò)來(lái)自美國圣地亞哥的視頻，美國人、非洲人和日本人在一起搶來(lái)?yè)屓?。如果金坷垃只在一個(gè)地方生產(chǎn)，那么非洲的運輸成本和生產(chǎn)者的產(chǎn)能壓力都很大。

那么很簡(jiǎn)單，我們在世界的每個(gè)需要金坷垃的國家都開(kāi)代工廠(chǎng)，都生產(chǎn)金坷垃——我們的 CDN 就是生產(chǎn)金坷垃的公司，而一個(gè)個(gè)「節點(diǎn)」就是代工廠(chǎng)。

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

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

訪(fǎng)問(wèn)加速

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

?

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

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

抗住攻擊

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

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

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

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

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

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

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

訪(fǎng)問(wèn)原理

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

?

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

首先我們在地址欄鍵入一個(gè)網(wǎng)址，瀏覽器發(fā)現本地沒(méi)有關(guān)于這個(gè)網(wǎng)址的 DNS 緩存，所以向網(wǎng)站的 DNS 服務(wù)器發(fā)起請求。

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

均衡負載系統解析域名，把對用戶(hù)響應最快的節點(diǎn)返回給用戶(hù)，然后用戶(hù)向該節點(diǎn)發(fā)出請求。

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

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

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

架設原理

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

?

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

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

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

?

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

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

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

?

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

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

應用與踩坑

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

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

緩存設置

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

緩存命中率

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

判斷是否命中緩存

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

?

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

資源預熱

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

Vary

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

Range

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

無(wú)私鑰 HTTPS

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

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

?

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

現實(shí)世界的 CDN

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

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

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

總結

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

源于知呼文章：https://zhuanlan.zhihu.com/p/39028766

作者：敖天羽

發(fā)布者：水橋丶帕露西