展望2018：WebRTC大規(guī)模商用元年

　　2018年有可能成為是WebRTC 大規(guī)模商用的元年。WebRTC 從谷歌2011年開源到1.0標(biāo)準(zhǔn)落地花了六年多時間 ，中間經(jīng)過了一個典型的新技術(shù)早期起跑（technology trigger）— 熱炒 （peak of inflated expectation） — 失落 （trough of disillusionment） — 趨于實用 （slope of enlightenment） 的發(fā)展過程。2017年是一個轉(zhuǎn)折點，2018年我們會看到視頻通信商業(yè)應(yīng)用場景的大爆發(fā)，而WebRTC將成為主要的技術(shù)推動力。

　　2011年5月谷歌發(fā)布了一個瀏覽器內(nèi)嵌的實時音視頻通信工具的開源項目，它的核心音視頻技術(shù)來自谷歌此前收購的兩家公司：一家是瑞典VOIP技術(shù)公司GIPS，另一家是免版權(quán)（royalty free）的美國視頻編解碼器技術(shù)公司ON2，這就是WebRTC 的開始。通常我們所講的WebRTC標(biāo)準(zhǔn)其實由兩部分組成：一個是其核心的流媒體協(xié)議棧規(guī)范，這個工作是由IETF的RTCWEB Working Group在做；另一個是瀏覽器API的標(biāo)準(zhǔn)化，這個是由W3C來做。

　　WebRTC 到目前的發(fā)展過程大致可分為4個階段。第一階段是從2011年發(fā)布到2012年，這個階段從開始一些工程師對這項新技術(shù)的好奇，到geek 圈開始動手做一些好玩的試驗項目，WebRTC在很多領(lǐng)域、特別是音視頻通信技術(shù)界得到的關(guān)注迅速升溫。第二階段是2013-2014年的hype期，大家討論的話題都是WebRTC的顛覆性，在這段時期也出現(xiàn)了不少關(guān)于WebRTC的行業(yè)會議并且出席率都不錯，而很多WebRTC的創(chuàng)業(yè)公司也在這個階段成立。第三階段是2015-2016年，這個階段很有意思，一方面我們看到行業(yè)巨頭們開始進(jìn)場，比如WhatsApp和Facebook messenger都開始使用WebRTC 作為核心的音視頻通信技術(shù)；另一方面大多數(shù)WebRTC初創(chuàng)公司在商業(yè)模式上陷入了困境，其中的原因基本可以總結(jié)為兩點：一是技術(shù)本身商業(yè)化還不夠成熟，二是市場條件還沒到位。

　　2017 年，我認(rèn)為是WebRTC作為可商業(yè)化技術(shù)的里程碑。這主要是源于這一年發(fā)生的幾件事：一是在11月發(fā)布了WebRTC 1.0的標(biāo)準(zhǔn)（candidate recommendation），親自動手跟過WebRTC的開發(fā)者都會有這種體會——谷歌每一版Chrome的發(fā)布都需要馬上修改自己的code，這其實是一件比較痛苦的事情。二是蘋果宣布了對WebRTC的支持，至此也完成對WebRTC 的全平臺支持覆蓋。三是AOM （Alliance for Open Media） 的完善，隨著FB 和 Apple （2018）的加入，AOM已涵蓋基本所有互聯(lián)網(wǎng)高科技領(lǐng)軍企業(yè)，而AOM從設(shè)計上就支持RTC的應(yīng)用場景， 保證了WebRTC和媒體編解碼技術(shù)的同步進(jìn)展。

　　國內(nèi)對WebRTC 的興趣應(yīng)該是從2015年開始有比較快的發(fā)展。目前開發(fā)者大致分為幾個層次：最初級的是開發(fā)者使用開源代碼（客戶端）很方便的搭一個P2P的方案，這個基本是沒有商用價值的。往上一層則是一些解決方案會加入服務(wù)器端功能，來協(xié)調(diào)多路流的傳輸和提高穩(wěn)定性，在這個層面作為一個技術(shù)解決方案是可以的，團(tuán)隊的音視頻技術(shù)積累決定了通話質(zhì)量和穩(wěn)定性的好壞，畢竟1-1好做，越多點則難度也會越大，那么媒體服務(wù)器就成為其中的關(guān)鍵技術(shù)，如果走公網(wǎng)，在網(wǎng)絡(luò)傳輸層就需要有很多的實戰(zhàn)經(jīng)驗。再往上則是一個平臺的產(chǎn)品形態(tài)，它需要支持包括管理、分析、API等等的功能，并且在整個平臺及網(wǎng)絡(luò)的設(shè)計和運(yùn)維上達(dá)到所謂的運(yùn)營商級別，這就包括高可用性、可管理性、彈性擴(kuò)容、安全性等等，而平臺功能的高可定制性和支持私有化部署也是相當(dāng)大的需求。最上層在我看來是生態(tài)圈的層面，也就是如何在實時視頻的流量上形成一個開放的商業(yè)環(huán)境，當(dāng)然這需要一個基于WebRTC的開放的平臺作為基礎(chǔ)。

