cdn是將源站內容分發至全國所有的節點，從而縮短使用者檢視物件的延遲，提高使用者訪問**的響應速度與**的可用性的技術。它能夠有效解決網路頻寬小、使用者訪問量大、網點分布不均等問題。
為了讓大家更全面的了解cdn的原理、排程、快取和安全等關鍵技術點，阿里雲高階技術專家白金將自己從事 cdn 相關領域工作 8 年來的一些經驗、收穫和個人認知撰寫成《cdn之我見》系列文章，分享給大家。
成多個部分，分為原理篇、詳解篇和隕坑篇，因為篇幅問題這裡先講第一部分。本篇章適合那些從未接觸過、或僅了解一些 cdn 專業術語，想深入了解和感受 cdn 究竟是什麼的同學。下面我們進入分享正文：
這個篇章，主要分成 4 個小部分來和大家做一下簡單的介紹和分享。
cdn 誕生於二十多年前，隨著骨幹網壓力的逐漸增大，以及長傳需求的逐漸增多，使得骨幹網的壓力越來越大，長傳效果越來越差。於是在 1995 年，mit 的應用數學教授 tom leighton 帶領著研究生 danny lewin 和其他幾位頂級研究人員一起嘗試用數學問題解決網路擁堵問題。
他們使用數學演算法，處理內容的動態路由安排，並最終解決了困擾 internet 使用者的難題。後來，史隆管理學院的 mba 學生 jonathan seelig 加入了 leighton 的隊伍中，從那以後他們開始實施自己的商業計畫，最終於 1998 年 8 月 20 日正式成立公司，命名為 akamai。
同年 1998 年，中國第一家 cdn 公司 chinacache 成立。
在接下來的20年中，cdn行業歷經變革和持續發展，行業也湧現出很多雲cdn廠商。阿里雲cdn是2023年從**cdn起家，在2023年正式發展成為阿里雲cdn的，它不僅為阿里巴巴集團所有子公司提供服務，同時也將自身的資源、技術以雲計算的方式輸出。
cdn 其實是 content delivery network 的縮寫，即「內容分發網路」。
之後的拓撲圖，裡面有幾個概念需要明確一下:
origin server：源站，也就是做 cdn 之前的客戶真正的伺服器。
user：訪問者，也就是問**的網民。
edge server：cdn 的伺服器，不單指「邊緣伺服器」，這個之後細說。
在 cdn 中，還有 3 個」一英里「的概念，即 first mile、middle mile 和 last mile。
first mile：和 cdn 客戶的伺服器越近越好的 cdn 裝置，即第一英里。
last mile：訪問者（網民）到離他最近的 cdn 伺服器，即最後一英里。
middle mile：資料從進入 cdn 網路，到出 cdn 網路之前的所有環節，即中間一英里。
從上圖可以看到，左圖是未做 cdn 之前跨洋跨國的長傳業務，使用者從西班牙訪問到美國紐約要經過北大西洋，直線距離6,000km 左右，按照光速300,000km/s 的傳輸速度，一束光從西班牙到紐約也至少需要 20ms 時間，乙個往返就需要 40ms。如果是光纖傳輸資料，加上傳輸損耗、傳輸裝置延時引入等，可能上百毫秒就出去了，即使用瀏覽器訪問乙個再小不過的，也會等個上百毫秒，積少成多，訪問乙個美國購物**會讓使用者無法接受。
當然，這是乙個西班牙訪問英國 cdn 節點的例子，如果 cdn 節點也位於西班牙本地，則效果會更加明顯，具體細節後續會有更詳細的說明。
接下來說一下排程。排程是 cdn 中的重中之重，流量接入、流量牽引、選擇合適的 cdn 節點伺服器等工作，都是在排程環節完成的。
要理解排程策略和原理，必須先了解 dns 協議及其工作原理。
我們平時所工作的電腦裡，都會配置（人為或自動）乙個 dns 伺服器位址，我們稱之為」本地 dns「，也叫 local dns，簡稱 ldns。在解析乙個網域名稱的時候，實際訪問的不是」網域名稱「而是 ip 位址，則 ldns 伺服器的用途就是負責將網域名稱翻譯成 internet 可以識別的 ip 位址。
在請求某個網域名稱時，ldns 一般有兩個情況：一種是網域名稱在 ldns 上有記錄，另一種情況是沒有記錄，兩種情況的處理流程不一樣。
在完全不命中情況，ldns 首先會向全球13個根域伺服器發起請求，詢問 .com 網域名稱在**，然後根域伺服器作出回答，然後去向 .com 的伺服器詢問 .163.com 在**，一步步往下，最後拿到 www.163.com 這個網域名稱所對應的 ip 位址。這個過程較複雜，如果大家感興趣可去查相關資料，在這就不一一贅述。
肯定很多人好奇是如何進行排程和進行定位的？其實也是通過 ldns 的具體位址來進行的，如上圖所示。
假設網民是乙個北京客戶，那他所使用的 dns 伺服器去做遞迴的時會訪問到cdn廠商的 glb（global load balance），它可以看到所訪問的網域名稱請求是來自於哪個 ldns，根據一般人的使用習慣，網民所在位置和 ldns 所在位置是一樣的，因此 glb 可以間接知道網民來自什麼位置。
以上圖為例，假如網民是乙個北京聯通的使用者，它使用的 ldns 位址也是北京聯通的，而 ldns 訪問 glb 也是北京聯通的，則 glb 則認為網民的位置在北京聯通，那麼會分配乙個北京聯通的 cdn 伺服器位址給 ldns，ldns 將http:www.a.com解析出的 ip 位址返回給最終網民，那麼在以後網民瀏覽器發起請求的時候，都會直接與北京聯通的 cdn 節點進行流量通訊，從而達到了加速的目的。
從這個排程理論上看，我們可以不難發現乙個問題，就是重點標註出的「根據一般人的使用習慣」。假設網民所使用的 ldns 位址和他自己在同乙個區域，排程才有可能是準確的（後續篇章會重點描述為什麼是「有可能」）。
但是舉個例子來說，如果網民是北京聯通的使用者，但他卻偏要使用深圳電信的 ldns，ldns 出口也同樣是深圳電信的 ip 位址，那麼 glb 會誤判網民位於深圳電信，分配給網民的 cdn 伺服器也都是深圳電信的，後續網民會從北京聯通訪問到深圳電信，不但沒加速，可能反而降速了。
如前文所述，由於使用者使用習慣或一些其他原因，通過 ldns 排程有可能是不準確的，因此又出現了另一種排程方式，http 302 排程。
原理很簡單，無論網民最初拿到的 ip 位址是否是正確的，但最終都是要和這個 ip 位址的 cdn 伺服器通訊的，因此 cdn 伺服器可以在這時知道網民的真實位址（dns 排程時只能間接知道網民位址，雖然 edns-client-subnet 技術可以解決問題，但尚未大規模使用）。
http 協議中有乙個特殊的返回狀態：302。在 http 伺服器返回 302 狀態碼時，可以攜帶乙個新的 url（使用的是正確 ip），瀏覽器在拿到 302 返回狀態碼時，會提取其中新的 url 位址發起請求，這樣就可以做到重新排程了。
除了 dns 排程、http 302 排程，還有一種使用 http 進行的 dns 排程策略。
隨著網路日新月異的發展和演進，也逐漸出現了很多鮮為人知的技術和裝置，例如劫持（具體在後面的篇章裡會單獨闡述）。劫持後，網民所訪問的目標有可能不再是真實伺服器，即使是真實伺服器，內容也有可能是虛假的、被替換過的，這對業務安全來說是十分危險的，這種劫持現象多出現在移動網際網路（手機上網）。
在未做 cdn 時，我們訪問某個網域名稱，直接拿到的是乙個真實的伺服器 ip 位址，這個顯示 ip 位址的 dns 記錄資訊叫 a 記錄，一般是下圖這個樣子。
當業務需要接入到 cdn 時，使用者只需調整自己的 dns 配置資訊，將 a 記錄改為 cname 記錄，將內容改為 cdn 廠商所提供的接入網域名稱即可。
詳情請閱讀原文
《CDN 之我見》原理篇 CDN的由來與排程
cdn是將源站內容分發至全國所有的節點，從而縮短使用者檢視物件的延遲，提高使用者訪問 的響應速度與 的可用性的技術。它能夠有效解決網路頻寬小 使用者訪問量大 網點分布不均等問題。為了讓大家更全面的了解cdn的原理 排程 快取和安全等關鍵技術點，阿里雲高階技術專家白金將自己從事 cdn 相關領域工作 ...
《CDN 之我見》原理篇 CDN的由來與排程
cdn是將源站內容分發至全國所有的節點，從而縮短使用者檢視物件的延遲，提高使用者訪問 的響應速度與 的可用性的技術。它能夠有效解決網路頻寬小 使用者訪問量大 網點分布不均等問題。為了讓大家更全面的了解cdn的原理 排程 快取和安全等關鍵技術點，阿里雲高階技術專家白金將自己從事 cdn 相關領域工作 ...
《CDN 之我見》原理篇 CDN的由來與排程
cdn是將源站內容分發至全國所有的節點，從而縮短使用者檢視物件的延遲，提高使用者訪問 的響應速度與 的可用性的技術。它能夠有效解決網路頻寬小 使用者訪問量大 網點分布不均等問題。為了讓大家更全面的了解cdn的原理 排程 快取和安全等關鍵技術點，阿里雲高階技術專家白金將自己從事 cdn 相關領域工作 ...