編輯：Coco Liang

策劃：Ant Bao & Coco Liang

時隔近一年的時間，我們再次有幸采訪到了Cascade Range Network的聯(lián)合創(chuàng)始人兼CEO范醒哲，這次我們和他聊了聊數(shù)據(jù)傳輸技術在視頻會議中的應用。本文由LiveVideoStack與范醒哲的郵件采訪整理而成。

01

老樹開新花

從學生時代起，我就一直在做計算機網(wǎng)絡協(xié)議方面的研發(fā)工作，到現(xiàn)在做了將近20年了，反而越做越感興趣。

2005年的時候，我開始參加工作，在University of Miami 電子與計算機工程系教授計算機網(wǎng)絡相關的課程，同時從事TCP方面的科研。

之后由于機緣巧合，加入了硅谷的一家創(chuàng)業(yè)公司Aspera，從事基于UDP的應用層協(xié)議研發(fā)。公司被成功收購后，我開始思索下一個需要被解決的大問題在哪里。

我注意到，盡管TCP是互聯(lián)網(wǎng)使用最廣泛的標準數(shù)據(jù)傳輸協(xié)議，但這么多年來，其性能問題卻一直是互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的痛點，于是我開始了第二次創(chuàng)業(yè)之旅：解決TCP協(xié)議的低率問題。

我們現(xiàn)在的公司Cascade Range Networks在不改變TCP協(xié)議標準的前提下，重寫TCP的3萬行內(nèi)核代碼，重新實現(xiàn)了TCP、解決了TCP為大家所詬病的低效，讓老樹也開出了新花。

02

我們的產(chǎn)品是一部“越野車隊”

最近由于新冠肺炎的影響，大家都在家里遠程上課、遠程辦公、遠程會議，很多平常線下的活動全部都移到了線上，有一些行業(yè)也被“逼”開直播自救，網(wǎng)絡帶寬因而壓力猛增。如何提升視頻流并發(fā)量從而更高效地利用網(wǎng)絡帶寬，成為疫情期間我們遇到的技術難點之一。

比方說原來一條1Gbps的教育線路可以支持300路高清視頻流供學生課后復習觀看，但是由于疫情，學校的IT部門突然被要求在同樣的帶寬下支持450路等同的高清視頻流。學校發(fā)現(xiàn)如果繼續(xù)使用原有數(shù)據(jù)傳輸技術就會出現(xiàn)線路擁塞，這時我們需要做的，就是在不升級線路帶寬的情況下仍能迅速支持更多的學生觀看教學視頻。

攻克這個技術難點的關鍵，是要對每一路數(shù)據(jù)流進行精準的速度控制，去除TCP的暴力發(fā)送數(shù)據(jù)、暴力搶占帶寬等造成的不必要的數(shù)據(jù)丟包和數(shù)據(jù)重傳，及時重傳丟包的同時不搶占別的數(shù)據(jù)流的帶寬，做到精準的“恒速”發(fā)送。

這個工作，就好比是以前的TCP是一群不守規(guī)矩的司機，開車頻繁換道、加速和剎車，不僅自己沒能節(jié)省時間還對其他車輛造成了干擾，從而導致道路未滿負荷就已經(jīng)擁堵。

我們所做的就像是為每輛車升級，使其具備自動駕駛功能，這樣車與車之間保持勻速小間距，車輛也不再頻繁換道，盡可能讓道路做到滿負荷、高吞吐量并服務盡可能多的數(shù)據(jù)流。從而支持更多的學生在線上無卡頓地觀看教學視頻，也降低端到端的延時與滯后。

在上一次接受LiveVideoStack采訪的時候，我做過這樣一個比喻：如果把帶寬想象成“路”，那我們的產(chǎn)品就是無論路況好壞都可以在上面高速行駛的“越野車隊”，為客戶準確、快速、可靠地“運送”數(shù)據(jù)。

流量暴增的情況下，數(shù)據(jù)傳輸解決方案首先要保證優(yōu)先傳輸關乎國計民生的視頻數(shù)據(jù)流，然后再傳輸相對次要的供大家消遣娛樂的視頻數(shù)據(jù)流，這就對數(shù)據(jù)傳輸速度有一個非常高的要求，即在帶寬擁堵等不理想的情形下能快速可靠、及時優(yōu)先地傳送重要應用的數(shù)據(jù)，比方說重要的疫情監(jiān)控視頻等。

