本文來自網心科技首席架構師李浩在LiveVideoStackCon 2017大會上的分享，李浩回顧了從迅雷時代到網心科技，P2P CDN的演進，以及挑戰和應對方案。

文 / 李浩

整理 / LiveVideoStack

大家好，我是來自網心科技的李浩，今天和大家分享一種新型CDN架構，匯聚家庭用戶的閑置網絡和計算資源構建的共享式CDN，整個過程會面臨很多的技術挑戰，下面會做些分析并介紹下解決思路。

我們的理想

我們希望通過共享的方式來降低企業計算成本，節約社會資源。共享經濟的模式這幾年發展很快，說實話迅雷當年搭建了一套業界最大的利用共享計算資源來做內容分發的網絡，網心繼承了迅雷的技術優勢，想用一個更標準化的方式對外提供一套高性能和低成本的商用服務。

有調查顯示現在生產出來的商品能10倍覆蓋我們當前的需求量，包括帶寬、存儲、計算這些數字化產品和服務。Uber、Airbnb這類產品為什么能火起來，就是因為提供了所有權向使用權高效轉移的途徑，盤活了巨大的存量資源。我們的目標是盤活家庭用戶擁有但很難完全使用的計算、存儲和網絡資源，使服務節點下沉在用戶家中，在網絡的最邊緣提供實時的服務，第一個切入點就是CDN市場。

現實與挑戰

從前兩位嘉賓的分享可以看到CDN要做得事情很多，遠不止緩存分發一件事情，需要提供一整套的多媒體傳輸、編解碼、截圖、存儲、運營服務。我們要在該功能集上面把共享資源有效的用起來，更會碰到一些額外的挑戰。首先，節點之間的連通性，如何在全球Nat設備分布最多的國家達到一個超高連通率。其次，波動場景的應對能力，質量波動相對來說好解決一點，容量波動是難題，IDC帶寬容量是有保障的，但在家庭環境下，有很多應用在同時運行，多個家庭共享有限的小區帶寬出口，無法保證穩定的資源容量和全局資源視圖。同時，不同協議的傳輸優先級，多個家庭節點之間網絡距離的精確測定，用IP判斷無法達到小區級的精度，多端數據共享，提高流量放大比等問題都需要有效解決。

直播架構

以典型的直播場景來展開介紹。主播推流和回源拉流構成數據輸入，輸入數據以后CDN主要做兩件事情，一個就是流數據處理，包括協議轉換、轉碼、截圖、轉點播等；另一個是中轉分發，其中最核心的是組網策略，我們通過玩客云節點做了一次末端流量放大，同樣的由于鏈路增加一跳，組網復雜度指數級增加。為了達到更高的放大比，玩客云節點訂閱直播流的一部分信息，SDK需要并行從多個玩客云節點獲取編碼的切片數據然后還原，封裝為標準的http-flv、hls數據流給到客戶端。最理想的情況下，對于1Mbps的熱流，一個10Mbps上行能力的末端節點，由于數據編碼和分片策略的存在，可以達到1000倍以上的放大比，帶寬壓力完全下移，遠優于傳統p2p方案。

架構實例

從數據流層面看，數據進入系統后，在IDC節點內部上行轉發時會做多份拷貝，避免單鏈路的問題，因為這里是整條鏈路最脆弱的一環。下行主要是按需回源，但對熱流和冷流做一些區分處理，冷流對CDN的需求是中轉加速的需求，好比北京電信的一個主播在直播，全國就覆蓋了十個觀眾，命中率和流量放大等指標基本沒有意義，系統核算內部鏈路成本后不會使用到共享計算節點，最核心的訴求就是縮短中轉加速路徑。熱流需要在內部分發路徑上做冗余保障，數據分片配合編碼糾錯是一個不錯的方式，同時盡可能使用共享節點來提高放大比，跳數帶來的內部帶寬完全可以消化。

內部組網架構

