WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!






話說,這種變化似乎就發生在一夜之間……

從跨國VoIP電話到連麥互動以及實時音視頻通話;

從直播答題撒幣到傳統電商都可以實時在線抓娃娃;

將「新鮮」趁熱打鐵,火的不要不要的微信官方小程序也趕趟兒宣布開放了實時音視頻通信接口;

就連人們熟知的教育、互聯網金融、安防以及企業通信,也都紛紛對實時互動場景拋出了繡球,開展了「聯姻」……

「實時」兩個字滿屏飛,背後呢?

這些讓人感覺頗為新奇的「變化」統統都要歸功於RTC技術。

RTC,如今人們經常說到的實時通信技術,從傳統互聯網過渡到移動互聯網的過程中,在很多領域都有廣泛應用。

如今開發者們完全可以通過各種實時通信API集成RTC雲服務能力,在各種原生應用、Web網頁、H5、硬件設備中加入實時通信功能,而WebRTC被稱為網路實時通信,是 RTC子模塊之一,被日漸重視。

相關數據顯示,每周僅在Chrome瀏覽器上就會有超過15億分鐘的WebRTC音視頻通話。

依照目前的統計,有超過1,300個從事WebRTC的公司和項目。

瀏覽器在日常生活中如此常見,據悉所有安裝的瀏覽器中就會有80%已經內置了WebRTC。

應用頻率如此之高,可見其技術發展日漸成熟。在此基礎上,WebRTC1.0候選推薦標準也於去年正式被「呼出」。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

可能出現的標準「新探」都在這里

基於此,在RTC2018大會上,WebRTC標準委員會委員Daniel C. Burnett為與會開發者們詳細介紹了該標準實施之後所開展的各項工作。他表示,其實在核心規範層面的變化是比較少的,說到發展,絕大多數是針對部分規範增強的「加碼」!

通常來說,人們都比較注重安全問題,當然WebRTC也不例外。為防止信息泄露,通常都會對RPT的流量進行加密。

背後的理念就是加密捕獲的媒體,必須要有指定個人進行解密,而且需要登陸之後才可以做到,

這點是需要額外注意的特殊功能之一。

進一步來說,WebRTC對於瀏覽器,一旦接觸到媒體就會產生編碼,可以使用任何想要的編碼器進行解碼工作,在這方面的拓展主要集中在讓開發者可以使用java進行解密或者加密,從而對編碼參數的控制更加有力。基於這個功能,WebRTC達到的效果是可以做到不需要經常打開瀏覽器的窗口。

這究竟有何好處呢?

可以妥妥解決臨時進入的電話接聽問題。

「這個功能十分適合視頻,過程中不需要經常打開瀏覽器窗口;而且還對背景語音的處理十分有效,尤其是語音識別方面。」Dan Burnett補充道。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

WebRTC標準委員會成員 Daniel C. Burnett

此外,關於SVC的controls的性能加持也十分重要。

具體來說, Daniel C. Burnett 闡釋道,本質上是一個可擴展的視頻編碼,具備後就可以在時間與空間上進行壓縮,其中時間壓縮能以比較慢的速率發送幀,比較高的速率插入可選的額外幀,類似於大家喜歡的聯播。

其中空間壓縮和時間壓縮非常類似,能夠發送低分辨率的幀,可以插入可擴展分辨率額外的幀等,所以可以採用比較低分辨率的幀。

「目前,我們正在設計一個加速 TLS以及HTTP新傳送,這是受到WebRTC開發經驗和教訓的啟發。這點Google非常支持我們,之前在quick領域做得很多開發實踐都是基於WebRTC之前的經驗和教訓,如今可能涉及到不同的連接設置中往返需要時間這樣類型的探索。」他說。

眾所周知,讓互聯網更快的路就是通往QUIC的這一條。Daniel C. Burnett也提出,quic流的數據通道作為大家都非常喜歡的概念,尤其是使用quic流的數據通道,在Java的語言下比較簡單。