以前絕大多數(shù)數(shù)據(jù)傳輸技術的缺陷在于，在理想的情形下（比方說近距離、低丟包，好比道路路況較好時）能夠持續(xù)穩(wěn)定地保證數(shù)據(jù)傳輸速度，而在不理想情形下（比方說遠距離，高丟包，好比道路路況不好時）就不能夠穩(wěn)定地保證傳輸速度，進而無法保證及時性，這就造成了很多現(xiàn)有數(shù)據(jù)傳輸解決方案依賴于專線（好比鋪設專用通道），或者依賴于提前傳輸預存（好比各地建立很多倉儲提前把視頻預存在城市附近的數(shù)據(jù)中心）。

具體來說，在沒有像這次新冠肺炎造成的互聯(lián)網(wǎng)數(shù)據(jù)流量暴增時，視訊服務提供方往往依賴于像CDN、SDWAN等預傳輸、預分發(fā)或專有線路優(yōu)化技術，或者FEC等數(shù)據(jù)冗余技術，面對突然數(shù)據(jù)流量的急劇暴增，這些技術方案或因實施耗時而無法快速應對需求、或因預傳輸分發(fā)等無法滿足實時性要求、或因“冗余”傳輸量在需求陡增時“浪費嚴重”。

所以在突發(fā)事件發(fā)生時，不僅要靠CDN，SDWAN這樣的“道路”基礎設施類方案，還需要有“越野車隊”，能及時的傳送數(shù)據(jù)。在這次突發(fā)情形下，我們看到視頻類應用的一個核心要求就是在全天候“路況”下，如何保障其所需的傳輸速度和低時延。這里面有很多算法和系統(tǒng)方面的挑戰(zhàn)。

在算法方面，及時的重傳技術不僅需要準確的探測丟包還需要準確的預測丟包，這些算法需要一系列的數(shù)據(jù)結構和軟件架構來支持；

在系統(tǒng)方面，在應用層UDP之上實現(xiàn)這些算法相對難度較低，因而近些年來我們看到很多應用層的API的出現(xiàn)，但是在操作系統(tǒng)內(nèi)核中直接重組重構重寫TCP，因內(nèi)核內(nèi)部沒有穩(wěn)定的網(wǎng)絡傳輸層API，難度很大。

選擇基于UDP的應用層API還是TCP，這個可以說各有利弊，就目前的技術生態(tài)來看，完整的解決方案本身兩者是都需要的。

03

速度與激情的挑戰(zhàn)

這次我們聊的高清會議，在我看來主要有兩個挑戰(zhàn)，第一是高清帶來的傳輸速度的挑戰(zhàn)，第二是會議帶來的實時性挑戰(zhàn)。

在網(wǎng)絡上，大家談起速度往往同時涵蓋了單位時間道路吞吐量和用戶感知時延兩個概念。如果形象的想象每個數(shù)據(jù)包在網(wǎng)絡里的移動，那數(shù)據(jù)包移動的平均速度可以用時間來量化，即從數(shù)據(jù)發(fā)送端到數(shù)據(jù)接收端花了多長時間，在技術上我們稱之為時延。

當一個數(shù)據(jù)包丟失了，這個數(shù)據(jù)包就需要被重傳，所以真正的用戶感知時延往往是線路時延的數(shù)倍，這個簡單的說就是實時性的挑戰(zhàn)。

單獨一個包到達對用戶是沒有意義的，視頻流需要很多很多數(shù)據(jù)包才能播放起來，所以需要單位時間的吞吐量大，這個簡單的稱為傳輸速度的挑戰(zhàn)。

攻克速度和實時性的難點需要同時幾方面的努力，在速度方面需要精準的帶寬檢測和帶寬預測，做到盡可能大的利用可用帶寬。在實時性方面需要精準的丟包檢測和丟包預測，及時重傳減小用戶感知時延等待。

