“所謂的抄近道，走的人多了，也就堵了。網絡高速路亦是如此。”
慢，大抵是互聯網時代的原罪。
因為“慢”的代價很大。
視頻加載超過7s, 87%的用戶放棄觀看；
網站打開時間超過3s，57%的用戶放棄訪問；
研究表明，每0.1秒的網站延遲，用戶轉瞬流失，會損失1%的收入。
當用戶在不斷追求更快、更好的打開方式和體驗之時，很難再接受慢下來的網絡世界，那些充滿擁塞、加載緩慢、卡頓、延時、掉幀……
如今，互聯網用戶無論是瀏覽網頁、觀看視頻，還是網購、在線學習，背后都有CDN（內容分發網絡）在后臺“加速”的身影，在支撐各類互聯網業務高速發展的同時，“加速”技術也隨之不斷發展。
一部“加速”技術的演進史，也正是一部互聯網業務的發展史。
一切唯快不破，看看“網絡高速公路”如何演進至今。
01源起：“加速”的經典架構
CDN 并不是互聯網誕生之初就存在的。
當沒有 CDN 加速時，大量的用戶請求需要穿越互聯網骨干網才能獲得源站的內容。
上世紀80年代，互聯網技術開始民用，人們主要通過撥號來訪問網絡，由于用戶少、帶寬小，并沒有對骨干網和服務器帶來壓力。
隨著互聯網高速發展，使用互聯網的用戶數量出現井噴式增長，加之寬帶接入網的出現，內容源服務器和骨干網絡的壓力越來越大。
由于網絡距離遠以及骨干網的網絡擁塞問題，端到端的請求時延會非常長，無法及時響應用戶的訪問需求，這會嚴重影響用戶體驗。
在早期CDN架構設計中，核心的目標，是通過內容的分發來實現"加速"，本質邏輯就是將文件從源站“搬”到離用戶近的地方，縮短內容傳輸的物理距離來實現所謂的"加速"效果。
那么基于這個前提和背景，技術上的重點，就是怎樣讓盡可能少的流量穿過邊緣集群回到源站，即盡可能的提高內容的命中率。
事實上，業界的廠商基本也都是在這個方面注入了最多的技術投入，盡量將訪問終結在邊緣，其次在上游增加緩存層(很多廠商叫做中間源)，來"攔截"回源流量。
所以，經典的CDN靜態加速，節點架構按照分層的設計就順理成章了，即從邊緣->一級父層->...->N級父->源站。
使用 CDN 之后，由于大量請求在邊緣就可以找到其所需的內容，因此穿越互聯網骨干網的流量大幅減少。
這樣，既有效減輕了骨干網的流量壓力，也節省了SP(Service Provider，服務提供商)的帶寬成本，促進了互聯網業務的快速發展。
02不足：動態場景下的失控
然而，在部分場景下，CDN經典技術架構并不是萬能的。
以電商、社交互動媒體、博客為代表的互聯網業務，存在大量不能緩存、需要實時回源的動態內容加速場景。
比如：電商平臺涉及了用戶注冊、登錄、在線支付、秒殺等需要動態加速的場景。
從流量上來說，一個域名全網的流量，隨著層級的深入，流量逐級減少，最終從幾個節點回到源站，面對一些內容熱度比較高的情況，回源量會更少。
從微觀來講，一般的邏輯是把內容送到離客戶最近的邊緣節點。那么，對于后續的父層節點來說(Parent Node)，依然遵循同樣的邏輯，即：一級父離edge盡量近，二級父離一級父盡量近。
最終呈現的狀態就是CDN的節點集中在離客戶端比較近的地方。
基于此，會出現一種不可避免的情況，文件沒有在CDN的網內節點命中，必須要回源，這就會經歷一個比較長的非CDN可控的公網鏈路回源。
從質量的角度來看，回源引起的質量劣化對整體域名質量的影響權重不一定很高。
舉個直觀的例子，如果客戶域名的CDN命中率是95%，即回源流量占比僅為5%，那么即使這部分流量出現響應時間異常，那么整體也只影響5%左右流量。
基于上面的論證，如果是一個需要100%回源的流量，比如登錄，提交表單，推薦列表，支付等場景下的流量。當把流量切到CDN靜態加速平臺，那么面對節點高度集中在邊緣，經過一個長距離不可控的公網鏈路回源，整體的質量將很容易失控。
03思考：動態加速的核心
對于純動態的流量，核心的問題比較明確：
當客戶流量接入到CDN邊緣節點之后，需要跨越一個很長的物理距離將請求送到客戶源站，CDN怎么承諾提供一個低延遲，高穩定的服務質量，就是一個核心的課題。
從邊緣的接入角度來看，用戶的動態流量基本都是https接入，那么基于CDN廣泛分布的邊緣節點來說，可以將客戶端訪問的TCP握手和SSL握手，卸載到CDN邊緣節點，從而讓本來需要長距離跟源站進行多次握手交互的操作，得到了極大的性能改善。
從節點內的傳輸的角度來看，要想做到最優的延遲，就需要利用最短最優的鏈路，同時在這個鏈路上配合最高效的傳輸。
“ 所謂“修好路，跑好車”，這兩項能力必須同時滿足，才能發揮最優的加速效果。”
再好的鏈路，如果中間傳輸伴隨額外的交互開銷，例如過多的tcp握手，ssl握手等，也很難承受住負向影響。
我們把這兩項能力稱為“選路能力”和“傳輸能力”，核心技術點就是：傳輸優化與動態選路。
04“修好路”：核心技術之傳輸優化
對于低延遲來說，動態流量往往都是小文件內容為主，即一次網絡交互就完成，所以傳統的CDN基于大文件下載的TCP優化，難以發揮很大的作用。
其根本原因在于：
目前TCP優化多數都是基于多包的統計和測量等方式，來探測網絡的最小延遲和最大窗口等維度的數據，來調整收發包數量和頻率。那么一次網絡交互的場景(典型的動態業務場景，例如彈幕、交易支付、登錄等)，就明顯不適用。
所以對于動態流量的加速，首包(基本就等于響應時間)就是一個核心指標。不像大文件場景，由于下載時長可能很多都是秒級以上，首包的多少，占比總的完成時間比例不是很高。
對于動態流量，首包基本就是全部。它的時間量級幾乎等于一次tcp握手的時間，那么在傳輸過程中有額外的長鏈路握手開銷，由此帶來的影響是巨大的。
對于動態流量兩項核心能力中的“傳輸能力”，核心其實是0rtt能力，所謂的0rtt指的是，CDN節點內除了必須產生的一次傳輸有效載荷行為外，不會出現網絡上的額外往返(即所謂“0”)。
在這項能力方面，阿里云的全站加速，經過多年的打磨，構建了一個用戶態的應用網絡，讓CDN邊緣和源站之間得以實現運行時零握手開銷的傳輸管道。
05“跑好車”：核心技術之動態選路
關于選路系統，基于阿里云全站加速DCDN多年的業務經驗和演進，在此文主要拋出一些觀點，來供讀者進一步的思考。
前面談到，在CDN的默認架構下，回源涉及很長的公網鏈路，這段鏈路可能要跨越不通的省份，國家，甚至大洲，又或者是需要穿過不同種類的運營商網絡。
而在廣域網的路由中，有很多復雜的地域和商業上面的定制策略，繞路之類的情況是經常出現的。
一種行之有效的方案就是基于CDN廣泛分布的節點，通過節點間的探測，配合CDN節點與各運營商的廣泛連通性，構造“路徑切割”來盡量規避穿越長鏈路可能存在的問題。
所謂的“路徑切割”就是構建多段TCP來引導數據，在路由層面盡量按照預期的鏈路來走。
對于選路來說，區別于通用的三層路由選路。
因為動態業務流量是一種具體的場景，在選路時會額外的關注節點間。節點到用戶源站層面上，業務特征、HTTP和HTTPS流量特征、TCP和UDP差異、長連接和短連接等方面，對于業務流量會有一些微妙的影響。
所以，對于網絡(如下圖)的最優路徑計算，相關的算法可以參考的較多。
“ 最優路經計算，其核心的問題，在于如何構圖，即圖的邊到底，通過哪些維度來度量與歸一化，是非常重要的課題。”
除了構圖中關于“邊”的度量和定義，還要關注“節點”的維度。學術界的經典最優選路的算法，并不考慮鏈路或者節點容量的問題。
那么，如果按照最優路徑相關算法的運行結果，會導致流量匯聚到某條鏈路或者節點，產生反向作用，導致鏈路質量上的劣化。
一個形象的比喻就是：所謂的抄近道，走的人多了，也就堵了。
傳統的經典算法，一旦涉及到鏈路容量限制，就不能正常運行，需要有新的模型來處理這類問題。
另外一個選路層面需要考慮的問題，就是：經典的路徑算法是無狀態的。
意思是說，每兩次選路的過程之間是沒有關聯的，這就會導致每次選路的結果可能差異很大，流量在網絡內瘋狂震蕩，對于系統的穩定性和處理能力有很大挑戰和風險。
最后一個在“選路”層面重點考慮的問題就是，分清楚哪些是節點層面應該做好的，哪些應該選路層面去做好的。
在SDN的領域中，節點層面被定義為數據面，選路層面定義為控制面。換句話說，所謂的控制面要控制哪些，能控制哪些？
對于業界常見的方案來說，選路基本都是中心化的，那么天然來說，節點到中心的交互就不能太頻繁。
選路層面都需要經過收集和匯聚數據的過程，決策和策略必然產生延遲。
比如10分鐘完成一個周期的任務處理和下發，那么系統一定是留有足夠的buffer的。這個buffer核心一般體現兩點，一是留有一定的余量，二是帶有一定的預測。
用一句話來講，選路系統每次計算結果，其實對節點數據面來說，有一個隱含SLA（服務水平協議）的。
比如在某個選路系統中，當前給的結果是保證的未來10分鐘內，在流量不超過xx的閾值下，延遲可以控制xx毫秒的概率是99.9%，那么對于一些秒級的鏈路閃斷或者質量惡化，就需要節點數據面有自己的容災和兜底策略，這部分是中心式選路系統的交互時間尺度內，難以提供有效支持的。
單獨站在選路的視角來看未來的演進，傳統的基于分場景，人為指定策略的探測模式(探測本質是一種旁路采樣，從統計學上來講就是希望構造一種抽樣來最大化的反映整體或者實際業務流)，然后基于此進行構圖和算路的架構，在系統優化和迭代方面，針對業務的貼合度，或多或少存在一定的GAP。
然而，在實際業務發展過程中，面對同時混合了動、靜態兩種流量場景的全站業務，相應的技術架構就需要有更多的兼顧和綜合視角的考慮，無論是“傳輸”還是“選路”。
動態加速業務的技術演進，從歷史的角度看，基本都是立足于靜態CDN架構在特定場景下的問題，不斷迭代和演進，走出了一套有差異化的架構和技術棧。