如果具體說說QUIC這條「捷徑」,騰訊TEG基礎架構部高級架構師羅成,曾在公開場合表示,其實QUIC的設計目的是為了減少傳輸延時。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

為何TA能夠有效減少傳輸延遲呢?主要還是由於幾方面特性。

羅成認為,首先能夠幫助0RTT建立連接,其次可以做到全用戶態傳輸控制。

一般來說,TCP的運算控制都是基於內核操作系統協議站做到的,如果要在其中完成一些優化改進甚至監控部署都需要涉及到服務器操作系統的修改甚至客戶端操作系統的修改,通常是不可能的,這個特性的部署升級壓力非常大,但是QUIC不一樣,是全用戶態做到,可以非常精準地做到特性。

此外,QUIC可以避免隊頭阻塞的多路復用。由於QUIC請求和請求之間都是完全獨立的,一個請求丟包只會影響「眼下」關聯的一個請求,不會影響別的。

相比之下,TCP不知道對應了多少個請求,如果產生丟包現象,也就不知道剩下等待請求的數量,自然就會產生隊頭阻塞。

這麼看,QUIC被高效利用「有情可原」,同樣對其深入研究的新浪微博技術專家聶永則表示,其實QUIC還涉及到一個前期篩選的過程。

他介紹說,選用QUIC還需要從自身出發,注意很多實驗機制、方案以及框架。「當時我們都在選擇的過程中,出現了go-quic,由於用戶不活躍就被排除了;另外一個就是Google的QUIC,想把它轉換成生產級的發現則需要很大的努力,更重要的一點它是使用C++語言寫的,因為我本身不會C++,所以就沒選擇它;一輪選擇之後,我們發現Caddy+QUIC可以提供一站式網路堆棧服務,方便成熟且使用者眾多,更新機制頻繁。」聶永補充道。

盡管QUIC有這樣那樣的優勢,但長期實踐表明,對於企業來說採用之後還是存在一定的困難,例如首當其沖的表現就是協議複雜性。

由於未來需要做到TCP的可靠性、擁塞控制、流量控制以及安全的指標,所以必然會出現QUIC協議被陸續替換並趨於標準化的情況。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

最重要的一點,技術的快速變化以及協議的快速迭代,差不多一個半月就有一個新的QUIC版本出現。QUIC現默認使用自己做到的握手協議,但後續計劃使用TLS1.3替代,這就增加了自己架構的難度,關於這個問題,聶永提出借助開源的想法,如果在工具層面可以做到就減輕了「重復造輪子」的負擔。

至此,我們不得不正視一個問題,如今整個社會還沒有為QUIC的到來做好準備,經營商針對UDP的支持也是不足的,表現不穩定。

例如,有些ISP會直接屏蔽UDP,UDP有時需要被偽裝成TCP才能正常傳輸,UDP帶寬有時相比TCP狹窄,UDP流量可能會因QOS線速判定為丟包……

此外,QUIC穿透性差,NAT局域網路、交換機、防火牆等會禁止UDP 443同行,防火牆有時只「認可」TCP……相對來說,實驗室數據還是比真實環境測評出來的數據漂亮很多,這一點需要企業在使用QUIC時多加注意。

會上,Dan Burnett還提到了解決NAT的問題的ICE。

通常,如果想從一個網路轉換到另一個網路,就算使用的是移動終端,無線轉換也非常耗費時間的,過程需要重新打包甚至還會出現丟包現象,所以ICE的使用過程中充滿挑戰。

此外還有一點,對於很多開發商來說不希望使用SDP是共同的「夙願」。

如何在使用ICE的同時不用SDP,其實還存在其他的運輸途徑,例如quic。由於ICE想控制的是用戶能夠使用哪個地址的問題,包括APP地址以及其他,完成這些最重要的依舊是對速度的極致要求。

