編輯：Coco Liang

策劃：Ant Bao & Coco Liang

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

01

老樹開新花

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

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

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

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

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

02

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

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

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

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

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

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

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

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

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

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

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

在算法方面，及時(shí)的重傳技術(shù)不僅需要準(zhǔn)確的探測(cè)丟包還需要準(zhǔn)確的預(yù)測(cè)丟包，這些算法需要一系列的數(shù)據(jù)結(jié)構(gòu)和軟件架構(gòu)來支持；

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

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

03

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

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

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

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

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

攻克速度和實(shí)時(shí)性的難點(diǎn)需要同時(shí)幾方面的努力，在速度方面需要精準(zhǔn)的帶寬檢測(cè)和帶寬預(yù)測(cè)，做到盡可能大的利用可用帶寬。在實(shí)時(shí)性方面需要精準(zhǔn)的丟包檢測(cè)和丟包預(yù)測(cè)，及時(shí)重傳減小用戶感知時(shí)延等待。

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

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

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

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

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

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

除了高帶寬的要求，沉浸式會(huì)議體驗(yàn)也有非常苛刻的用戶感知時(shí)延要求，比方某些VR應(yīng)用的時(shí)延滯后達(dá)到一定閾值時(shí)，參與者會(huì)有明顯的暈眩感，這就需要不僅是5G網(wǎng)絡(luò)接入段降低時(shí)延，骨干網(wǎng)絡(luò)部分、服務(wù)器網(wǎng)絡(luò)接入部分都要有很低的時(shí)延。

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

04

5G與SRT，新與舊

談到5G可否帶來上層技術(shù)諸如多媒體壓縮技術(shù)和傳輸技術(shù)的標(biāo)準(zhǔn)化，這是個(gè)很有意思的話題。

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

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

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

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

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

我個(gè)人認(rèn)為當(dāng)前的多媒體傳輸協(xié)議標(biāo)準(zhǔn)大部分不會(huì)受到5G帶來的沖擊，只會(huì)繼續(xù)調(diào)優(yōu)適應(yīng)帶寬的增長，因?yàn)槿缜八鼋^大部分這些技術(shù)并不是為某一個(gè)G、或者某一特定路段瓶頸而設(shè)計(jì)的，是為互聯(lián)網(wǎng)設(shè)計(jì)的。

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

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

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

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

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

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

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

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

05

當(dāng)時(shí)只道是平常

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

疫情之下，平常看來理所當(dāng)然的事，其實(shí)都來之不易，我的內(nèi)心是“對(duì)自然深深的敬畏，對(duì)真情深深的感動(dòng)，和對(duì)技術(shù)強(qiáng)烈的渴望”。

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

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

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

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

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

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

相關(guān)文章：

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

“不要隨便打擾一個(gè)正在開視頻會(huì)議的人”

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

“聊五分鐘未來——視頻會(huì)議音頻技術(shù)的下半場(chǎng)”

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

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

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

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

總結(jié)

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

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