CDN 原理入門(mén)，你學(xué)會(huì)了嗎？

作者：蠻荊 2023-03-31 08:16:39

CDN 的基本原理為反向代理，反向代理（Reverse Proxy）方式是指以代理服務(wù)器來(lái)接受 Internet 上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請(qǐng)求連接的客戶端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)節(jié)點(diǎn)服務(wù)器。通過(guò)部署更多的反向代理服務(wù)器，來(lái)實(shí)現(xiàn) 多節(jié)點(diǎn) CDN 架構(gòu)。

概述

CDN? 的全稱(chēng)是 Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)，基本思路是: 盡可能避開(kāi)互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)酶旄€(wěn)定。

圖片來(lái)源: https://www.researchgate.net/figure/Content-Delivery-Network_fig1_221632001

CDN 技術(shù)原理

CDN? 的基本原理為反向代理，反向代理（Reverse Proxy）方式是指以代理服務(wù)器來(lái)接受 Internet? 上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 Internet? 上請(qǐng)求連接的客戶端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)節(jié)點(diǎn)服務(wù)器。通過(guò)部署更多的反向代理服務(wù)器，來(lái)實(shí)現(xiàn) 多節(jié)點(diǎn) CDN 架構(gòu)。

CDN? 主要使用了負(fù)載均衡、動(dòng)態(tài)路由? 和內(nèi)容壓縮來(lái)提高其性能和可靠性:

? 分布式存儲(chǔ): 采用可擴(kuò)展的系統(tǒng)架構(gòu)，利用多節(jié)點(diǎn)、多位置、多種方式存儲(chǔ)數(shù)據(jù)

? 負(fù)載均衡: 可以將流量均勻地分配到多個(gè)節(jié)點(diǎn)服務(wù)器上，從而避免某些服務(wù)器過(guò)度負(fù)載而導(dǎo)致響應(yīng)時(shí)間延遲

? 動(dòng)態(tài)路由: 可以根據(jù)網(wǎng)絡(luò)流量和服務(wù)器負(fù)載情況來(lái)選擇最優(yōu)的路徑和服務(wù)器來(lái)響應(yīng)用戶請(qǐng)求

? 內(nèi)容壓縮: 可以將內(nèi)容文件壓縮到更小的體積，以減少網(wǎng)絡(luò)傳輸?shù)臅r(shí)間和成本

簡(jiǎn)單地理解，CDN 就是客戶端和真實(shí)服務(wù)器之間的一層高效的緩存。

傳統(tǒng)網(wǎng)站訪問(wèn)過(guò)程

在說(shuō)明 CDN? 的技術(shù)優(yōu)勢(shì)之前，我們先來(lái)看看傳統(tǒng)網(wǎng)站的 HTTP 請(qǐng)求訪問(wèn)過(guò)程。大部分開(kāi)發(fā)者應(yīng)該都熟悉 HTTP 協(xié)議基礎(chǔ)流程，下面以請(qǐng)求一個(gè)圖片文件來(lái)舉例說(shuō)明。

1.客戶端瀏覽器輸入網(wǎng)址，如 https://www.example.com/logo.png

2.瀏覽器請(qǐng)求 DNS? 服務(wù)器，查詢 https://www.example.com/logo.png? 對(duì)應(yīng)的源服務(wù)器 IP 地址

3. DNS 服務(wù)器返回對(duì)應(yīng)的 IP 地址

4. 瀏覽器向服務(wù)器發(fā)起 TCP 連接

5. 瀏覽器通過(guò)建立的 TCP? 連接發(fā)送 HTTP 請(qǐng)求圖片文件

6. 服務(wù)器向?yàn)g覽器發(fā)送圖片文件

7. 瀏覽器將接收到的圖片文件渲染，完成本次請(qǐng)求

傳統(tǒng)網(wǎng)站訪問(wèn)過(guò)程

如果我們要加入 CDN 的話，是加到哪個(gè)步驟呢？