「WebRTC1.0版本現在運轉得非常好,相信未來會越來越好,據了解已經有APP在使用WebRTC1.0版本。但值得注意的一點,如今WebRTC是一個平台,而且會不斷延伸,衍生平台或產品未來會更加亮眼,越發被注意。」

你理解最新的標準測試「那些事兒」嗎?

標準呼出之後自然要觀察適用效果,GoogleWebRTC產品經理HuibKleinhout對此深受感觸。

他表示,關於WebRTC的1.0版本,標準在實踐中加以測試很重要,可以借此判斷任何時間條件下標準是否適用。

說到WebRTC的測試,據悉這與其他的網路標準並不相同。

例如,Google之間有一個kite,可以將兩個瀏覽器進行連接,瀏覽器可以進入機器,也可以在原端,還可以是物理的硬件,而且能夠把測試結果報告給安卓等,這樣兩個服務器就做到直接對話了。

更重要的一點,這種測試不單單針對標準的適用性,還能夠測試基於WebRTC應用。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

Google WebRTC產品經理 Huib Kleinhou

Huib Kleinhou認為,WebRTC在開始階段與現在的1.0版本有非常大區別,包括Google、chrome等都做了大量的工作。例如,關於chrome,加入一些API,避免直接使用SDP;調整到另外一個SDP,讓瀏覽器會更加具有一致性。

反觀瀏覽器的性能提升,例如chrome和safari,要保障它們更好的符合標準要求,同時又有一定的靈活性。未來對於Edge有需要進行更多提升,因為基於WebRTC以及API需要開展越來越多的工作。「我們的方向非常好,希望在未來將這個應用進一步改善和提升。」Huib Kleinhou說。

此外,關於WebRTC的1.0版本,還需要考慮其穩定性以及可靠性。

其中一個非常重要的修訂是MacAudio,主要針對解決MacOS之前出現的相關問題;另外就是關於chrome的螢幕共享。

通常,我們與其他人進行平台共享時,不是帶寬不夠就是乾脆沒有網路,螢幕延遲以及死機都是常有的事兒。關於這方面,Google團隊做了一定改進並保證更好的自動化,盡管效果不夠完美,但針對相關問題總結後會有進一步提升。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

「坑坑窪窪」的規模商用尚待成熟

話說,標準有了,測試做了,似乎說著說著還要落地到應用實踐的層面。

聊到這里,可能不少開發者有這樣的想法。

WebRTC並不算一個特別新的概念,就連1.0說話也就落地了,如今構建很多不同領域的應用,例如視頻通話、遠程醫療等,開發者們第一時間也可以想到WebRTC,證明這個普及程度還是十分令人欣喜額,此外關於一些to C產品的應用,例如Facebook message等,如此推測大規模商用的門檻高不高呢?

對此,聲網Agora首席WebRTC架構師陳功在演講「WebRTC在大規模的商業應用中的實踐」中提出,其實從WebRTC到大規模的商用,還是會遇到非常棘手的問題。

首先可能就是通信質量的「那些事兒」。陳功表示,真正商用的場景中不可避免會有多人的場景,這就需要有一個KOS的優化策略。如果過程中所面向的用戶客戶是全球分布的,更需要智能路由以及全球化的部署服務節點的能力。

除了質量之外,在可用性方面,全球化部署的服務節點必然需要高可用的運維,同時服務的終端不會是單純的PC端瀏覽器, 這麼看還要有跨平台互通的,包括與移動端、其他第三方接入的互通能力。

關於以上這些問題的解決,從服務架構出發,陳功介紹,WebRTC協議站開發了WebRTC的Gateway網關,這個網關會負責瀏覽器端的Web用戶和Agora大網進行接入,同時還負責一些頻道的創建、媒體流的發布、媒體流的訂閱、消息的傳遞和狀態反饋,整個網關是一個就近接入的分布式部署,充分利用了Agora傳輸網路的優勢,因為WebRTC本身是點對點的。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

「另外,由於整個服務體系中非常重要的就是數據驅動,從數據方面可以看到大體可以分成三部分。」總結道。