上面列出了我們內部組網的幾次演進，最開始是固定的樹狀結構，根據運營商的拓撲結構，選定兩到三個多線路BGP節點做為源，同時根據運營商拓撲結構選出區域中心點，例如華北、華東這些地域，組成一個比較清晰的三層架構。因為結構層級很清晰，路由都是按照預定好的規則去設置，便于研發和運營，一開始起步選這種結構，我覺得是合理的，但是到后面呢，就會發現，它很便于運營，但是它特別依賴于運營，需要運營人員對整體的網絡拓撲結構非常了解。舉個例子，假設核心源點一個選擇了河南，一個選擇了廣州，那么你可能會出現問題，2015年底的時候，電信的京漢廣骨干經常癱瘓，一癱瘓兩個點全都不能用，我們需要知道中國的骨干鏈路是怎么建的，需要能支持這種骨干之間的容災，是一個依靠人的強運營網絡。

第二種方案是很自然演變過來的，把規劃好的區域和源節點抽象成節點池，比第一種方案多一套路由系統。不再依賴之前設定的靜態路由規則，假設之前設置的華東節點只能走華東和華北區域中心，現在可以通過一些探測算法來動態選擇，我們有一些專利算法，例如eqv算法會通過丟包、重傳、延時數據來和關鍵業務指標擬合，通過訓練好的擬合參數來為每一條有基礎網絡數據的鏈路評分。其次影響路由的還有成本權重，本來回源北京節點是最快的，質量可能是98分，但是從山東走質量是95分，但是山東能直接命中，北京需要回源多一跳成本，那對于能接受95分質量的業務應該優先走山東。有了動態路由系統后，運營工作量大為減少，主要處理一些資源的縮擴、預知的網絡割接等事項就行。

對已經在服務的鏈接根據路由系統指令，要避免乒乓效應帶來的額外開銷，就是切A切B切A切B這種場景。同時對直播來說很核心一點，要把數據給無縫的拼接起來，因為無法保證兩個不同節點擁有同樣的時間起點的數據流，在切換過程中如果上一個節點傳到某一個編號的P幀，下一個節點就要跟著下一個P幀就往下去傳，這里面可以通過特殊標記或者對幀做哈希的方式來拼接，保證路由生效過程中的觀看連貫，否則會產生直播重放等問題很影響觀看體驗。

這個組網方案一開始非常好用，直到UGC直播火起來后逐漸碰到瓶頸。一些客戶高峰會有上萬路推流并發，在這種情況下，避免不了很多流是長尾流，長尾流在這種固定的網絡層級下面確實會有跳數浪費，對只有兩個人觀看的，或者只有一個人觀看的，仍然要走固定跳數。好比主播在山東推流，北京有一個用戶觀看，源設置在上海，整體路徑就是山東到華北區域中心，再到上海，再后到北京，最后到用戶，中間浪費的路徑比你真正吐出去的這個帶寬多好幾倍的，而且可能質量還不如北京用戶直接訪問山東節點。因此這套組網方式在處理冷流上瓶頸是比較大的。

第三種其實是一種網狀結構，但是不是無任何規則的網狀結構，待會會詳細講一下規則策略，每一個主播都是一個數據源點，這個對冷流多的場景也非常友好，但是要把數據處理系統給獨立開來，需要全局可訪問的截圖、錄播、轉碼系統的支持難度會提升不少。

最后是我們針對熱流、重點流的處理思路，內部分發類似SDK的處理方式是一樣的，中間會做編碼處理，像剛才有個同學去問Akamai是否會做編碼處理，Akamai說因為他們的計算開銷太大了沒有做過多編碼處理。看過13年Akamai出的一些論文，傳輸過程中會做一些簡單正交編碼配合簡單糾錯，把一路數據流拆分成三道去往上推。我們也是做編碼處理，只不過我們內部編碼處理分兩種，一種是簡單糾錯，一種是復雜糾錯，以復雜糾錯為主。數據推過來以后，重點數據流編碼后按照一定冗余度往上去推，一定的程度的丟包是可以克服的，盡量降低雙向的數據交互來降低延時。下行通過無率碼編碼和分發，中間的節點不需要cache所有數據，下行節點通過多個點并行獲取一定冗余度的碼片并組合。對熱流會分發到所有邊緣節點的場景，帶寬節省也很顯著。

對冷流熱流的處理