　　有人統(tǒng)計過在去年年初一共有超過1000個WebRTC項目，再往前的就很難統(tǒng)計，主要因為會嵌入在各個應(yīng)用場景中。但其實現(xiàn)在已經(jīng)很少能聽到大家專門提到WebRTC，因為如果業(yè)務(wù)場景有音視頻通信的需要時，它基本已經(jīng)成為默認(rèn)的解決方案。在視頻客服、遠(yuǎn)程醫(yī)療、遠(yuǎn)程控制等各垂直領(lǐng)域都有比較成熟的解決方案和一些專注的創(chuàng)業(yè)公司在開拓。而關(guān)注點也已經(jīng)不再是音視頻通信的本身，而是在已經(jīng)具備音視頻通信能力的基礎(chǔ)上如何提供高度場景化的客戶體驗。

　　那么在WebRTC 解決了互聯(lián)網(wǎng)音視頻通信的技術(shù)門檻問題后，有哪些行業(yè)能最大或者最快地體現(xiàn)它帶來的市場價值。目前可以看到的是，國內(nèi)的互聯(lián)網(wǎng)尤其是移動互聯(lián)網(wǎng)上基于視頻互動的各種泛娛樂應(yīng)用創(chuàng)新層出不窮，并且我相信這一領(lǐng)域還會繼續(xù)有令人耳目一新的實踐應(yīng)用涌現(xiàn)出來。此外，我個人更偏向關(guān)注視頻通信在商用場景里的發(fā)展，這里除了通常提到的在線教育、在線醫(yī)療都還有非常大的想象空間外，企業(yè)信息和業(yè)務(wù)流程的智能視頻化是一個趨勢，我也非常期待在這些領(lǐng)域看到不斷出現(xiàn)好的創(chuàng)新。

　　特別一提的是，在教育領(lǐng)域WebRTC目前的應(yīng)用場景其實是很直白的，特別是在線教育和網(wǎng)上虛擬課堂都是典型的強(qiáng)交互性場景，也有不少方案供應(yīng)商在做專門針對教育領(lǐng)域的通用、專用解決方案。即便如此整個教育行業(yè)機(jī)會依舊還很大，根本原因是教育資源的空間分布的極度不均衡，它需要有一些技術(shù)手段和解決方案消除掉這種“空間障礙”，而WebRTC因其開放性和標(biāo)準(zhǔn)性，是不二的技術(shù)選擇�？梢灶A(yù)見的是，未來隨著一些基本通信問題的解決，隨之而來的必然是用戶體驗需求的提升——更高的視頻分辨率、更低的端到端延時以及更生動的視頻畫面呈現(xiàn)就變得更急迫，我相信VR/AR與WebRTC結(jié)合的機(jī)會、以及基于人工智能的多媒體呈現(xiàn)體驗改進(jìn)將會是行業(yè)的熱點和突破點。

　　WebRTC在對主流編解碼的支持上還并不是很好，尤其對于H.265的支持，這里其實牽涉到兩個問題。一個是傳統(tǒng)的主流視頻編解碼器大多是針對比較固定的應(yīng)用場景設(shè)計并優(yōu)化的，應(yīng)用于碼率、幀率、甚至分辨率可根據(jù)網(wǎng)絡(luò)狀況實時自適應(yīng)的RTC應(yīng)用場景不是很匹配；反觀VP8、VP9，包括新一代的AV1編解碼器都是在設(shè)計上就把RTC 的應(yīng)用場景考慮在內(nèi)了。

　　第二點是版權(quán)費的問題。WebRTC的宗旨就是開放和透明，為最大限度地推廣這個技術(shù)，終端用戶必須不被昂貴的編解碼版權(quán)費所限制。還記得當(dāng)年谷歌花了很大力氣解決了VP8 的版權(quán)問題，其目的也是為了除去這個障礙，而我們也看到了MPEGLA很快就宣布H.264（Baseline Profile）免費使用，思科和微軟Edge瀏覽器也宣布了對H.264的支持，其實從某種意義上來說，WebRTC最終還是完成了實際意義上對H.264的支持。對于H.265，我猜想基于VP9和AV1的壓力，它有可能會開放免費使用，最起碼是在一些限定的應(yīng)用場景，這其中很有可能就包括WebRTC。對于大家比較期待的AV1而言，目前包括谷歌、微軟、英特爾等眾多主流廠商參與制定的bitstream格式基本已經(jīng)完成，因此很可能會在2018年集成到WebRTC中來。

　　QUIC（Quick UDP Internet Connections）協(xié)議是一種全新的基于UDP的web開發(fā)協(xié)議。相比較TCP+TLS，它具有時延低、效率高、靈活性強(qiáng)等優(yōu)點。Google作為其主要開發(fā)和倡導(dǎo)者，已經(jīng)在Chrome瀏覽器上試用多年，并取得了較好的效果。將QUIC用于實現(xiàn)WebRTC數(shù)據(jù)通道（data channel）是比較容易想象的，用它來做實時音視頻流媒體的傳輸則是很有創(chuàng)意的想法，目前還處在可行性討論的階段。