第一部分是在媒體服務器上或WebRTC網關上能看到的采集到的數據,包括延時、抖動、丟包,還包括網關和SD-RTN TM之間的傳輸狀態。

端上最重要的就是pc.getStats,會挑選其中大多數比較有意義的進行采集,包括非常重要的帶寬可能、關鍵幀請求等信息。最後的數據是SDK的logger,對分析的用戶真正真實場景遇到的問題非常重要。

應用落地始終是打開大規模商用的第一步,所以針對不同場景的優化體驗,聲網把WebRTC用到大規模的商用要服務於不同垂直領域的客戶,區分一些場景。

例如,直播場景就比較要求高清的畫質,通信場景的重要指標就是流暢性,所以針對這些不同的場景像採用編碼選擇參數的設置、傳輸策略上進行根據場景的定制等。

此外,關於WebRTC前端應用中的經驗和教訓,TutorABC的資深架構師孫高朝列舉了在線課堂系統中經常出現的問題,例如學生反映怎麼看不到顧問,也聽不到聲音;顧問也反映聽不到學生聲音,看不到自己的影像。

孫高朝對與會開發者們表示,總結之後發現上述這幾類問題,基本上歸功於設備問題和網路問題,其中設備問題占了絕大部分。

通常提及的GetUserMedia並不能算真正的設備問題,只是調用這個函數會出現報錯,這可能與設備相關;另外的設備異常就屬於物理硬件上的異常。

「關於WebRTC文檔上的關鍵事件,我們都會給予一定容錯,甚至有時候要多個接口一起協同使用,而不是對單一的接口做一些判斷,往往會存在不精準的現象。WebRTC的信令協商非常重要,取決於WebRTC網路連接或其他東西能不能正常使用,所以網路層的處理要格外精細,要考慮到丟包以及重連。」他說。

總體來說WebRTC文檔可以參考,應用過程中需要因地制宜,還是需要根據自己的業務需求發現其中的問題做一些解決。

那些典型的實時場景與後端架構,TA們都是怎麼做的?

概括了應用層面的彎與坑之後,大家都知道,HQ Trivia直播答題掀起了今年一波實時熱潮,瞬間高並發的特點給系統架構提出了「新難題」。

具體來說,在高並發場景下的實時狀態同步,包括PK、答題、或者大型直播間等,在消息丟失、消息延遲情況下如何做到消息實時狀態的同步呢?

關於這個問題,李慶壽似乎最有發言權,花椒直播在產品中的技術實踐更是值得探討。

通常來說,答題、連麥以及直播間的PK 活動都有可能帶來長連接的不穩定性。

試想瞬間增加服務器壓力,處理能力有限導致數據丟失延遲等情況出現,由此出現長連接異常,用戶體驗自然不高。

此外據了解,長連接的固有性質導致丟失或者亂序,開啟實時消息控制會導致它更加嚴重。此外,長連接超時狀態的判別延遲,其中超時比http這種接口請求的超時長得多,出現網路問題時不可能立馬斷線連接、重新建連,所以就出現了消息丟失和延遲問題。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

「我們當時考慮兩個方案,首先轉成IM消息,寫擴散,進行消息編號等功能。但這個功能評估下來對系統的改造非常大;另外就是定時拉取接口做實時狀態的同步,這個方案導致狀態接口的請求量非常大。所以最後根據這個思路設計了Sync服務。」李慶壽說。

具體操作第一步就是要增加ID的版本號,將Sync消息寫入現成連系統中,由長連系統推送到APP端,與此同時將帶有版本號的信息同步寫入到Sync中去。

作為APP端,要不就是網路特別好而且消息不是很多的情況下,正常接受消息可以展示出來;如果此時APP處於網路不穩定或者直播間消息眾多,那就輪到Sync服務發揮作用了。具體來說,APP會尋找Sync服務的相關接口,如果版本號大於本地的最大版本號,就會用這個版本信息做業務處理。

