范醒哲:敬畏自然 渴望技术 —— 新冠肺炎后对网络数据传输能力的思考
編輯:Coco Liang
策劃:Ant Bao & Coco Liang
時隔近一年的時間,我們再次有幸采訪到了Cascade Range Network的聯合創始人兼CEO范醒哲,這次我們和他聊了聊數據傳輸技術在視頻會議中的應用。本文由LiveVideoStack與范醒哲的郵件采訪整理而成。
01
老樹開新花
從學生時代起,我就一直在做計算機網絡協議方面的研發工作,到現在做了將近20年了,反而越做越感興趣。
2005年的時候,我開始參加工作,在University of Miami 電子與計算機工程系教授計算機網絡相關的課程,同時從事TCP方面的科研。
之后由于機緣巧合,加入了硅谷的一家創業公司Aspera,從事基于UDP的應用層協議研發。公司被成功收購后,我開始思索下一個需要被解決的大問題在哪里。
我注意到,盡管TCP是互聯網使用最廣泛的標準數據傳輸協議,但這么多年來,其性能問題卻一直是互聯網、物聯網的痛點,于是我開始了第二次創業之旅:解決TCP協議的低率問題。
我們現在的公司Cascade Range Networks在不改變TCP協議標準的前提下,重寫TCP的3萬行內核代碼,重新實現了TCP、解決了TCP為大家所詬病的低效,讓老樹也開出了新花。
02
我們的產品是一部“越野車隊”
最近由于新冠肺炎的影響,大家都在家里遠程上課、遠程辦公、遠程會議,很多平常線下的活動全部都移到了線上,有一些行業也被“逼”開直播自救,網絡帶寬因而壓力猛增。如何提升視頻流并發量從而更高效地利用網絡帶寬,成為疫情期間我們遇到的技術難點之一。
比方說原來一條1Gbps的教育線路可以支持300路高清視頻流供學生課后復習觀看,但是由于疫情,學校的IT部門突然被要求在同樣的帶寬下支持450路等同的高清視頻流。學校發現如果繼續使用原有數據傳輸技術就會出現線路擁塞,這時我們需要做的,就是在不升級線路帶寬的情況下仍能迅速支持更多的學生觀看教學視頻。
攻克這個技術難點的關鍵,是要對每一路數據流進行精準的速度控制,去除TCP的暴力發送數據、暴力搶占帶寬等造成的不必要的數據丟包和數據重傳,及時重傳丟包的同時不搶占別的數據流的帶寬,做到精準的“恒速”發送。
這個工作,就好比是以前的TCP是一群不守規矩的司機,開車頻繁換道、加速和剎車,不僅自己沒能節省時間還對其他車輛造成了干擾,從而導致道路未滿負荷就已經擁堵。
我們所做的就像是為每輛車升級,使其具備自動駕駛功能,這樣車與車之間保持勻速小間距,車輛也不再頻繁換道,盡可能讓道路做到滿負荷、高吞吐量并服務盡可能多的數據流。從而支持更多的學生在線上無卡頓地觀看教學視頻,也降低端到端的延時與滯后。
在上一次接受LiveVideoStack采訪的時候,我做過這樣一個比喻:如果把帶寬想象成“路”,那我們的產品就是無論路況好壞都可以在上面高速行駛的“越野車隊”,為客戶準確、快速、可靠地“運送”數據。
流量暴增的情況下,數據傳輸解決方案首先要保證優先傳輸關乎國計民生的視頻數據流,然后再傳輸相對次要的供大家消遣娛樂的視頻數據流,這就對數據傳輸速度有一個非常高的要求,即在帶寬擁堵等不理想的情形下能快速可靠、及時優先地傳送重要應用的數據,比方說重要的疫情監控視頻等。
以前絕大多數數據傳輸技術的缺陷在于,在理想的情形下(比方說近距離、低丟包,好比道路路況較好時)能夠持續穩定地保證數據傳輸速度,而在不理想情形下(比方說遠距離,高丟包,好比道路路況不好時)就不能夠穩定地保證傳輸速度,進而無法保證及時性,這就造成了很多現有數據傳輸解決方案依賴于專線(好比鋪設專用通道),或者依賴于提前傳輸預存(好比各地建立很多倉儲提前把視頻預存在城市附近的數據中心)。
具體來說,在沒有像這次新冠肺炎造成的互聯網數據流量暴增時,視訊服務提供方往往依賴于像CDN、SDWAN等預傳輸、預分發或專有線路優化技術,或者FEC等數據冗余技術,面對突然數據流量的急劇暴增,這些技術方案或因實施耗時而無法快速應對需求、或因預傳輸分發等無法滿足實時性要求、或因“冗余”傳輸量在需求陡增時“浪費嚴重”。
所以在突發事件發生時,不僅要靠CDN,SDWAN這樣的“道路”基礎設施類方案,還需要有“越野車隊”,能及時的傳送數據。在這次突發情形下,我們看到視頻類應用的一個核心要求就是在全天候“路況”下,如何保障其所需的傳輸速度和低時延。這里面有很多算法和系統方面的挑戰。
在算法方面,及時的重傳技術不僅需要準確的探測丟包還需要準確的預測丟包,這些算法需要一系列的數據結構和軟件架構來支持;
在系統方面,在應用層UDP之上實現這些算法相對難度較低,因而近些年來我們看到很多應用層的API的出現,但是在操作系統內核中直接重組重構重寫TCP,因內核內部沒有穩定的網絡傳輸層API,難度很大。
選擇基于UDP的應用層API還是TCP,這個可以說各有利弊,就目前的技術生態來看,完整的解決方案本身兩者是都需要的。
03
速度與激情的挑戰
這次我們聊的高清會議,在我看來主要有兩個挑戰,第一是高清帶來的傳輸速度的挑戰,第二是會議帶來的實時性挑戰。
在網絡上,大家談起速度往往同時涵蓋了單位時間道路吞吐量和用戶感知時延兩個概念。如果形象的想象每個數據包在網絡里的移動,那數據包移動的平均速度可以用時間來量化,即從數據發送端到數據接收端花了多長時間,在技術上我們稱之為時延。
當一個數據包丟失了,這個數據包就需要被重傳,所以真正的用戶感知時延往往是線路時延的數倍,這個簡單的說就是實時性的挑戰。
單獨一個包到達對用戶是沒有意義的,視頻流需要很多很多數據包才能播放起來,所以需要單位時間的吞吐量大,這個簡單的稱為傳輸速度的挑戰。
攻克速度和實時性的難點需要同時幾方面的努力,在速度方面需要精準的帶寬檢測和帶寬預測,做到盡可能大的利用可用帶寬。在實時性方面需要精準的丟包檢測和丟包預測,及時重傳減小用戶感知時延等待。
疫情造成的互聯網擁堵還增加了另外一個挑戰,就是在有限帶寬底下最大限度的提升視頻流的并發量,雖然一直有這方面的優化,但在面對突發性的互聯網流量陡增時,我們就不會僅僅滿足于次優。繼續提升的難點在于需要結合碼率做傳輸速度方面的非常精準的速度控制,這方面的工作需要一定的數學建模和像現代控制理論這樣的應用數學工具指導速度控制。
速度控制的本質是可用帶寬的跟蹤。可用帶寬隨著用戶的數量、信號的強弱、運營商的某些策略等隨著時間變化。5G帶寬大但是基站覆蓋范圍小,容易受建筑物等影響,也會造成可用帶寬的巨變。
再聊聊沉浸式會議體驗,這也是未來的趨勢之一。沉浸式會議體驗對數據傳輸技術要求的關鍵點還是高帶寬和低延時,這種帶寬和延時的要求是端到端(用戶端到服務端)的用戶感知帶寬和用戶感知時延。
5G可以解決網絡接入部分的高帶寬和低時延要求,所以很多媒體在報道時認為5G的到來意味著新興媒體體驗的到來,這個還是需要澄清一下,沉浸式會議體驗所要求的高帶寬是用戶應用感知的帶寬,它跟5G帶寬相關但不完全是5G的物理帶寬。
首先用戶感知帶寬是端到端的,這種帶寬瓶頸隨著5G接入帶寬的提升,更有可能出現在服務器端,比方說由訪問用戶增多引起的擠兌擁塞,如像這次新冠肺炎疫情造成服務器訪問流量激增而造成用戶訪問變慢;其次用戶感知的帶寬還要考慮丟包、重傳或者FEC冗余數據等造成的折扣。
5G接入帶寬的提升,會馬上暴露以上所述數據傳輸的瓶頸,而任何用戶感知帶寬過低(相比5G物理帶寬)都會馬上帶來急需解決的技術問題:比如數據發送端重傳丟包造成的數據接收端等待;簡單FEC帶來的冗余數據過多而不能自適應網絡丟包狀況;服務器高并發訪問造成帶寬利用率下降等等問題。這些都是沉浸式會議體驗給數據傳輸技術帶來的高帶寬方面的要求。
除了高帶寬的要求,沉浸式會議體驗也有非常苛刻的用戶感知時延要求,比方某些VR應用的時延滯后達到一定閾值時,參與者會有明顯的暈眩感,這就需要不僅是5G網絡接入段降低時延,骨干網絡部分、服務器網絡接入部分都要有很低的時延。
考慮到共享網絡時延的不可預測性,沉浸式會議體驗所要求的低用戶感知時延將會更多依賴優化路由甚至租用專線來滿足,但數據傳輸本身,比如發送端不能及時重傳先前丟失數據從而造成的接收端應用等待,進而造成用戶感知延時過大也是非常需要注意的問題。
04
5G與SRT,新與舊
談到5G可否帶來上層技術諸如多媒體壓縮技術和傳輸技術的標準化,這是個很有意思的話題。
接入帶寬的極大提升的確給了上層技術更多的想象空間,好比存儲空間的極大提升也促進了文件系統、文件格式的發展,不過這將是一個非常漫長的過程。
網絡和存儲的不同在于,網絡是一個多層多樣的系統,5G僅是網絡接入技術。就好比我們家庭寬帶以前依賴銅纜,現在越來越多依賴光纖,接入帶寬的提升僅是把瓶頸從一個地方移到了另外一個地方。新的瓶頸將更有可能出現在流媒體服務器端,甚至是5G基站的互聯網接入端。
我們知道網絡除了路段多樣和瓶頸多樣外,它的數據通訊實現也是分層的,各層之間的設計是相對獨立的,所以上層傳輸層或者應用層并不知曉端到端(用戶端到服務器端)發生在何處,上層對底層的瓶頸是一視同仁的。
一個好的協議或者標準,在設計之初不會僅為一個G而設計,或者僅針對某個特定路段的瓶頸而設計,它是相對穩定的。一個簡單的例子就是TCP協議,它從最初的1G到現在的5G,都是互聯網的標準,支撐著我們最常見的像HTTPS這樣的應用層協議。
我想,這個話題更深一層的思索,是以前的協議或者標準是否能夠在5G時代繼續生存和發展。具體而言,數據傳輸協議在5G時代(平均無線用戶感知100Mbps的量級,相比4G時代平均用戶感知10Mbps的量級、3G時代的平均1Mbps的量級)是否能繼續生存下去,還是將被新的協議標準所替代。
我個人認為當前的多媒體傳輸協議標準大部分不會受到5G帶來的沖擊,只會繼續調優適應帶寬的增長,因為如前所述絕大部分這些技術并不是為某一個G、或者某一特定路段瓶頸而設計的,是為互聯網設計的。
5G帶來的速度提升對上層應用來說也并不是第一次遇到,比方說在我們的家庭寬帶接入中,也是從小帶寬提升到100Mbps的量級,而且現在100Mbps早已不少見,這些協議一直在發展并勝任了家庭光纖接入,我想它們也能勝任5G時代的到來。
當然5G的另一挑戰是帶寬大但基站覆蓋范圍小,對終端用戶體驗的影響是帶寬瞬時變化巨大,您可能在路上移動轉個彎,手機的速度就或許就從100Mbps掉到1Mbps以下。
這當然是一個很有意思的問題,我個人覺得很多現有的多媒體傳輸技術面對帶寬的劇烈波動是會受影響,所以每個協議需要做些相應的工作,但這些應該不會影響協議標準,僅是協議內部的調優。當然優化也會造成優勝劣汰,讓我們拭目以待。
SRT隨著互聯網音視頻應用的增多也會逐步增多各種應用場景。
一個協議被看好與否不僅僅是技術原因,比方說是否容易集成、是否容易調優、是否可以自學習適應各種不同的網絡環境和不同的應用要求等,還有很多商業因素,比方說是否有聯盟支持、聯盟中企業在互聯網和其相關行業中的分量、是否容易找到相應的集成和開發人員等等。
總體來說SRT相較其他視頻流傳輸格式(RTMP、HLS、DASH等)有一定技術和非技術方面的優勢,但是SRT的劣勢也是相當明顯的,就是在高并發時帶寬的浪費。這也是整個基于UDP的視頻傳輸協議目前的通病,目前來看還是比較適合點對點視頻傳輸,比方說網紅直播時主播推流到平臺,還有企業高清視頻會議,在點到面上的場景現在應用起來需要一些冗余帶寬,比如阿里一年一度的晚會等特殊場合。
長遠來說實現SRT與專業實時會議通訊系統的兼容,還有一定的路要走,需要廠家的集成與支持。據我們觀察,廠家在對SRT的支持上也是有一定的私心的,比如說將SRT的經驗用于廠家自己私有協議的開發、還有一些廠家在優化SRT后未完全公開優化代碼等等。
我個人覺得,廠家從自身商業利益考慮,將來會在自己的設備中支持多個標準協議,保證設備的通用性。比方說同時支持基于UDP和TCP的傳輸方案,在這點上,這些不同方案對廠家來說是一個生態,在其產品里一個合作的生態更有利于其硬件系統在互聯網、物聯網的普適性。
05
當時只道是平常
疫情影響了很多行業,也讓很多人“閑”在家里,可以說是“人閑了,網絡忙了”。而我們這些網絡工程師恰恰相反,在疫情期間反而比平常更忙。
疫情之下,平常看來理所當然的事,其實都來之不易,我的內心是“對自然深深的敬畏,對真情深深的感動,和對技術強烈的渴望”。
在面對突發事件時,大家通過在家辦公、在家上課,繼續為社會做貢獻的同時也減輕了給地球生態帶來的壓力。這些都離不開一個更加強大的互聯網和物聯網,也讓我們對現在做的工作多了一份使命感。
CRN是一家專注于數據傳輸技術的公司,一直致力于革新陳舊的數據傳輸協議,解決互聯網和物聯網上各種數據傳輸瓶頸。
當前我們看到的最大的數據傳輸瓶頸就是互聯網最廣泛使用的傳輸協議TCP的瓶頸,這個協議40年來未能與時俱進,有很多技術方面的難點,深嵌在操作系統的內核中,內核本身有非常多的變種和版本,市場產品等碎片化非常嚴重;也有理論方面的難點,比方說需要很多智能控制與預測算法。
由于互聯網的存在,地球越來越小,我們今天可以跨區域、跨洋進行超高清的視頻會議、視頻點播,這在以前只有通過衛星才能做到的事,現在也能通過CDN、SDWAN等底層技術與上層應用結合來實現。
我們的目標是繼續降低互聯網數據移動的成本,盡可能利用已有的共享互聯網絡帶寬,減少不必要的專線開銷,減少不必要的緩存服務器開銷。
疫情結束了,我們會抓緊時間提升互聯網的數據傳輸效率。好好工作,只爭朝夕,不負韶華。
相關文章:
“‘疫‘外爆發:沒那么簡單的視頻會議”
“不要隨便打擾一個正在開視頻會議的人”
“我們請到了聲網、億聯和網易云信,來聊聊疫情帶來的一些思考”
“聊五分鐘未來——視頻會議音頻技術的下半場”
“做技術的,不要去迷信黑科技 | 對話思科Webex 研發總監汪凱”
LiveVideoStackCon 2020?上海/北京/舊金山 講師招募
2020年LiveVideoStackCon將持續迭代,LiveVideoStackCon將分別在上海(6月13-14日),北京(9月11-12日)和舊金山(11月)舉行。歡迎將你的技術實踐、踩坑與填坑經歷、技術與商業創業的思考分享出來,獨樂不如眾樂。請將個人資料和話題信息郵件到 speaker@livevideostack.com 或點擊【閱讀原文】了解成為LiveVideoStackCon講師的權益與義務,我們會在48小時內回復。
Hey,有關下一代音視頻會議的技術和趨勢,你還想聽我們聊些什么嗎,記得評論區留言:)
總結
以上是生活随笔為你收集整理的范醒哲:敬畏自然 渴望技术 —— 新冠肺炎后对网络数据传输能力的思考的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: LiveVideoStack线上分享第五
- 下一篇: 音视频技术开发周刊 | 134