　　從技術(shù)角度的匹配似乎很容易可以看到，需要考慮的包括：首先QUIC本身還不是一個IETF標(biāo)準(zhǔn)，其次WebRTC 標(biāo)準(zhǔn)本身的向后兼容不能被破壞，以及把控制過多曝露給上層應(yīng)用是否會影響到兼容性。比較安全的做法——也是目前主流的意見，是WebRTC會將通信層做得相對獨立，在保留現(xiàn)有的通信架構(gòu)的基礎(chǔ)上增加對QUIC的支持。

　　WebRTC從最初讓人激動的發(fā)布到現(xiàn)在1.0的落地，花費了六年的時間。在這期間，互聯(lián)網(wǎng)通信不管是從底層技術(shù)，媒體終端，還是應(yīng)用場景都有很快的發(fā)展。回頭看看，WebRTC其中一些技術(shù)的選擇已經(jīng)顯得有點保守了，比如其終端媒體能力描述的形式過度依賴于SDP協(xié)議，但反過來講，要想能制定一個標(biāo)準(zhǔn)就不能老是變�？傮w而言，能將1.0 定版就是很好的一個成就。而前面也提到，WebRTC最大的成就不在于它的核心技術(shù)比其它私有的技術(shù)構(gòu)架有多么了不起的優(yōu)勢，而是在于大大降低了提供音視頻通信功能的門檻以及互通互聯(lián)的開放性。對WebRTC 1.0以后的發(fā)展，業(yè)界已經(jīng)開始有不少有意義的反思和建議，包括前面提到對QUIC的討論，以及在不破壞標(biāo)準(zhǔn)兼容性的前提下如何能給開發(fā)者有更多的自由度等等。

　　那么在探討它未來發(fā)展之前，我們一起看下在開發(fā)基于WebRTC的應(yīng)用的過程中的主要難點，大體可以分為兩個方面：客戶端側(cè)和服務(wù)器側(cè)。客戶端側(cè)的問題主要是非瀏覽器環(huán)境的支持，特別是在各種Android盒子和嵌入式設(shè)備上調(diào)試其多媒體系統(tǒng)，由于終端形態(tài)和運(yùn)行環(huán)境的差異，定制化需求比較多，往往每個典型環(huán)境的音視頻pipeline和媒體優(yōu)化參數(shù)都要做一遍，是比較繁雜的工作。而服務(wù)器側(cè)的主要問題在于面對大并發(fā)量的使用場景，要有一套優(yōu)雅、合理的媒體處理框架設(shè)計才能保證服務(wù)側(cè)系統(tǒng)的高可連接性、可靠性和可擴(kuò)展性。當(dāng)然這些問題并不是所有WebRTC用戶都會遇到，用戶可以盡量根據(jù)自己應(yīng)用場景的要求選擇恰當(dāng)?shù)目蛻舳藗?cè)和服務(wù)器側(cè)方案，在解決特別復(fù)雜的終端環(huán)境和實用場景下的問題時，最好是利用第三方經(jīng)過驗證的成熟的方案，避免重復(fù)掉到別人摔過的坑里。

　　回到WebRTC在2018年發(fā)展趨勢的話題，伴隨WebRTC 1.0標(biāo)準(zhǔn)的落地，可以預(yù)見各家瀏覽器廠商和平臺廠商未來一年會在穩(wěn)定性和兼容性方面有持續(xù)改進(jìn)，為開發(fā)者提供可靠的應(yīng)用環(huán)境和順滑的互操作性。同時也會進(jìn)入前面所提到的最上層的發(fā)展趨勢，也就是圍繞WebRTC 商用的生態(tài)圈開始成形。而基于WebRTC的技術(shù)和方案提供商則將會進(jìn)一步細(xì)分化、專業(yè)化，比如有專注于媒體服務(wù)器的、有提供WebRTC媒體網(wǎng)絡(luò)平臺運(yùn)維監(jiān)控的、有提供客戶端個性化解決方案的。不過從整個行業(yè)來看，我們還只是剛剛開始而已。

　　除了本文分享，馮昶還將在WebRTCon 2018大會上擔(dān)任“測試監(jiān)控和服務(wù)保障”專題出品人并做分享，曾擔(dān)任全球社交類App ooVoo公司CTO，讓他積累了超過10億分鐘多點高清視頻通話平臺經(jīng)驗，并擁有多項視頻通信領(lǐng)域國際專利，在WebRTC國內(nèi)外發(fā)展、技術(shù)研發(fā)難點、平臺搭建以及未來趨勢有著獨到的見解，相信他將為我們呈現(xiàn)一場精彩的專題論壇，一同探討如何提升音視頻服務(wù)的保障能力，提升產(chǎn)品魯棒性？

　　本專題我們還在積極邀請包括英特爾、阿里巴巴、愛奇藝、噠噠英語的技術(shù)大咖。更多詳情掃描下圖二維碼或點擊閱讀原文。