疫情造成的互聯(lián)網(wǎng)擁堵還增加了另外一個挑戰(zhàn)，就是在有限帶寬底下最大限度的提升視頻流的并發(fā)量，雖然一直有這方面的優(yōu)化，但在面對突發(fā)性的互聯(lián)網(wǎng)流量陡增時，我們就不會僅僅滿足于次優(yōu)。繼續(xù)提升的難點在于需要結合碼率做傳輸速度方面的非常精準的速度控制，這方面的工作需要一定的數(shù)學建模和像現(xiàn)代控制理論這樣的應用數(shù)學工具指導速度控制。

速度控制的本質(zhì)是可用帶寬的跟蹤?？捎脦掚S著用戶的數(shù)量、信號的強弱、運營商的某些策略等隨著時間變化。5G帶寬大但是基站覆蓋范圍小，容易受建筑物等影響，也會造成可用帶寬的巨變。

再聊聊沉浸式會議體驗，這也是未來的趨勢之一。沉浸式會議體驗對數(shù)據(jù)傳輸技術要求的關鍵點還是高帶寬和低延時，這種帶寬和延時的要求是端到端（用戶端到服務端）的用戶感知帶寬和用戶感知時延。

5G可以解決網(wǎng)絡接入部分的高帶寬和低時延要求，所以很多媒體在報道時認為5G的到來意味著新興媒體體驗的到來，這個還是需要澄清一下，沉浸式會議體驗所要求的高帶寬是用戶應用感知的帶寬，它跟5G帶寬相關但不完全是5G的物理帶寬。

首先用戶感知帶寬是端到端的，這種帶寬瓶頸隨著5G接入帶寬的提升，更有可能出現(xiàn)在服務器端，比方說由訪問用戶增多引起的擠兌擁塞，如像這次新冠肺炎疫情造成服務器訪問流量激增而造成用戶訪問變慢；其次用戶感知的帶寬還要考慮丟包、重傳或者FEC冗余數(shù)據(jù)等造成的折扣。

5G接入帶寬的提升，會馬上暴露以上所述數(shù)據(jù)傳輸?shù)钠款i，而任何用戶感知帶寬過低（相比5G物理帶寬）都會馬上帶來急需解決的技術問題：比如數(shù)據(jù)發(fā)送端重傳丟包造成的數(shù)據(jù)接收端等待；簡單FEC帶來的冗余數(shù)據(jù)過多而不能自適應網(wǎng)絡丟包狀況；服務器高并發(fā)訪問造成帶寬利用率下降等等問題。這些都是沉浸式會議體驗給數(shù)據(jù)傳輸技術帶來的高帶寬方面的要求。

除了高帶寬的要求，沉浸式會議體驗也有非?？量痰挠脩舾兄獣r延要求，比方某些VR應用的時延滯后達到一定閾值時，參與者會有明顯的暈眩感，這就需要不僅是5G網(wǎng)絡接入段降低時延，骨干網(wǎng)絡部分、服務器網(wǎng)絡接入部分都要有很低的時延。

考慮到共享網(wǎng)絡時延的不可預測性，沉浸式會議體驗所要求的低用戶感知時延將會更多依賴優(yōu)化路由甚至租用專線來滿足，但數(shù)據(jù)傳輸本身，比如發(fā)送端不能及時重傳先前丟失數(shù)據(jù)從而造成的接收端應用等待，進而造成用戶感知延時過大也是非常需要注意的問題。

04

5G與SRT，新與舊

談到5G可否帶來上層技術諸如多媒體壓縮技術和傳輸技術的標準化，這是個很有意思的話題。

接入帶寬的極大提升的確給了上層技術更多的想象空間，好比存儲空間的極大提升也促進了文件系統(tǒng)、文件格式的發(fā)展，不過這將是一個非常漫長的過程。

網(wǎng)絡和存儲的不同在于，網(wǎng)絡是一個多層多樣的系統(tǒng)，5G僅是網(wǎng)絡接入技術。就好比我們家庭寬帶以前依賴銅纜，現(xiàn)在越來越多依賴光纖，接入帶寬的提升僅是把瓶頸從一個地方移到了另外一個地方。新的瓶頸將更有可能出現(xiàn)在流媒體服務器端，甚至是5G基站的互聯(lián)網(wǎng)接入端。