根據(jù)上面描述的步驟不難發(fā)現(xiàn)，從第 3 步開(kāi)始，客戶端瀏覽器就和真實(shí)的服務(wù)器開(kāi)始建立連接了，連接建立完成后，客戶端瀏覽器就直接從服務(wù)器獲取數(shù)據(jù)，這顯然不是我們需要的，因?yàn)檫@樣所有的客戶端都會(huì)直接連接服務(wù)器，會(huì)嚴(yán)重增加服務(wù)器的負(fù)載。

我們?cè)賮?lái)看第 2 步，瀏覽器在訪問(wèn)真實(shí)的服務(wù)器之前，會(huì)先通過(guò) DNS? 查詢域名對(duì)應(yīng)源服務(wù)器的 IP? 地址，如果 DNS? 返回的是 CDN? 服務(wù)器的 IP? 地址，那么后面的流程就會(huì)變?yōu)? 客戶端瀏覽器就直接從 CDN? 服務(wù)器獲取數(shù)據(jù)，接下來(lái)的工作就會(huì)全部轉(zhuǎn)交給 CDN 了，如何完成這項(xiàng)工作呢？

將域名 www.example.com 的 CNAME 記錄解析到 CDN 服務(wù)商即可，CDN 服務(wù)商的 DNS 服務(wù)器也稱(chēng)為權(quán)威服務(wù)器 (細(xì)節(jié)請(qǐng)看上篇文章: DNS 原理)。

接入 CDN 網(wǎng)站訪問(wèn)過(guò)程

1. 客戶端瀏覽器輸入網(wǎng)址，如 https://www.example.com/logo.png

2. 瀏覽器請(qǐng)求 DNS? 服務(wù)器，查詢 https://www.example.com/logo.png? 對(duì)應(yīng)的服務(wù)器 IP 地址

3. 由于域名的 CNAME? 記錄解析到了 CDN? 服務(wù)商，所以這里 DNS? 服務(wù)器會(huì)返回 CDN? 服務(wù)商提供的 CDN 節(jié)點(diǎn)服務(wù)器的地址

4. 瀏覽器向 CDN? 節(jié)點(diǎn)服務(wù)器發(fā)起 TCP 連接

5. 瀏覽器通過(guò)建立的 TCP? 連接發(fā)送 HTTP 請(qǐng)求圖片文件

6. CDN? 節(jié)點(diǎn)服務(wù)器使用內(nèi)部專(zhuān)用 DNS? 解析出域名對(duì)應(yīng)的源服務(wù)器 IP 地址

7. CDN 節(jié)點(diǎn)服務(wù)器向源服務(wù)器發(fā)起TCP連接

8. CDN? 節(jié)點(diǎn)服務(wù)器通過(guò)建立的 TCP? 連接發(fā)送 HTTP 請(qǐng)求圖片文件

9. CDN 服節(jié)點(diǎn)務(wù)器接收到圖片文件后，在本地保存一份，作為緩存使用，減少源服務(wù)器的回源流量

10. CDN 節(jié)點(diǎn)服務(wù)器向?yàn)g覽器發(fā)送圖片文件

11. 瀏覽器將接收到的圖片文件渲染，完成本次請(qǐng)求

接入 CDN 網(wǎng)站訪問(wèn)過(guò)程

中央節(jié)點(diǎn)如何選擇提供服務(wù)的 CDN 節(jié)點(diǎn)

一般會(huì)綜合考慮以下幾個(gè)方面：

? 網(wǎng)絡(luò)成本
? 流量分布
? 源站負(fù)載
? 地理位置

這里以地理位置舉例說(shuō)明：

1. 用戶訪問(wèn) CDN? 服務(wù)商的權(quán)威 DNS 服務(wù)器
2. DNS? 服務(wù)器獲取用戶的 IP 地址
3. 根據(jù)用戶 IP 地址查詢用戶所在地
4. 返回離用戶最近的 CDN? 節(jié)點(diǎn)的 IP? 地址，比如用戶離北京近，就返回北京的 CDN? 節(jié)點(diǎn)的 IP 地址

