2017 已過大半，從年初盛起的《王者榮耀》、《狼人殺》卻依然是火爆的游戲產品，其共同特性都在于集成了實時語音功能，前者左手走位右手技能，語音自然也就成為了非常必要的屬性，而后者更不用說，本就是純粹依靠實時語音進行下去的游戲。
而從游戲到直播、在線教育/醫療以及 VR/AR、AI 等互聯網垂直行業及創新技術，這樣的例子還有很多。比如轉型做直播的陌陌在新的 8.0 版本中推出了“快聊”、“狼人殺”、“派對”等實時視頻社交玩法；小米在新發布智能音箱中也集成了實時語音云服務。隨著互聯網服務越來越廉價易得，諸如網絡電話、視頻通話、全互動直播等實時場景已然成為用戶的普遍需求，越來越多的規模化應用基于使用模式及場景集成了實時音視頻功能，“實時”儼然已是互聯網熱的標簽詞之一。
但實際上，始建于上世紀 60 年代的互聯網本身并非為“實時”所設計，受限于當時的應用場景和技術，再加上不同國家、運營商之間人為制造的屏障，通信技術在實時傳輸、質量保證等各方面都可謂差強人意。
也正因如此，從互聯網誕生之日起，一代又一代的技術人便在對通信技術進行不斷地更新升級。1989年，還在歐洲粒子研究中心（CERN）的 Tim Berners-Lee 研制出了三項突破性的數字通信技術：可用于排列文本文件的 HTML 語言、連接文件的 HTTP 系統以及用來對特殊節點信息進行定位的 URL。這三項創新改變了整個通信系統，使得信息能夠更容易地穿越計算機網絡。而在1993年，Berners-Lee 更是建立起萬維網聯盟（World Wide Web Consortium，簡稱 W3C），負責 Web 相關標準的制定。瀏覽器的普及和 W3C 的推動，使得 Web 上可以訪問的資源逐漸豐富起來，然而此時 Web 的主要通信還是瀏覽器向服務器請求靜態 HTML 信息。
不過，同在 1993 年，CGI（Common Gateway Interface，通用網關接口）的出現帶動了 Web 上動態信息服務的蓬勃興起。CGI 定義了 Web 服務器與外部應用程序之間的通信接口標準，Web 服務器可以通過 CGI 執行外部程序，讓外部程序根據 Web 請求內容生成動態的內容。
到了 1995 年，NetScape 公司設計的 JavaScript 被用作瀏覽器上運行腳本語言為網頁增加動態性，不僅能夠做出非常酷的頁面動態效果，還可以減少與服務器端的通信開銷，而十年后，也就是 2005 年，當 Google 的崛起掀開了 Web 2.0 的大幕，應運而生的 AJAX 更使得javascript 再次大放異彩。
我們知道，在 Web 應用中，用戶提交表單時就向 Web 服務器發送一個請求，服務器進行接收處理，并返回一個新的網頁，前后兩個頁面中的大部分 HTML 代碼往往是一樣的，由此也就造成了返回時帶寬資源的浪費。而 AJAX 應用僅向服務器發送并返回必要的數據，且在客戶端采用 JavaScript 處理來自服務器的響應，更新頁面的局部信息。這樣不僅讓瀏覽器和服務器的數據交換大大減少，且客戶端也可以更快速地響應用戶操作。
而到了移動互聯網時代，通信技術標準化也就成為了水到渠成的自然現象。在《蘋果終于入伙 WebRTC，新一代移動 Web 應用爆發路上還有哪些坑？》一文中，我們曾談到的 WebRTC 標準便是典型案例之一。
在 2011 年以前，瀏覽器之間要想實現實時通信，需要私有技術，其中大部分都是通過插件和客戶端來安裝使用。對于許多用戶而言，插件的下載、安裝和更新是一個復雜、繁瑣和容易出錯的操作。而對于開發人員來說，插件的調試、測試、部署、錯誤修復和維護同樣困難重重，且不提還涉及到一些受版權保護的技術，整合相當復雜。再者，很多時候，服務提供商很難說服用戶去安裝插件。
但這一兩頭吃力還不討好的局面就這樣被 Google 將 WebRTC 項目開源所打破。2011 年，WebRTC 基于 BSD 協議開源，同年，W3C 啟動 WebRTC 計劃，讓 WebRTC 成為了 HTML5 標準的一部分（目前，該規范還在開發中）。
另一方面，在移動互聯網創業大潮涌動之時，不少創業者選擇從移動 SDK 切入，將實時通信工具化，開發者及團隊無需顧及實時通信背后繁瑣的技術原理與邏輯實現，只需在應用開發中集成相應的 SDK 即可輕松實現實時通信功能。這方面的代表性企業可見聲網 Agora.io，其提供了一個極簡 SDK，讓開發者接入 SD-RTN? 實時虛擬通信網，在任何 App 和網站實現高質量的音頻通話、視頻通話、全互動直播。
同時，隨著網絡基礎設施到位、硬件配件發展成熟，以及 4G、Wi-Fi 的普及，用戶開始對更豐富的功能、場景有了更多的需求。譬如在當前人工智能如火如荼之時，諸多智能設備都集成了實時音視頻的功能，前文提到的小米 AI 音箱即是其中之一。
對此，聲網 Agora.io CEO 趙斌如此總結道：
中國互聯網發展迅猛，基礎云服務、開源技術、html5、移動 SDK 等技術，讓中國的開發者能快速地開發移動和網頁 App，與世界比肩。下一個風口，一定會是融合了實時通信技術的應用。
接下來，我們進行具體分析。
網絡傳輸：現存的互聯網作為冷戰時代的產物早其實是為了用于保障美國通信網絡，其在網絡傳輸方面的種種局限也直接導致了現在的互聯網在大文件傳輸、實時傳輸方面的窒礙難行。而語/視頻通信、直播連麥對實時性要求非常高，要求延遲低至幾百毫秒，因此，現存的互聯網并不能滿足這種新型的實時應用場景。
編解碼：傳統的編解碼算法，也非應用于復雜的互聯網實時場景的良選，就導致卡頓、模糊等不可用的情況發生。
硬件適配：在音視頻通話中，除了延遲，還有一個嚴重影響用戶體驗的問題 —— 回聲。所謂“回聲”，即是指自己的聲音傳到遠端再通過遠端的麥克風錄音傳回來。我們需要通過信號處理算法來進行回聲消除，但由于手機的音量控制是非線性的，不同的手機材質、手機殼會導致聲音傳導性有差異，設備種類差異導致算法不能普適。且Android 手機碎片化嚴重，也就直接導致了移動端適配工作量龐雜。
QoE 質量保障： 來自北歐的實時通信數據測試公司 Callstats.io 曾分享過歐美市場實時通信行業現狀的調研數據，基于公網的 WebRTC 通話中有 16% 通話質量不可接受。而實際情況中，類似東南亞、中東這些基建不發達地區會糟糕得多。如何保障 RTC 服務的高連通性、高質量，也就成為了 RTC 領域的一大技術難點。
RTC 從功能流程上來講，包含了采集、編碼、前后處理、傳輸、解碼、緩沖、渲染等諸多環節，下圖是一個 RTC 通信的粗略流程，每一個細分環節還有更細分的技術模塊。比如在前后處理環節，有美顏、濾鏡、回聲消除、噪聲抑制等，采集有麥克風陣列等，編解碼有 VP8、VP9、H.264 等。
在這里，來自聲網的技術專家分享了他們的實踐：
值得一提的還有，不少開發者直接將 RTC 和 WebRTC 劃上了等號。實際上，WebRTC 是 Google 的一個專門針對網頁實時通信的標準及開源項目，只提供了基礎的前端功能實現，包括編碼解碼和抖動緩沖等，開發者若要基于 WebRTC 開發商用項目，需要自行做服務端實現和部署，信令前后端選型實現部署，以及手機適配等一系列具體工作。除此之外，還要在可用性和高質量方面進行大量的改進和打磨，對自身開發能力的門檻要求非常高。而一個專業的 RTC 技術服務系統，除了涵蓋上述的通信環節外，實際上還需要有解決互聯網不穩定性的專用通信網絡，以及針對互聯網信道的高容忍度的音視頻信號處理算法。當然，常規云服務的高可用、服務質量的保障和監控維護工具都只能算是一個專業服務商的基本模塊。
當各式智能硬件、移動應用以及 Web App 中的許多模塊都越來越依賴于音視頻技術，實時通信已然成為了所有行業的一大基礎設施，不僅僅是在直播、游戲這些泛娛樂行業，更滲透到在線醫療、教育、金融等領域。在不同場景下，推動著人們溝通互動方式的改變。
但是，就是這樣一個已與各個垂直行業進行深度融合需求龐大的技術領域，卻仍然匱乏核心技術高端人才。RTC 核心技術需求的是通信工程相關專業的人才，而這些專業的應屆畢業生此前就業一般集中于華為、愛立信等傳統通信行業廠商，也不具有 RTC 的經驗，一般都是工作后二次學習。開發者需要對實時通信有更深層次的理解，建立起 RTC 技術體系，幫助自己在各個行業開拓創新的可能。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