詳細說一下冷流處理，我們的處理邏輯就是組建弱網狀結構，根據一定的規則和跳數約束來構建的應用級的組播網。核心的路由系統采用etcd存儲全量策略，每一個轉發節點會有路由代理緩存部分數據并做一些主備線路的質量決策。對冷流邏輯就是降低跳數，減少中間損耗，上行是被動方式，沒人觀看的情況下數據就不要往上走。下行的主動路由查詢，邏輯也是去提高命中率，這個點如果有數據且質量符合的情況下，不應該再去拓展一條新的路徑。

根據數據源和觀看分布會有幾種場景：無人觀看、同省同網、同網跨區等，最復雜的是跨網跨區，這種情況也可以在四到五跳到達，和樹形結構的一般場景類似，所以真正在線上運營會發現針對UGC的流能節省一半的內部帶寬。因為大部分的冷流，尤其是現在的移動直播，App端會用地理位置信息做主播和內容推薦，冷流的主播和觀眾很大概率在一個區域內。

熱流也會依賴路由系統，對熱流核心是快速獲取到，盡量保證重要節點上已經存在該數據。因此不再做被動上行，會主動分發的，采取一倍以上的鏈路冗余。會存在冷熱轉換的過程，因此路由策略要及時刷新，熱變冷暫時不考慮。

最后一跳的難點

最后一跳是共享CDN方案的差異化優勢點，用SDK的模式把用戶資源用起來，做一層毛細節點放大，通過無速率的信道編碼來應對波動和實時性要求。傳統的P2P方案數據是順序強相關，主要靠節點間緩存數據的錯時實現分享，延時和分享率互相矛盾，同時需要很多的雙向交互和補片策略，無法達到很高的放大比。

我們采用運算復雜度較高的噴泉碼方案，因為最后一層的共享節點，相對于20Mbps的平均帶寬，4核Arm處理器的計算能力是遠超的，對比服務器的萬兆帶寬和32核處理器。因此采用高復雜度前置編碼算法非常合理，采用這種方式的數據碼片每個都包含原數據的部分特征，像噴泉一樣去往外噴，只需要接住一杯原始數據就解出來了。在這種情況下，基本不需要雙向交互，采用訂閱的模式，告知需要原始數據的比例，上行節點按照比例隨機給出碼片。

啟播過程中通過服務器拿到首幀和音視頻描述信息，同時找共享節點訂閱，根據fps、cps指標來判斷節點吞吐狀態，流量逐漸傾斜至共享節點，如果節點資源不足，也可以逐漸傾斜至服務器節點，過程是平滑的沒有硬切換。同時每個碼片包含原始數據部分特征且不重復，因此從多個節點高并發獲取實時數據是可行的，放大比可以很高，對于熱流共享節點的1KB碼片數據可以分享給上千個客戶端。

要達到最高效率，共享節點端要支持全棧協議，同時支持rtmfp、data chanel、自定義，同一份數據可以提供個不同的客戶端，C化rtmfp協議難度很高。

內部傳輸策略與難點解決

效果展示

還有很多策略細節，例如點播業務在播放前放廣告，可以采用慢速啟播直接走共享節點分發，成本會節省不少。

傳輸協議以UDP為主，同時保存TCP快速通道，傳遞音視頻描述、控制信令這些關鍵數據。

波動的應對參考BBR，對鏈路質量做評估，估算出最佳冗余率，核心目的是避免補數據拉高延時。

編碼算法優化，常規噴泉碼算法實現是N3復雜度，無法在線上實用，這里權衡了度分布做了很多效率優化。

調度還有一些問題可能要去處理，除了質量和成本的策略，還需要關注容量波動，我們采用雙端判定的方式，調度給出優選節點列表，客戶端根據調度的節點主動選擇，服務節點可以根據自己的負載和cps指標主動斷連。節點間的拓撲分布會利用定時的traceroute探測來計算。

上行的第一跳受限的可能是物理通道，我們推出了一款電信、聯通、移動的三通道推流器，根據鏈路質量做負載均衡，數據同樣采用噴泉碼方式推送，很適合戶外高清直播場景。

從目前實際的效果數據中可以看出，在弱網場景下的傳輸優勢還是很顯著的。

共享計算展望

CDN是共享計算的第一個切入點，也只是平臺上的一個服務插件。我們的希望能通過輕量虛擬化的方式，統一底層的賺錢寶、玩客云資源，對外提供一套標準化的云計算服務，降低分布式存儲、AI訓練、流量分發等場景的服務成本。