我們知道網(wǎng)絡除了路段多樣和瓶頸多樣外，它的數(shù)據(jù)通訊實現(xiàn)也是分層的，各層之間的設計是相對獨立的，所以上層傳輸層或者應用層并不知曉端到端（用戶端到服務器端）發(fā)生在何處，上層對底層的瓶頸是一視同仁的。

一個好的協(xié)議或者標準，在設計之初不會僅為一個G而設計，或者僅針對某個特定路段的瓶頸而設計，它是相對穩(wěn)定的。一個簡單的例子就是TCP協(xié)議，它從最初的1G到現(xiàn)在的5G，都是互聯(lián)網(wǎng)的標準，支撐著我們最常見的像HTTPS這樣的應用層協(xié)議。

我想，這個話題更深一層的思索，是以前的協(xié)議或者標準是否能夠在5G時代繼續(xù)生存和發(fā)展。具體而言，數(shù)據(jù)傳輸協(xié)議在5G時代（平均無線用戶感知100Mbps的量級，相比4G時代平均用戶感知10Mbps的量級、3G時代的平均1Mbps的量級）是否能繼續(xù)生存下去，還是將被新的協(xié)議標準所替代。

我個人認為當前的多媒體傳輸協(xié)議標準大部分不會受到5G帶來的沖擊，只會繼續(xù)調(diào)優(yōu)適應帶寬的增長，因為如前所述絕大部分這些技術并不是為某一個G、或者某一特定路段瓶頸而設計的，是為互聯(lián)網(wǎng)設計的。

5G帶來的速度提升對上層應用來說也并不是第一次遇到，比方說在我們的家庭寬帶接入中，也是從小帶寬提升到100Mbps的量級，而且現(xiàn)在100Mbps早已不少見，這些協(xié)議一直在發(fā)展并勝任了家庭光纖接入，我想它們也能勝任5G時代的到來。

當然5G的另一挑戰(zhàn)是帶寬大但基站覆蓋范圍小，對終端用戶體驗的影響是帶寬瞬時變化巨大，您可能在路上移動轉個彎，手機的速度就或許就從100Mbps掉到1Mbps以下。

這當然是一個很有意思的問題，我個人覺得很多現(xiàn)有的多媒體傳輸技術面對帶寬的劇烈波動是會受影響，所以每個協(xié)議需要做些相應的工作，但這些應該不會影響協(xié)議標準，僅是協(xié)議內(nèi)部的調(diào)優(yōu)。當然優(yōu)化也會造成優(yōu)勝劣汰，讓我們拭目以待。

SRT隨著互聯(lián)網(wǎng)音視頻應用的增多也會逐步增多各種應用場景。

一個協(xié)議被看好與否不僅僅是技術原因，比方說是否容易集成、是否容易調(diào)優(yōu)、是否可以自學習適應各種不同的網(wǎng)絡環(huán)境和不同的應用要求等，還有很多商業(yè)因素，比方說是否有聯(lián)盟支持、聯(lián)盟中企業(yè)在互聯(lián)網(wǎng)和其相關行業(yè)中的分量、是否容易找到相應的集成和開發(fā)人員等等。

總體來說SRT相較其他視頻流傳輸格式（RTMP、HLS、DASH等）有一定技術和非技術方面的優(yōu)勢，但是SRT的劣勢也是相當明顯的，就是在高并發(fā)時帶寬的浪費。這也是整個基于UDP的視頻傳輸協(xié)議目前的通病，目前來看還是比較適合點對點視頻傳輸，比方說網(wǎng)紅直播時主播推流到平臺，還有企業(yè)高清視頻會議，在點到面上的場景現(xiàn)在應用起來需要一些冗余帶寬，比如阿里一年一度的晚會等特殊場合。

長遠來說實現(xiàn)SRT與專業(yè)實時會議通訊系統(tǒng)的兼容，還有一定的路要走，需要廠家的集成與支持。據(jù)我們觀察，廠家在對SRT的支持上也是有一定的私心的，比如說將SRT的經(jīng)驗用于廠家自己私有協(xié)議的開發(fā)、還有一些廠家在優(yōu)化SRT后未完全公開優(yōu)化代碼等等。

