如你所見, 我也喜歡頁面能快速加載, 越快越好. 但在我們開始討論之前, 先要有一個清楚的認知: CDN 并不是萬能的. 如果因為糟糕的前端工作導致你的網(wǎng)站變慢, CDN 并不能幫到你太多, 你需要先做好前端工作. 但一旦你已經(jīng)做好了所有的優(yōu)化, 就需要來研究一下內(nèi)容傳輸這塊了.

我碰到的主要問題是即使能通過一次 HTTP 請求來完成初始網(wǎng)站的加載, 但因為我的服務器托管在法蘭克福, 在澳大利亞的人仍需要等待 2-3 秒后才能訪問到它. 超過 300ms 的往返延時和中間大量的服務提供商使得頁面加載就跟 WordPress 網(wǎng)站一樣慢.

那如何解決這個問題呢? 一種解決方案是使用傳統(tǒng)的 CDN. 然而大多數(shù)商業(yè) CDN 在從服務器請求到數(shù)據(jù)之后, 都會緩存一段時間.

由于 CDN 的存在, 在內(nèi)容獲取上稍微繞行了一下, 導致在使用傳統(tǒng) CDN 之后, 初始頁面的加載反而變慢了. 如果你的網(wǎng)站流量高, 內(nèi)容一直緩存著, 這沒什么大問題. 但反過來說, 如果和我一樣僅僅是運行一個小博客, 內(nèi)容并不會常駐緩存,傳統(tǒng)的 pull-CDN 反而會讓網(wǎng)站變得更慢. 當然, 我也可以通過 push-CDN 直接上傳內(nèi)容, 但跟我要搭建的 CDN 相比, 這種成本要昂貴許多.

CDN 是如何工作的?

我們的方案很明確: 為了擴大世界影響力, 我們應該保證內(nèi)容在任何位置都能被快速訪問. 這意味著內(nèi)容所在位置應該盡量靠近訪問者. 方便的是, 很多云服務商在多個地區(qū)都提供了廉價的虛擬服務器. 我們是否僅需要把內(nèi)容放到比如 6 臺服務器上, 就萬事大吉了呢?

好吧, 沒那么快. 那如何把用戶路由到正確的服務器上呢? 我們看一下實際訪問網(wǎng)站的過程. 首先, 瀏覽器通過 DNS 查詢網(wǎng)站的 IP 地址, 獲取到 IP 之后, 就可以連接網(wǎng)站并下載請求的頁面.

上層的解決方案其實很簡單: 需要一臺智能 DNS 服務器, 對請求的 IP 做 GeoIP 查詢并返回離它最近的 IP 地址. 事實上, 幾乎所有的商業(yè) CDN 都是這么做的. 雖然還牽扯到許多工程學領(lǐng)域的內(nèi)容, 比如延遲測量等, 但基本原理還是這個.

讓 DNS 服務器快起來

接下來新的問題出現(xiàn)了: 如何讓 DNS 服務器快起來? 從最近節(jié)點上訪問網(wǎng)站僅僅解決了一半問題, 如果 DNS 查找不得不繞行地球一周, 還是會有極大的延遲.

事實證明, 支撐互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施非常適合解決這個問題. 網(wǎng)絡(luò)提供商使用邊界網(wǎng)關(guān)協(xié)議來相互告知可連接的網(wǎng)絡(luò)和躍點的多少. 多數(shù)情況下, 最終互聯(lián)網(wǎng)提供商會采用最短路線來到達目標地址.

如果在多個位置使用一個 IP 地址, DNS 總是會路由到最近的節(jié)點, 這就是 BGP Anycast.

為何網(wǎng)站下載不使用 BGP Anycast?

如果能做到, 我們?yōu)楹尾缓唵问褂?BGP 來路由網(wǎng)絡(luò)流量呢? 主要有三個原因.

首先, 使用 BGP Anycast 需要在網(wǎng)絡(luò)硬件上做控制, 并且需要一個至少包含 256 個 IP 地址的池子, 這超出了我們的預算.

其次, BGP 路由并不那么穩(wěn)定. 不同于 DNS 請求僅僅只需要向兩個方向發(fā)送單個數(shù)據(jù)包, HTTP web 請求需要創(chuàng)建一個連接來下載內(nèi)容. 期間如果路由改變或者連接不穩(wěn)定, HTTP 連接就會斷開. 對這種規(guī)模的工程來說反而增加了很多復雜性.

最后, 躍點作為 BGP 路由計算基礎(chǔ), 它數(shù)目的減小并不能保證往返延遲的減小. 一個跨大洋的躍點可能僅僅是一個躍點, 但卻是時間最長的一個.

創(chuàng)建 DNS

既然已經(jīng)確認不能運行我們自己的 BGP Anycast, 也意味著同樣不能運行我們自己的 DNS 服務器. 讓我們?nèi)フ艺沂召M的!… 事實證明, 同時提供 BGP Anycast 和延遲路由的 DNS 提供商很難找到. 我只搜索到了 2 個: 相當昂貴的 Dyn 和非常便宜的 Amazon Route53.(更新: 后來發(fā)現(xiàn), DNS Made Easy 也能實現(xiàn)延遲路由) 既然想合算, 就選 Route53 了. 添加域名之后開始為機器設(shè)置 IP. 我們需要設(shè)置跟我們遍布世界各地的 (邊緣節(jié)點) 服務器同樣多的 DNS 記錄, 每條記錄設(shè)置如下:

提示: 最好對每個邊緣節(jié)點都創(chuàng)建一個健康檢查以便在他們失效后進行移除.

分發(fā)內(nèi)容

我們需要解決的下一個問題是分發(fā)內(nèi)容. 每個邊緣節(jié)點都需要有相同的內(nèi)容. 如果你使用的是 Jekyll 這樣的靜態(tài)網(wǎng)站生成器, 工作很簡單: 只需要將生成的 HTML 文件復制到所有的服務器上即可. 一個簡單的 rsync 就能搞定.

如果想使用 WordPress 這樣的內(nèi)容編輯系統(tǒng), 工作會困難的多, 因為它并不能在 CDN 上運行. 當然也可以做, 但免不了有缺陷, 靜態(tài)內(nèi)容的分發(fā)仍然是一個問題. 你可能必須要創(chuàng)建一個分布式存儲才能正常工作.

使用 SSL/TLS 證書

下一個痛點是使用 SSL/TLS 證書. 實際上, 可以統(tǒng)稱他們?yōu)? x509 證書. 每個邊緣節(jié)點都需要為域名設(shè)置有效的證書. 當然, 最簡單的解決方案是使用 LetsEncrypt 來生成不同的證書. 但要注意, 我在其中一個邊緣節(jié)點上碰上了 LE 有效期的問題, 導致在每周限額到期之前我不得不暫時把倫敦節(jié)點下掉.

我使用 Traefik 作為我的選擇代理, 它支持分布式鍵值存儲, 甚至支持 Apache Zookeeper 后端同步. 雖然這需要一些程序設(shè)計, 可從長遠來看會更穩(wěn)定一些.

結(jié)果

是時候檢驗一下結(jié)果了, 我的 CDN 表現(xiàn)如何呢? 使用這個工具, 看一下總體數(shù)據(jù):

如你所見, 相當不錯的結(jié)果. 我可能還需要在亞洲和南美加兩個節(jié)點來優(yōu)化加載時間.

更新: 在把它提交到 Hacker News 首頁之后, 我可以使用 Google Analytics 來收集一些實際使用數(shù)據(jù):

結(jié)論: 我確實需要一個新加坡節(jié)點. 在印度的加載時間超過了預期的 1 秒.

常見問題

我在做這項工作的時候, 人們經(jīng)常問我:” 你為什么要做這個呢? 你這是自尋煩惱啊 “. 確實, 在某種程度上, 我喜歡做不同的事情來探索新方向和新技術(shù), 建立自己的 CDN 可能具有很大的意義. 讓我們來談談關(guān)于設(shè)置的一些問題.

首先申明: 如果商業(yè)提供商能推出價格合理的 push CDN, 讓我能處理 nice URLs, SSL 和自定義頭信息, 我絕對樂意花錢解決問題并停掉我自己的基礎(chǔ)設(shè)施. 搭建它很有趣, 但我還有很多服務器沒有運行它.

為何不用 CloudFlare?

對很多人來說 CloudFlare 是一個很棒的工具, 但如上所述, CDN 會從緩存中移除未使用的內(nèi)容. 我管理的其他網(wǎng)站, 在正確配置的情況下緩存命中率大概能達到 75%. 擁有自己的 CDN 則意味著內(nèi)容會常駐緩存, 不會有訪問遠程服務器而導致的往返延時.

為何不用 S3 或 CloudFront?

Amazon S3 有托管靜態(tài)網(wǎng)站的選項, 并且可以與 CloudFront 結(jié)合著使用. 然而, 它不允許你自定義緩存頭信息, 設(shè)置 nice URLs 等. 為此, 你需要使用 Lambda@Edge, 這是一個可以讓你在 CloudFront 邊緣節(jié)點上運行代碼的工具. 但 Lambda@Edge 跟 CDN 有同樣的問題: 如果它在一段時間內(nèi)沒有接收到請求, 運行它的容器就會關(guān)閉, 再次重啟則需要一秒鐘的時間.

為何不用 Google AMP?

Google AMP 只會在用戶通過 Google 搜索引擎訪問你的網(wǎng)站時才會帶來效果. 而我的大部分流量并非來自 Google, 所以它并不能解決問題. 它僅僅對 Google 有效果, 不管其他. 而且我完全有能力在不使用他們提供的簡化 HTML 的情況下搭建一個快速網(wǎng)站.

誰在意? 3 秒的加載時間已經(jīng)很棒了!

我是一個擅長內(nèi)容傳輸?shù)?DevOps 工程師. 不管其他人如何, 我都應該有一個全球都能快速訪問的網(wǎng)站, 不是嗎? 我一般都會將 Google AMP 關(guān)閉, 因為跟他們所期望的不同, 這是一項糟糕的技術(shù).

搭建

現(xiàn)在看你的了: 是否要搭建你自己的 CDN? 源代碼在 GitHub 上, 拿去吧!

英文原文 | https://pasztor.at/blog/building-your-own-cdn

原文 | http://codebay.cn/post/7936.html

譯者：郭明

福音：天下數(shù)據(jù)私人定制全球CDN http://51huadong.com/2017/Txsjcdn.asp

本文鏈接：http://51huadong.com/cloundnews/11002527.html