Q/A

Q1：剛才你講到那個冷流調度的時候提到有些路徑的規則會提前下發下去，但是在冷流這種流維度的情況下應該不是用下發規則來實現的？

A：冷流路徑是不提前下發的，但是我們會有些規則規約，就是最理想的情況下它是個純網狀結構，無論在哪個運營商，只看延時丟包等網絡指標。很有可能直播流推到了北京聯通，那么北京電信，或者河北電信的用戶訪問，直接通過北京聯通訪問，假設我也能知道這個網絡情況OK，這種是最理想的情況。但是這種無預制規則的網狀結構，對判斷準確度要求很高，而且也會產生很多切換開銷，運營難度高。因此我們會定一些規則，就好比，我們還是要堅持同運營商優先，主播是北京聯通，那么用戶是河北電信，訪問路徑還是河北電信到中間的一個雙線中轉點，再到北京聯通，在這個過程中我們堅持的是一些預制規則，而設置固定路徑，通過這些規則，路由系統動態生成路徑。

Q2：那在找冷流的路徑這個過程中會有個中心的狀態服務存在嗎？

A：會有。上面已經介紹，單機上會有一個路由代理，其次有個中心路由服務，中心路由服務用etcd記錄全局信息，路由代理會緩存一些路徑信息同時有部分主動決策能力。

Q3：一般來說，小運營商和大運營商網間的質量不會太好？這個怎么保證呢？

A：盡量保證網內匯聚，降低出網流量，根據運營商的拓撲結構合理選擇網間節點，通過一些匯聚線路來做中轉，避免用戶直接跨網訪問。

Q4：前面有講到C化，如果C化這部分對用戶的設備壽命有什么影響？

A：C話是指共享節點上的服務進程能執行rtmfp協議，可以和flash客戶端直接互通，flash會看作一個對等peer，和用戶的硬件設備無關。難點是rtmfp非公開，通過字節碼逆向分析難度高。

Q5：使用設備上的一些存儲空間之類的嗎？

A：閑置資源包括帶寬、存儲、算力，但是對直播這個場景下我們不需要用存儲，純內存的，對點播這種場景需要提前做一些部署的，大家知道迅雷的離線下載，現在接近百分之百全都遷移到了共享計算平臺上，迅雷的離線下載服務也相當于我們下面的一個插件。

Q6：問一下，就是我們用戶那種節點，它那個如果是宕了，得多長時間能從網絡里替掉？

A：剛才說了去做雙向選擇，用戶節點如果宕了，這個控制權應該是SDK層面就立馬去把它替掉的，我們不管是宕了，還是網絡中斷了，就是它沒有按照規定的CPS去吐數據，我需要淘汰它了，因為它的長上下線是很頻繁的，無法根據完全調度來下發指令決策，調度根據幾次心跳十幾秒的時間來確認的狀態也不實時。調度給到SDK的服務節點數是有接近一倍的富余度的，SDK會自己判定。

Q7：他會有很大量的備份？掛了立馬就去連別的？

A：是的。

Q8：我還有個問題，如果是邊緣，用戶節點這個地方，它一般那個帶寬量很有限，我們假設建立了幾個連接，我的意思是你怎么限制它那個帶寬呢？就是我可能很快就已經把帶寬跑爆了？

A：首先對數據進行編碼切片，通過幾十個共享節點同時提供數據，訂閱過程中會指定希望獲取該路流多少比例的數據量。同時上面介紹過容量判斷策略，后端節點是有剔除鏈接能力的，如果共享節點監控到cps等服務指標下降，會主動斷掉部分鏈接，避免出現雪崩。

LiveVideoStackCon 2018講師招募

LiveVideoStackCon 2018是音視頻技術領域的綜合技術大會，今年是在10月19-20日在北京舉行。大會共設立18個專題，預計邀請超過80位技術專家。如果你在某一領域獨當一面，歡迎申請成為LiveVideoStackCon 2018的講師，讓你的經驗幫到更多人，你可以通過speaker@livevideostack.com提交演講信息。了解大會更多詳情，點擊【閱讀原文】訪問LiveVideoStackCon 2018官網，報名即刻享受7折優惠。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的李浩：无限节点的CDN架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。