我個人覺得，廠家從自身商業(yè)利益考慮，將來會在自己的設備中支持多個標準協(xié)議，保證設備的通用性。比方說同時支持基于UDP和TCP的傳輸方案，在這點上，這些不同方案對廠家來說是一個生態(tài)，在其產(chǎn)品里一個合作的生態(tài)更有利于其硬件系統(tǒng)在互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的普適性。

05

當時只道是平常

疫情影響了很多行業(yè)，也讓很多人“閑”在家里，可以說是“人閑了，網(wǎng)絡忙了”。而我們這些網(wǎng)絡工程師恰恰相反，在疫情期間反而比平常更忙。

疫情之下，平?？磥砝硭斎坏氖?#xff0c;其實都來之不易，我的內(nèi)心是“對自然深深的敬畏，對真情深深的感動，和對技術強烈的渴望”。

在面對突發(fā)事件時，大家通過在家辦公、在家上課，繼續(xù)為社會做貢獻的同時也減輕了給地球生態(tài)帶來的壓力。這些都離不開一個更加強大的互聯(lián)網(wǎng)和物聯(lián)網(wǎng)，也讓我們對現(xiàn)在做的工作多了一份使命感。

CRN是一家專注于數(shù)據(jù)傳輸技術的公司，一直致力于革新陳舊的數(shù)據(jù)傳輸協(xié)議，解決互聯(lián)網(wǎng)和物聯(lián)網(wǎng)上各種數(shù)據(jù)傳輸瓶頸。

當前我們看到的最大的數(shù)據(jù)傳輸瓶頸就是互聯(lián)網(wǎng)最廣泛使用的傳輸協(xié)議TCP的瓶頸，這個協(xié)議40年來未能與時俱進，有很多技術方面的難點，深嵌在操作系統(tǒng)的內(nèi)核中，內(nèi)核本身有非常多的變種和版本，市場產(chǎn)品等碎片化非常嚴重；也有理論方面的難點，比方說需要很多智能控制與預測算法。

由于互聯(lián)網(wǎng)的存在，地球越來越小，我們今天可以跨區(qū)域、跨洋進行超高清的視頻會議、視頻點播，這在以前只有通過衛(wèi)星才能做到的事，現(xiàn)在也能通過CDN、SDWAN等底層技術與上層應用結合來實現(xiàn)。

我們的目標是繼續(xù)降低互聯(lián)網(wǎng)數(shù)據(jù)移動的成本，盡可能利用已有的共享互聯(lián)網(wǎng)絡帶寬，減少不必要的專線開銷，減少不必要的緩存服務器開銷。

疫情結束了，我們會抓緊時間提升互聯(lián)網(wǎng)的數(shù)據(jù)傳輸效率。好好工作，只爭朝夕，不負韶華。

相關文章：

“‘疫‘外爆發(fā)：沒那么簡單的視頻會議”

“不要隨便打擾一個正在開視頻會議的人”

“我們請到了聲網(wǎng)、億聯(lián)和網(wǎng)易云信，來聊聊疫情帶來的一些思考”

“聊五分鐘未來——視頻會議音頻技術的下半場”

“做技術的，不要去迷信黑科技 | 對話思科Webex 研發(fā)總監(jiān)汪凱”

LiveVideoStackCon 2020?上海/北京/舊金山 講師招募

2020年LiveVideoStackCon將持續(xù)迭代，LiveVideoStackCon將分別在上海（6月13-14日），北京（9月11-12日）和舊金山（11月）舉行。歡迎將你的技術實踐、踩坑與填坑經(jīng)歷、技術與商業(yè)創(chuàng)業(yè)的思考分享出來，獨樂不如眾樂。請將個人資料和話題信息郵件到 speaker@livevideostack.com 或點擊【閱讀原文】了解成為LiveVideoStackCon講師的權益與義務，我們會在48小時內(nèi)回復。

Hey，有關下一代音視頻會議的技術和趨勢，你還想聽我們聊些什么嗎，記得評論區(qū)留言:)

總結

以上是生活随笔為你收集整理的范醒哲：敬畏自然 渴望技术 —— 新冠肺炎后对网络数据传输能力的思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。