按照地理位置訪問(wèn) CDN 節(jié)點(diǎn)過(guò)程

如何提高 CDN 緩存命中率

? 在流量高峰來(lái)臨前，將熱門(mén)資源提前預(yù)熱到 CDN 節(jié)點(diǎn)
? 合理配置文件緩存過(guò)期時(shí)間，如將靜態(tài)文件緩存過(guò)期時(shí)間設(shè)置為 1 個(gè)月甚至更久
? 消除 URL 中文件名稱(chēng)后面的參數(shù)，如 https://www.example.com/logo.png? 和 https://www.example.com/logo.png?versinotallow=123 應(yīng)該被視作同一個(gè)文件處理
? 超大文件設(shè)置分片回源策略，如視頻文件?, APP 安裝包等

不適合使用 CDN 的場(chǎng)景

? 請(qǐng)求客戶端和服務(wù)器物理距離很近，比如同機(jī)房、同機(jī)架的內(nèi)網(wǎng)服務(wù)
? 用戶分布在同一地理區(qū)域，如同城服務(wù)、本地門(mén)戶網(wǎng)站
? 動(dòng)態(tài)文件或接口，比如更新很頻繁的文件，使用 CDN 反而會(huì)增加響應(yīng)耗時(shí)

數(shù)據(jù)如何回源

還是以剛才的 https://www.example.com/logo.png? 為例，CDN 節(jié)點(diǎn)服務(wù)器會(huì)先把這張圖片緩存起來(lái)，下次有相同的請(qǐng)求到達(dá)時(shí)，直接返回緩存的圖片，從而減少回源流量。

這里提到的緩存? 是一個(gè)很復(fù)雜的功能，下面是阿里的 HTTP 緩存服務(wù)器，名字叫 Swift。

阿里 - CDN 節(jié)點(diǎn)

圖中是一個(gè) CDN? 節(jié)點(diǎn)，用戶的請(qǐng)求從 LVS?（LVS是一個(gè)四層的負(fù)載均衡組件）的入口來(lái)，先由 LVS? 做一次 4 層的負(fù)載均衡，然后轉(zhuǎn)到一臺(tái) Tengine?（阿里在 Nginx? 的基礎(chǔ)上開(kāi)發(fā)的服務(wù)器）上，Tengine? 做一致性哈希，選擇一臺(tái) Swift 服務(wù)器去做緩存數(shù)據(jù)回源。

阿里 - Swift 架構(gòu)

首先可以看到，Swift? 是一個(gè)多線程的程序，每個(gè)線程啟動(dòng)一個(gè) epoll? 來(lái)充分發(fā)揮多核的處理能力，并且盡量減少線程間的上下文切換，一個(gè)請(qǐng)求盡量在一個(gè)線程處理。除此之外，還能看到內(nèi)存緩存，SSD 緩存，SATA 緩存。Swift? 有熱點(diǎn)淘汰和提升機(jī)制，將熱文件放在內(nèi)存里，次熱文件放在 SSD 上，最后才是 SATA 盤(pán)。叔度 (阿里 CDN 負(fù)責(zé)人) 指出，Tengine? 和 Swift? 是通過(guò) Spdy 協(xié)議來(lái)通信的，從而優(yōu)化 HTTP 的傳輸效率。

小結(jié)

CDN 的原理是: 基于分布式架構(gòu)，通過(guò)將源服務(wù)器上的內(nèi)容分發(fā)到多個(gè)節(jié)點(diǎn)服務(wù)器上，使用戶能夠從最近的服務(wù)器中獲取所需內(nèi)容。這些節(jié)點(diǎn)服務(wù)器被稱(chēng)為邊緣服務(wù)器，它們通常位于不同的地理位置，并通過(guò)高速互聯(lián)網(wǎng)連接互相交換數(shù)據(jù)。用戶通過(guò)接入離他們最近的邊緣服務(wù)器來(lái)獲取所需的內(nèi)容，從而降低了響應(yīng)時(shí)間和延遲，提高了網(wǎng)站的訪問(wèn)速度。