如今，阿里雲CDN服務了全球數十萬家客戶，這些客戶來自於不同行業、不同場景，有移動短視訊、有互動直播，有視訊會議，也有海外的內容分發，那麼如何深入場景，針對性優化，實現高效能的傳輸網路呢？在杭州雲棲大會飛天技術匯-CDN與邊緣計算專場中，阿里雲高階技術專家盧日為觀眾分享了阿里雲CDN在CDN網路的last mile和middle mile這兩段鏈路上，所構建的一個高效能的傳輸網路。

這個主題有兩個關鍵詞：第一個是場景化，和傳統OSI網路不太一樣的地方是。該傳輸網路針對業務場景進行了深度優化。第二個關鍵詞是高效能，怎麼定義高效能，是傳輸速度？卡頓率？實時性？對，也不對，因為每個場景所追求的KPI是不一樣的，所以盧日老師認為這個高效能一定是最大化契合各個場景KPI需求的一個綜合指標。

盧日用一張著名的網路漫畫“How Standards Proliferate”也就是“標準是如何激增”的來作為開場，標準激增這種現象在很多領域裡都有，比如電源插座，字符集編碼等等，在漫畫的最左邊框裡的文字表示的是現狀，意思是在某個領域目前一共有14個完整的標準，漫畫中間是兩個人的對話，上面一大段文字大概意思是：這位男同學說，什麼，14個？太搞笑了，不行，我們需要開發一個通用的標準來覆蓋所有的需求，然後旁邊的妹子很高興的說：yeah，太好了。右邊的框裡表達的意思是，在不久以後，在該領域一共有15個完整的標準。這就是標準激增。漫畫總是發人深省的，其實在計算機領域何嘗不是呢，在網路傳輸標準化領域尤其是這樣的。

協議逐漸深入垂直化領域

首先來看看Internet傳輸協議的一個現狀，這是以OSI模型進行分類的的資料傳輸協議象限圖，縱軸是標準化程度，這裡不單單是RFC或是W3C或是ISO的標準，也包括被業界所接受的事實標準以及普及的程度，橫軸是這些協議對內容感知的程度。乍一看很像剛剛漫畫裡的情況，這幅圖裡大概是20個，再過幾年估計還會增加。

聯絡到今天的第一個關鍵詞：場景化，通過這幅圖可以看到一個趨勢：越來越多的協議開始往紅色區域的右下角集中，也就是說越來越多的傳輸協議開始向垂直化的領域發展了。比如這裡的RakNet就是針對遊戲行業的一個可靠UDP協議，SRT是在電視臺領域的視訊傳輸協議，QUIC最初是針對網頁瀏覽設計的傳輸協議，還有HLS，DASH是OTT場景下的傳輸協議，WebRTC-RTP是視訊會議下的傳輸協議，其實這些協議並不一定有很好的標準化程度，但並不妨礙這些協議在相應的垂直領域的廣泛應用。

正所謂分久必合，合久必分，網際網路發展到今天，HTTP似乎已經開始慢慢離群了，一種通用的應用層協議越來越難滿足業務場景的需求了，為了解決多場景需求，我們是應該搞出一個比如類似OSI第八層協議來覆蓋所有場景還是應該另闢蹊徑呢？

構建高效能傳輸網路儘量契合各場景的KPI

阿里CDN的解法並不是通過再發明一種協議來覆蓋所有場景，而是通過構建一個高效能的傳輸網路來儘量契合各場景下的KPI，大家知道，CDN的核心是解決網路延時和頻寬問題，決定CDN效果好壞有很多指標，比如：精細化的排程，精準的覆蓋，優質的資源，快取命中率，網路傳輸優化等。

如今網路傳輸優化有哪些關鍵技術呢？

盧日老師大概總結了5點，這5點主要集中在CDN針對last mile和middle mile的網路傳輸上。

其中，動態選路是利用CDN的優質多線機房節點來構建一層overlay的網路，這個相較於資料包直接在Internet下傳輸會帶來相對短的延時和少的丟包；鏈路QoS保障，這是last mile的技術，通過運營商在4G或是未來5G的鏈路層上進行資源預留等技術來提高鏈路層的傳輸質量；協議棧優化是通過優化TCP擁塞控制演算法來提高傳輸效率和控制成本；私有協議是通過設計激進的傳輸協議以提高傳輸效率；多路徑傳輸則是通過在條多路徑互備傳輸來提高傳輸的可靠性。

傳輸層優化實踐

目前業界在協議棧優化和私有協議方面的研究和實踐主要集中在傳輸層優化上，比如從TCP轉換到UDP，擁塞控制演算法的研究，比如前段時間比較熱的BBR演算法，甚至學術界還有利用AI來對擁塞控制引數進行調優的嘗試。

傳輸層優化，在傳輸層優化上目前業界都是圍繞下面三個指標進行博弈：公平性Fairness，交付效率Efficiency，成本Cost，都取首字母總結下來就是FEC。

第一公平性，這個其實是運營商比較關注的，如果一個傳輸協議不考慮公平性，完全是瘋狂的發包，那麼這個一旦被發現，很可能是會被運營商封禁的，更不要說標準化了；第二交付效率，用更高的速度交付更多的資料，提高業務的QoS是CDN廠商和客戶關心的；最後一個是成本，CDN發展到今天，成本已經是決定CDN廠商生死存亡的大事了，如果一個傳輸協議只是一味地追求效率，也不追求公平性，那很簡單，最傻的辦法是每個包多發幾遍就好了，這樣效率上基本上沒什麼問題了，但成本肯定扛不住，CDN廠商需要為發出的每個位元組買單。

