Home
行業用例
CDN架構詳解：優化網站性能的技術基礎與最佳實踐

CDN架構詳解：優化網站性能的技術基礎與最佳實踐

8月 11, 202436 mins read

CDN（內容分發網絡）的架構，探索其如何提升網站性能和用戶體驗。本文涵蓋CDN的核心組件、工作原理和部署最佳實踐，幫助開發者和網站管理員有效優化網站速度和穩定性。

前言 ?

CDN(全称 Content Delivery Network)，经常被我们使用在前端资源处理中，例如：图片、视频、音频、html等静态资源。当遇到加载性能问题的时候，需要提效，会优先想到使用CDN进行加速资源处理。这篇主要带我们去了解一下CDN的原理，在了解原理前，带着下面几个问题去思考：

爲什麽要有網絡加速？
什麽是CDN？
CDN是如何實現網絡加速？
CDN有那些安全隱患？

爲什麽有網絡加速 ?

主要目的: ?提升网络性能、提供更好的用户体验。避免用户丢失，达成业务目标。所以在了解为什么需要网络加速之前，需要先了解为什么网络会堵塞。用户在访问到真是的资源之前，需要经过运营商，如下图所示：

如圖所示原因有以下幾個導致了網絡堵塞:

不同地域用户通过运营商，会跨越大海，飘洋过海的找到源服务
互聯網從邏輯上看是一張大網，但實際上是由許多小網絡組成的，這其中就有小網絡“互連互通”的問題，典型的就是各個電信運營商的網絡。
这些小网络内部的沟通很顺畅，但网络之间却只有很少的联通点。如果你在 A 网络，而网站在 C 网络，那么就必须“**跨网”传输，和成千上万的其他用户一起去“挤”连接点的“独木桥”[网络拥堵]**。而带宽终究是有限的，能抢到多少只能看你的运气。
網絡中還存在許多的路由器、网关，数据每经过一个节点，都要停顿一下，在二层、三层解析转发，這也會消耗一定的時間，帶來延遲。
最終結果就是，如果仅用现有的 HTTP 传输方式，大多数网站都会访问速度缓慢、用户体验糟糕。
放到全球來看，物理距離非常大，你在北京，訪問舊金山的網站，要跨越半個地球，地理位置距離遠、運營商網絡、路由轉發的影響就會成倍增加

什麽是CDN ?

CDN (全称 Content Delivery Network)，即內容分發網絡。CDN是以全球分布式代理服务器网络（a globally distributed network of proxy servers）来实现的。通过在现有的Internet中增加一层新的网络架构，將網站的內容發布到最接近用戶的網絡"邊緣"。 通過部署CDN邊緣服務，縮短訪問路徑，提升資源加載速度。如下圖所示：

目的： 使用戶可就近取得所需內容，解決Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。

優勢：

CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低；
大部分請求在CDN邊緣節點完成，CDN起到了分流作用，減輕了源站的負載。

本質上講CDN解決兩個問題：

高延遲。如果您的服務部署在美國，那麽亞洲地區的延遲將較高，這是由于與提供數據中心的物理距離造成的。
數據密集型應用程序：
1. 它們傳輸大量數據。在較長距離上，由于路徑中存在多個互聯網服務提供商，可能會出現問題
2. 其中一些可能具有較小的鏈路、擁塞、數據包丟失和其他問題。
3. 距離越長，路徑上的服務提供商就越多，其中一個出現問題的幾率就越高

核心技術:

CDN構建在現有網絡基礎之上的智能虛擬網絡，依靠部署在各地的邊緣服務器，通過中心平台的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。
CDN 的关键技术主要有內容存儲和分發技術
- 簡單來講，CDN就是根據用戶位置分配最近的資源，于是，用戶在上網的時候不用直接訪問源站，
- 而是訪問離他“最近的”一個 CDN 节点(也叫做“边缘节点”、edge node)，其实就是缓存了源站内容的代理服务器。
簡單理解 CDN是一組地理分布的代理服務器。代理服務器是客戶端和源服務器之間的中間服務器。

CDN訪問過程:

用户输入访问的域名,操作系统向 LocalDns 查询域名的ip地址.
LocalDns向 ROOT DNS 查询域名的授权服务器(这里假设LocalDns缓存过期)
ROOT DNS将域名授权dns记录回应给 LocalDns
LocalDns得到域名的授權dns記錄後,繼續向域名授權dns查詢域名的ip地址
域名授权dns 查询域名记录后(一般是CNAME)，回应给 LocalDns
LocalDns 得到域名记录后,向智能調度DNS查询域名的ip地址
智能調度DNS 根据一定的算法和策略(比如静态拓扑，容量等),将最适合的CDN节点ip地址回应给 LocalDns
LocalDns 将得到的域名ip地址，回应给用户端
用戶得到域名ip地址後，訪問站點服務器
CDN節點服務器應答請求，將內容返回給客戶端.(緩存服務器一方面在本地進行保存，以備以後使用，二方面把獲取的數據返回給客戶端，完成數據服務過程)絡加速

CDN系統架構 ?

工作流程