直播環節看似沒有坑了,那點播如何才能做的順當?

滬江CCtalk CTO 楊繼珩為現場開發者建議的解決方案是OCS。

這套系統是一套播放系統,可以理解為一個播放器,但它播的內容不像其他機構播一個視頻那麼簡單。

作為一個富媒體播放器,就是把上課所有元素按直播時一個個放完,機制很複雜,但可以讓錄播用戶得到更好的體驗和學習效果更好。OCS的結構也很複雜,包括OCS的後台生成器、平台服務層的轉碼、打包、數據切片、富媒體包裝等。

未來關於在線視頻教育的挑戰,楊繼珩認為這幾點比較關鍵,給同行人帶來些許建議。卡頓、低延遲優化的老生常談的話題之一;此外,一些大型課程學生在場率超過50%的並沒有很多,很多用戶都是看錄播,所以要保證MCU錄制質量一定要高,這方面能力的建設以及穩定性比較重要。

如今,8億-9億網民中有超過六成的使用者或多或少玩過遊戲,盡管從國家層面對其進行了相對嚴格的管控,但體量巨大帶來的影響仍然是不容小覷。

更重要的一點,遊戲對網路要求非常高。不像視頻或其他電商類業務對網路的帶寬、時延、抖動、丟包要求極致;常常玩FPS遊戲的人們了解,如果網路不好的話基本沒辦法進行下去,客戶體驗會非常差,再加上如今公有雲的網路基礎設施還相對薄弱,這也是華為雲遊戲解決方案架構師王冰關注遊戲網路質量優化的立足點。

王冰表示,將數據采集完成進行分析、網路預測,去動態調整網路流量流向等環節確實很關鍵,但更重要的一點,還是要對網路質量整體提升。

「網路出問題後,最終要改善網路,而不是總去預防,要總結、分析後對網路能力進行提升。例如可以從數據中心建設、骨幹網的帶寬和ISP帶寬、POP點廣泛覆蓋、線路質量的提升、跨地域線路容災能力以及IPV6的快速推廣等方面著手。」他說。

從技術層面出發,隨著RTC技術在更多行業的應用落地,不斷迸發出更多創新業務場景,後端架構設計與傳輸也將時刻面臨新的挑戰。

小到教育畫面的卡頓,大到工單以及客戶系統的諸多問題, 聲網Agora 首席數據架構師何豐作為RTC 大會的老朋友,這次帶來了針對「質量透明」的主題分享。

WebRTC、標準測試、大前端技術、實時網路質量……RTC2018幫你「劃重點」!

在分享中,何豐強調,需要把服務質量透明給用戶,質量透明以後用戶可以了解事態;此外可以有效幫助定性是網路問題還是設備陳舊問題,對質量改進形成非常快速的迭代。

具體來說,聲網關於這方面的實踐,主要是通過內部的工具和系統把這些問題定位診斷出來,因為有一套非常完善的質量數據體系。

這個數據的體系會從用戶通話的每一個環節針對質量收集, 例如用戶行為、網路切換、音視頻采集、上行網路丟包、抖動、延遲等質量數據。

話說,中間的雲作為傳輸大網,能夠保障跨州、跨國傳輸的質量。大網中傳輸的質量指標、對方用戶下行網路、對方接收解碼播放渲染的運行狀態……這些用戶行為都會被全鏈路收集起來。

何豐進一步補充道,這些收集到的數據還可以做些分類,例如用戶行為一類,運行時狀態為一類,以及QoE和QoS兩方面的質量數據等。這代表可以通過全方面數據去判斷通話的相關情況,脫離用戶訪談就可以對通話質量進行全方位把控。此外,會上Callstack.ioCEOVarunSigh還帶來了有關WebRTC領域質量監控和優化的經驗分享。

如今,實時互聯網行業迎來爆發之年,很多創新的實時互動場景在RTC技術的激發下踏上風口,關於RTC 2018大會的相關報導後續會接踵而至,敬請期待。