在這個圖裡列舉了幾種傳輸協議和擁塞控制演算法在這三個指標下的大概位置，這個只是會意性的，但可以直觀讓大家感受一下理論上最好的協議會是什麼樣的，那就是成本線無效趨近於0點，公平和效率最大化。

為什麼叫做FEC困境呢？

那是因為隨著技術的發展到今天，在總頻寬固定的情況下，在兼顧公平性和成本的情況下提高交付效率已經越來越難了，由於引數的複雜性，國外甚至有在利用AI來對擁塞控制演算法進行調優中嘗試，就像在一個封閉的獵場打獵一樣，獵物只會越來越少。

如何跳出FEC困境，開闊一片新的獵場？

盧日老師認為需要傳輸協議去理解業務，不同的業務有不同的KPI，有不同的內容優先順序，比如網頁瀏覽文字比圖片優先順序高，比如實時通訊聲音比影象高，影象裡關鍵幀比非關鍵幀高，由業務根據KPI來定義內容傳輸的優先順序，從而提高內容的有效傳輸，另外就是業務也是有實效性的，並不是我們交付的每個位元組都有意義。

在跳出FEC困境上業界在做的兩個嘗試：第一個是WebRTC-RTP，瞭解媒體傳輸的同學都知道RTP是媒體傳輸領域的一個普及和接受度都很高的媒體傳輸協議，WebRTC為了能夠適配短延時的場景選取了一系列針對性的RFC來整合到WebRTC中，比如在擁塞的情況下通過降低幀率和解析度來換取實時性，比如只傳輸關鍵幀等，所以WebRTC的傳輸不是一個協議，而是一系列協議的集合。

再看QUIC，QUIC最初是Google為了解決網頁瀏覽問題而提出的一套傳輸解決方案，後來擴充套件到視訊領域，根據Google的報告，在YouTube上面使用了QUIC傳輸以後，卡頓率有下降大約30個百分點，這些都得益於在QUIC中引入了優先順序傳輸，Multiplexing 基於UDP的流複用，還有更好的Loss Detection and Recovery丟包監測和恢復機制等。

通過上述的兩個例子，大家應該可以感覺到業界在場景化傳輸所作出的嘗試和落地實現，盧日老師總結了五個典型場景和6個KPI維度。從這個圖可以看到每個場景所追求的KPI是有差異的，如何來定義一個傳輸網路是否是高效能的在這張圖下就一目瞭然，雖然很難兼顧每個維度，但可以針對某個場景進行深耕，在相應的維度上追求極致。

阿里視訊雲的傳輸網路AliQUIC

接下來，盧日老師介紹了阿里視訊雲的傳輸網路AliQUIC：“首先澄清一下我們不是在創造一種新協議, AliQUIC簡稱aQUIC不是一個協議, 而是一種CDN last mile和middle mile的網路傳輸解決方案。”在這個網路方案裡，aQUIC不僅僅針對Web類應用，而是擴充套件到遊戲，實時音視訊通訊，互動直播和IM彈幕等一系列的場景，針對不同的場景，使用不同的演算法和技術。

aQUIC仍然把QUIC作為一個關鍵詞，QUIC有一系列非常好的技術，比如Loss Detection and Recovery，它吸取了很多TCP協議中的精華來設計它的Loss Detection and Recovery機制，從而形成了一套自己的封幀協議。盧日老師說：“我們把QUIC更多的是看做一個框架，在這個框架之上我們設計了場景化的擁塞控制演算法，場景化的流控，還有多路徑傳輸以及流複用規則等等。除此之外，我們還設計了一套類socket的API程式設計介面，方便上層應用進行程式設計。同時，我們還利用QUIC的multistreaming功能，將控制信令和資料分離，對於UDP加速場景來說，可以做到在不改變UDP MTU的情況下進行UDP資料包的透傳。“

aQUIC的特色

首先是場景化，前文有詳細講解； 第二個是模組化，每個演算法和功能點都是模組化設計，可以自由拼湊，而且會提供一套程式設計介面，方便上層呼叫； 第三個是扁平化，在最開始的資料傳輸協議象限中的另外一個趨勢，就是傳輸層和應用層之間的界限開始越來越模糊了，只做傳輸層不考慮上層業務，就會有FEC困境，而只做應用層的優化不考慮傳輸層，這個是Google最早做http/2的思路，結果做完http2.0以後發現還是不夠極致，因為下面的TCP還是有HOL的問題，所以開始要替換TCP，變成UDP，四層-七層全部打通。aQUIC也是如此，不僅四、七層打通，而且和業務打通，整體是扁平化的。 第四點是軟硬一體化，這個主要是單機效能的考慮，在現有的kernel/userspace體系架構下，UDP程式設計的效率其實是比不上TCP的，大概的效能損失相較於TCP是1倍左右，為了提升單機效能我們採用軟硬一體化的設計方案。 aQUIC是如何來解FEC困境的？

針對這6個維度，分別採用了針對性的技術和演算法，從而也達到的場景化高效能的目的。

在分享的最後，盧日老師同現場開發者一起展望未來，場景化並不是終極目標，他認為還可以更進一步，做內容感知的傳輸。

比如在城市大腦這個場景下，目前把城市各個角落的攝像頭都接入到AI系統，AI系統進行摳圖然後進行分析和結構化，那麼AI需要的是視訊流嗎？其實並不是，AI需要的是視訊中的物件，比如車，人，物，那麼是否可以做一個傳輸網路來傳輸視訊中的物件呢？ 盧日認為：“這就需要我們理解所傳輸的內容，最終構建一個基於內容感知的端到端傳輸網路，基於內容感知的端到端傳輸網路，這是我們未來努力的方向。”

原文https://yq.aliyun.com/articles/643770?spm=a2c4e.11153940.0.0.3db23403jOtB4A