我們從源服務器爲特定DNS域或特定DNS名稱提供內容委托開始。它告訴CDN所有到特定URL的請求將被代理。
源服務器將內容發布到分發系統，負責在一組邊緣代理服務器上分發內容。通常使用“推送”和“拉取”模型，通常兩者都會被使用。
分發系統將合格的內容發送給代理服務器，同時跟蹤哪些內容在哪個代理服務器上被緩存。它還了解哪些內容是靜態的和動態的，需要刷新的數據的TTL、內容租約等等。
客户端向路由系統请求合适的代理服务器IP，或使用Anycast IP来路由到最近的位置。
客戶端請求通過Scrubber服務器。
Scrubber服務器將良好的流量轉發到邊緣代理。
邊緣代理服務器爲客戶端請求提供服務，並定期將其健康信息轉發給數據控制系統。
如果代理中不可用的內容，則會路由到源服務器

各系統簡單介紹

路由系統
- 將客戶端引導到最近或最優的CDN位置。
- 爲了有效地執行這個功能，該組件接收來自各種系統的輸入，以了解請求來自何處、內容位于何處、數據中心的繁忙程度等等。
- 有两种最流行的路由系統：带有负载均衡的DNS和Anycast。
Scrubber服務器
- 用于分離良好的流量和惡意流量，以防範DDoS攻擊。
- Scrubber服務器通常仅在检测到攻击时使用。
- 如今，Scrubber服務器非常复杂，允许客户端推送非常细粒度的防火墙规则，并在实时中在所有数据中心应用这些规则。
代理或邊緣代理服務器
- 爲終端用戶提供內容。它們通常會將內容緩存，並從RAM中提供快速檢索。
內容分發系統
- 負責將內容分發到不同CDN設施中的所有邊緣代理服務器
- 通常使用樹狀分發模型。
源服務器
- 托管在CDN上分發的原始內容的用戶基礎設施。
數據控制系統
- 用于觀察資源使用情況和統計信息。
- 該組件測量指標，如延遲、停機時間、數據包丟失、服務器負載等等。
- 然后将其反馈给路由系統以进行最佳路由。

路由轉發 ?

內容分發 ?

主動推送

主動推送就是服务器源站将內容分發到内容节点
用戶訪問時就可以直接訪問到節點上的副本

被動推送

被動訪問就是在用戶訪問時,向鏡像服務器發送請求,如果鏡像服務器上有內容,就直接返回給用戶,如果沒有,就到服務器源站獲取後在返回給用戶

調度 ?

CDN 中的重中之重，流量接入、流量牵引、选择合适的 CDN 节点服务器等工作，都是在調度环节完成的。CDN 調度是指通过各种策略将客户端请求調度到合理的目标机房。以达到成本、质量（可用性、平均速度）的最佳控制。

調度形式有以下几种：

DNS 調度
HTTP DNS 調度
302 調度
路由調度（Anycast）

DNS調度 ?

基于 local DNS 的出口 IP 归属地以及运营商的 DNS 調度。DNS 調度的问题：

DNS 缓存时间在 TTL 过期前是不会刷新的，这样会导致节点异常的时候自动調度延时很大，会直接影响线上业务访问。
大量的 local DNS 不支持 EDNS 协议，拿不到客户的真实IP，CDN 绝大多数时候只能通过local DNS IP来做决策，经常会出现跨区域調度的情况。

主域名最后是一个 CNAME 地址，最后又会再解析这个 CNAME 得到最后的结果。NS 记录显示了这个域名的权威 DNS，一般由云厂商提供。DNS 調度的问题：

DNS 缓存时间在 TTL 过期前是不会刷新的，这样会导致节点异常的时候自动調度延时很大，会直接影响线上业务访问
大量的 local DNS 不支持 EDNS 协议，拿不到客户的真实IP，CDN 绝大多数时候只能通过local DNS ip来做决策，经常会出现跨区域調度的情况。

HTTP DNS 調度 ?

客户端请求固定的 HTTP DNS 地址，根据返回获取解析结果。可以提高解析的准确性(不像DNS調度，只能通过local DNS IP来做决策)，能很好的避免劫持等问题。当然这种模式也有一些问题，例如客户端每次加载URL都可能产生一次HTTP DNS查询，这就对性能和网络接入要求很高。

302 調度 ?

基于客户端 IP 和 302 調度集群进行实时的流量調度。我们来看一个例子：

访问 URL 链接后，此时请求到了調度群集上，我们能拿到的客户端信息有客户端的出口IP（绝大多情况下是相同的），接下来算法和基于 DNS 的調度可以是一样的，只是判断依据由 local DNS 出口 ip 变成了客户端的出口IP。
浏览器收到302回应，跟随 Location 中的 URL，继续发起 http 请求，这次请求的目标 IP 是CDN 边缘节点，CDN节点会响应实际的文件内容。

302 調度的優勢：

实时調度，因为没有 local DNS 缓存的，适合 CDN 的削峰处理，对于成本控制意义重大；
准确性高，直接获取客户端出口 IP 进行調度。

302 調度的劣势：

每次都要跳轉，對于延時敏感的業務不友好。一般只適用于大文件

路由調度（Anycast） ?

基于 BGP AnyCast 路由策略，只提供极少的对外 IP，路由策略可以很快的调整。目前 AWS CloudFront、CloudFlare 都使用了这种方式，在路由层面进行調度。这种方式可以很好地抵御 DDOS 攻击，降低网络拥塞。当然这种方式的成本和方案设计都比较复杂，所以国内的 CDN 目前还都是用 UniCast 的方式。