网络协议 20
CDN
上一篇，看到了網站的一般訪問模式。
當一個用戶想訪問一個網站的時候，指定這個網站的域名，DNS 就會將這個域名解析為地址，然后用戶請求這個地址，返回一個網頁。就像你要買個東西，首先要查找商店的位置，然后去商店里面找到自己想要的東西，最后拿著東西回家。
那這里面還有沒有可以優化的地方呢？
例如你去電商網站下單買個東西，這個東西一定要從電商總部的中心倉庫送過來嗎？原來基本是這樣的，每一單都是單獨配送，所以你可能要很久才能收到你的寶貝。但是后來電商網站的物流系統學聰明了，他們在全國各地建立了很多倉庫，而不是只有總部的中心倉庫才可以發貨。
電商網站根據統計大概知道，北京、上海、廣州、深圳、杭州等地，每天能夠賣出去多少書籍、衛生紙、包、電器等存放期比較長的物品。這些物品用不著從中心倉庫發出，所以平時就可以將它們分布在各地倉庫里，客戶一下單，就近的倉庫發出，第二天就可以收到了。
這樣，用戶體驗大大提高。當然，這里面也有個難點就是，生鮮這類東西保質期太短，如果提前都備好貨，但是沒有人下單，那肯定就壞了。這個問題后面再說。
先來說說，網站訪問可以借鑒“就近配送”這個思路。
全球有這么多的數據中心，無論在哪里上網，臨近不遠的地方基本上都有數據中心。是不是可以在這些數據中心里部署幾臺機器，形成一個緩存的集群來緩存部分數據，那么用戶訪問數據的時候，就可以就近訪問了呢？
當然是可以的。這些分布在各個地方的各個數據中心的節點，就稱為邊緣節點。
由于邊緣節點數目比較多，但是每個集群規模比較小，不可能緩存下來所有東西，因而可能無法命中，這樣就會在邊緣節點之上。有區域節點，規模就要更大，緩存的數據會更多，命中的概率也就更大。在區域節點之上是中心節點，規模更大，緩存數據更多。如果還不命中，就只好回源網站訪問了。
這就是 CDN 分發系統的架構。CDN 系統的緩存，也是一層一層的，能不訪問后端真正的源，就不打擾它。這也是電商網站物流系統的思路，北京局找不到，找華北局，華北局找不到，再找北方局。
有了這個分發系統之后，接下來，客戶端如何找到相應的邊緣節點進行訪問呢？
之前說過基于 DNS 的全局負載均衡，這個負載均衡主要用來選擇一個就近的同樣運營商的服務器進行訪問。你會發現，CDN 分發網絡也是一個分布在多個區域、多個運營商的分布式系統，也可以用相同的思路選擇最合適的邊緣節點。
在沒有 CDN 的情況下，用戶向瀏覽器輸入 www.web.com 這個域名，客戶端訪問本地 DNS 服務器的時候，如果本地 DNS 服務器有緩存，則返回網站的地址；如果沒有，遞歸查詢到網站的權威 DNS 服務器，這個權威 DNS 服務器是負責 web.com 的，它會返回網站的 IP 地址。本地 DNS 服務器緩存下 IP 地址，將 IP 地址返回，然后客戶端直接訪問這個 IP 地址，就訪問到了這個網站。
然而有了 CDN 之后，情況發生了變化。在 web.com 這個權威 DNS 服務器上，會設置一個 CNAME 別名，指向另外一個域名 www.web.cdn.com，返回給本地 DNS 服務器。
當本地 DNS 服務器拿到這個新的域名時，需要繼續解析這個新的域名。這個時候，再訪問的就不是 web.com 的權威 DNS 服務器了，而是 web.cdn.com 的權威 DNS 服務器，這是 CDN 自己的權威 DNS 服務器。在這個服務器上，還是會設置一個 CNAME，指向另外一個域名，也即 CDN 網絡的全局負載均衡器。
接下來，本地 DNS 服務器去請求 CDN 的全局負載均衡器解析域名，全局負載均衡器會為用戶選擇一臺合適的緩存服務器提供服務，選擇的依據包括：
根據用戶 IP 地址，判斷哪一臺服務器距用戶最近；
用戶所處的運營商；
根據用戶所請求的 URL 中攜帶的內容名稱，判斷哪一臺服務器上有用戶所需的內容；
查詢各個服務器當前的負載情況，判斷哪一臺服務器尚有服務能力。
基于以上這些條件，進行綜合分析之后，全局負載均衡器會返回一臺緩存服務器的 IP 地址。
本地 DNS 服務器緩存這個 IP 地址，然后將 IP 返回給客戶端，客戶端去訪問這個邊緣節點，下載資源。緩存服務器響應用戶請求，將用戶所需內容傳送到用戶終端。如果這臺緩存服務器上并沒有用戶想要的內容，那么這臺服務器就要向它的上一級緩存服務器請求內容，直至追溯到網站的源服務器將內容拉到本地。
CDN 可以進行緩存的內容有很多種。
保質期長的日用品比較容易緩存，因為不容易過期，對應到就像電商倉庫系統里，就是靜態頁面、圖片等，因為這些東西也不怎么變，所以適合緩存。
還記得接入層緩存的架構嗎？在進入數據中心的時候，我們希望通過最外層接入層的緩存，將大部分靜態資源的訪問攔在邊緣。而 CDN 則更進一步，將這些靜態資源緩存到離用戶更近的數據中心。越接近客戶，訪問性能越好，時延越低。
但是靜態內容中，有一種特殊的內容，也大量使用了 CDN，這個就是前面介紹過的流媒體。
CDN 支持流媒體協議，例如前面講過的 RTMP 協議。在很多情況下，這相當于一個代理，從上一級緩存讀取內容，轉發給用戶。由于流媒體往往是連續的，因而可以進行預先緩存的策略，也可以預先推送到用戶的客戶端。
對于靜態頁面來講，內容的分發往往采取拉取的方式，也即當發現未命中的時候，再去上一級進行拉取。但是，流媒體數據量大，如果出現回源，壓力會比較大，所以往往采取主動推送的模式，將熱點數據主動推送到邊緣節點。
對于流媒體來講，很多 CDN 還提供預處理服務，也即文件在分發之前，經過一定的處理。例如將視頻轉換為不同的碼流，以適應不同的網絡帶寬的用戶需求；再如對視頻進行分片，降低存儲壓力，也使得客戶端可以選擇使用不同的碼率加載不同的分片。這就是我們常見的，“我要看超清、標清、流暢等”。
對于流媒體 CDN 來講，有個關鍵的問題是防盜鏈問題。因為視頻是要花大價錢買版權的，為了掙點錢，收點廣告費，如果流媒體被其他的網站盜走，在人家的網站播放，那損失可就大了。
最常用也最簡單的方法就是 HTTP 頭的 referer 字段， 當瀏覽器發送請求的時候，一般會帶上 referer，告訴服務器是從哪個頁面鏈接過來的，服務器基于此可以獲得一些信息用于處理。如果 refer 信息不是來自本站，就阻止訪問或者跳到其它鏈接。
referer 的機制相對比較容易破解，所以還需要配合其他的機制。
一種常用的機制是時間戳防盜鏈。使用 CDN 的管理員可以在配置界面上，和 CDN 廠商約定一個加密字符串。
客戶端取出當前的時間戳，要訪問的資源及其路徑，連同加密字符串進行簽名算法得到一個字符串，然后生成一個下載鏈接，帶上這個簽名字符串和截止時間戳去訪問 CDN。
在 CDN 服務端，根據取出過期時間，和當前 CDN 節點時間進行比較，確認請求是否過期。然后 CDN 服務端有了資源及路徑，時間戳，以及約定的加密字符串，根據相同的簽名算法計算簽名，如果匹配則一致，訪問合法，才會將資源返回給客戶。
然而比如在電商倉庫中，前面提過，有關生鮮的緩存就是非常麻煩的事情，這對應著就是動態的數據，比較難以緩存。怎么辦呢？現在也有動態 CDN，主要有兩種模式。
一種為生鮮超市模式，也即邊緣計算的模式。既然數據是動態生成的，所以數據的邏輯計算和存儲，也相應的放在邊緣的節點。其中定時從源數據那里同步存儲的數據，然后在邊緣進行計算得到結果。就像對生鮮的烹飪是動態的，沒辦法事先做好緩存，因而將生鮮超市放在你家旁邊，既能夠送貨上門，也能夠現場烹飪，也是邊緣計算的一種體現。
另一種是冷鏈運輸模式，也即路徑優化的模式。數據不是在邊緣計算生成的，而是在源站生成的，但是數據的下發則可以通過 CDN 的網絡，對路徑進行優化。因為 CDN 節點較多，能夠找到離源站很近的邊緣節點，也能找到離用戶很近的邊緣節點。中間的鏈路完全由 CDN 來規劃，選擇一個更加可靠的路徑，使用類似專線的方式進行訪問。
對于常用的 TCP 連接，在公網上傳輸的時候經常會丟數據，導致 TCP 的窗口始終很小，發送速度上不去。根據前面的 TCP 流量控制和擁塞控制的原理，在 CDN 加速網絡中可以調整 TCP 的參數，使得 TCP 可以更加激進地傳輸數據。
可以通過多個請求復用一個連接，保證每次動態請求到達時。連接都已經建立了，不必臨時三次握手或者建立過多的連接，增加服務器的壓力。另外，可以通過對傳輸數據進行壓縮，增加傳輸效率。
所有這些手段就像冷鏈運輸，整個物流優化了，全程冷凍高速運輸。不管生鮮是從你旁邊的超市送到你家的，還是從產地送的，保證到你家是新鮮的。
小結
CDN 和電商系統的分布式倉儲系統一樣，分為中心節點、區域節點、邊緣節點，而數據緩存在離用戶最近的位置。
CDN 最擅長的是緩存靜態數據，除此之外還可以緩存流媒體數據，這時候要注意使用防盜鏈。它也支持動態數據的緩存，一種是邊緣計算的生鮮超市模式，另一種是鏈路優化的冷鏈運輸模式。
總結
- 上一篇： ffmpeg 处理ts视频流
- 下一篇： OpenDDS内部关键的idl文件（In