1、前言

---

近幾年實時音視頻通信應用呈現出了大爆發的趨勢。在這些實時通信技術的背后，有一項不得不提的技術——WebRTC。

今年 1 月，WebRTC 被 W3C 和 IETF 發布為正式標準。據調研機構 GrandViewReseach 的報告顯示，預計 2025 年全球 WebRTC 市場規模將達到 210.23 億美元，相較 2019 年 23 億美元的市場規模，5 年的復合年增長率為 43.6％。

本系列內容將和大家一起來探討，為什么 WebRTC 受到開發者及企業的青睞 ？未來 WebRTC 又將如何發展？以及聲網Agora 是怎樣基于 WebRTC 進行二次開發，又將如何支持 WebRTC NV 版本的？

---

在線會議、在線教育、在線面試、在線社交、在線醫療、金融證券在線開戶、智能家居等等已經成為了現代人們生活中非常熟悉的一部分，將常見的線下場景轉至線上，人們足不出戶便能體驗上述場景。這些實時互動場景在很大程度上已經改變了我們原本的生活方式。

如果我們將時間倒回到 10 年前，也就是在 4G 即將商用的時候，幾乎所有的媒體和技術都在強調 4G 可以看高清視頻，但多數都聚焦在討論手機看視頻有多么的方便，沒有人預測到短視頻的徹底爆發；多數人都知道 4G 的上傳速度可以視頻直播了，但當時的設想更多的是應用于專業的新聞領域，沒有想到這個全民皆可直播的時代的來臨；對于視頻會議的設想也大多停留在跨國辦公的需求上，但沒想到就在去年，線上辦公幾乎成為了每一位上班族的日常。

在這十年間，實時互動場景的日常化又是如何一步一步實現的呢？

從 2010 年左右，實時通信只能使用專有軟件、插件或Adobe Flash進行實時通信；2013年，Chrome 和 Firefox 之間進行了首次跨瀏覽器視頻通話；2014年，第一次跨瀏覽器數據傳輸得以實現，通過客戶端進行實時通信打開了一個新興的趨勢......而今天，它被稱為WebRTC，我們每天都在 Chrome，Mozilla Firefox，Opera，Safari，Edge，iOS 和 Android 的實時互動場景中使用它。

2、什么是 WebRTC

---

WebRTC 是一個由 Google、Mozilla、Opera 等發起的開源項目，名稱源自網頁即時通信（Web Real-Time Communication）的縮寫。因此，不難看出這項技術最開始的目標是希望為實現自由地在瀏覽器上進行實時音視頻傳輸做準備的。

“其實 WebRTC 在不同場景下包含不同的含義，它既可以代表 Google 開源的 WebRTC 項目，又可以代表 W3C（World Wide Web Consortium-萬維網聯盟） 工作組制定的 WebRTC 標準，也可以代表瀏覽器中的 WebRTC 接口，我們將他們統稱為 WebRTC 技術。”【1】多數時候，對于開發者而言 WebRTC 是一套支持網頁瀏覽器進行實時音視頻對話的 W3C Javascript API，它包括了音視頻的采集、編解碼、網絡傳輸、顯示等功能。

由于幾乎所有主流瀏覽器都支持 WebRTC 標準 API ，因此也讓瀏覽器之間無插件化的音視頻互通成為可能， 大大降低了音視頻開發的門檻，開發者只需要調用 WebRTC API 即可快速構建出音視頻應用。

3、開發者為什么喜歡使用 WebRTC

---

“WebRTC 的使命是使豐富、高質量的 RTC 應用程序能夠為瀏覽器、移動平臺和 IoT 設備開發，并允許所有人通過一組通用協議進行通信。”

3.1WebRTC 解決了什么問題？

---

在沒有 WebRTC 前，對于開發者而言 RTC 通信的難點主要來自于互聯網網絡復雜、延時敏感、實時音視頻流暢度及清晰度較低以及運營成本較高等。但這些問題在 WebRTC 出現后都得到了較好的解決：

3.1.1互聯網網絡復雜

不同的 NAT、防火墻對媒體 P2P 的建立帶來了很大的挑戰。而 WebRTC 的出現為瀏覽器提供了端到端的直接通信，使開發者可以輕松地實現這種連接。同時，WebRTC 里面有 P2P 打洞的開源項目 libjingle ,支持 STUN，TURN 等協議。

3.1.2延時敏感

在早期的 RTC 技術中，TCP（Transmission Control Protocol-傳輸控制協議）由于自身機制的缺陷，只能使用 UDP 傳輸，但這需要開發人員解決重傳、亂序等問題。而 WebRTC 則提供了 NACK，FEC 技術，不再需要通過服務器進行路由，減少了延遲和帶寬消耗。直接通信可提高數據傳輸和文件共享的速度。

3.1.3流暢性

互聯網網絡不穩定，特別一些小運營商，在流量使用高峰期往往無法保證足夠的帶寬。需要一套自適應的算法來應對網絡擁塞、平滑發送等問題。WebRTC 中提供了 TCC + SVC + PACER + JitterBuffer 技術支持。

3.1.4語音清晰

由于終端設備和環境復雜，會有噪聲、回聲的干擾，這時候 WebRTC 提供了 3A 算法 + NetEQ，讓實時環境中的聲音處理及互動體驗得到了大幅的提升。

對于開發人員或企業而言，使用 WebRTC 的過程中只需要下載兼容 WebRTC 的瀏覽器并使用，不需要額外的軟件、插件或持續的服務器的參與就可以將音視頻應用輕松嵌入到任何網站中，并通過 Internet 進行連接，大大節省了開發時間和成本。

目前主流的瀏覽器如 Microsoft Edge、Google Chrome、Mozilla Firefox、Safari、Safari、Opera、Vivaldi 等都已支持 WebRTC。

3.2使用 WebRTC 安全嗎？

---

WebRTC 作為一項開源技術，可在任何 Web 瀏覽器上免費使用，并且不受插件限制。那么，這時候可能有人會問，使用 WebRTC 安全嗎？使用 WebRTC 會不會有惡意訪問我的用戶數據或者專用網絡的情況出現？

放心吧，在安全方面，WebRTC同樣做了優化設計：所有 WebRTC 媒體數據都必須經過加密。

由于 WebRTC 并非是一個插件，也不用安裝別的插件，因此所有應用都可以在瀏覽器的沙箱中運行，并不用再額外創建新進程。也正因為如此， WebRTC 有效地阻止了惡意軟件進入用戶系統。在任何實時通信應用程序中，數據傳輸的過程都有可能會增加安全風險，因此加密是WebRTC 的強制性功能，并在所有媒體數據上強制執行。【2】

3.2.1WebRTC使用兩種標準化的加密協議：

• 數據報傳輸層安全性（DTLS）

• 瀏覽器中內置的標準化協議。是基于傳輸層協議（TLP）的數據流加密；

• 由于 DTLS 使用用戶數據協議（UDP），因此保留了傳輸的語義；

• 它是安全套接字層（SSL）的擴展，任何 SSL 協議均可用于保護 WebRTC 數據，從而允許端到端加密。

3.2.2安全實時傳輸協議（SRTP）

• 用于媒體流加密；

• 它是對實時傳輸協議（RTP）的擴展，該協議沒有任何內置的安全性機制；

• 為實時傳輸協議（RTP） 提供加密、完整性保證和消息身份驗證。

（* 但 SRTP 協議也有它的一些缺點，比如雖然它為 RTP 數據包提供加密，但不對標頭進行加密。）

在我們日常使用網絡下載應用程序、電影或者通過郵件傳輸信息/文件的過程中，其實都有可能會存在惡意入侵的風險。但是，WebRTC 技術通過上述標準，可以有效保護敏感數據的傳輸，為安全的實時通信環境提供保障。

4、WebRTC 可以直接食用？

---

WebRTC 是互聯網行業在實時通信方面影響深遠的一項努力，大幅降低了開發人員實現實時音視頻通信功能的門檻。那我是不是有了好的想法，就可以直接使用 WebRTC 來進行開發并商用了呢？（搓手😄...）很遺憾，答案是否定的。

由于 WebRTC 的傳輸是基于公共互聯網，而公共互聯網并不是為了實時通信而設計的，因此在網絡協議、跨區域帶寬、跨運營商、用戶設備、網絡架構、文檔支持等方面都會對 WebRTC 的開發有牽制，從而會導致實時音視頻等傳輸質量沒辦法得到有效的保證。

關于 WebRTC 的優缺點詳情可參考：WebRTC現狀及優缺點，音視頻通信必看的開源項目

因此，可以說如果 WebRTC 直接拿過來商用的話，幾乎是不太可能的，當下普遍的解決方案是自研，根據自身的業務場景進行二次定制開發，或者更簡單一點使用第三方 SDK。（Agora WebSDK 是基于 WebRTC 封裝的API集合，極致簡單，對開發者更加友好，能十行之內完成一個簡單的 demo 并上線。點擊【查看詳情】）

關于 WebRTC 如何進行二次定制開發以及 WebRTC 的最佳實踐內容，我們會在本系列后續內容中與大家分享。

原文鏈接：https://juejin.cn/post/6963914794470473764

★文末名片可以免費領取音視頻開發學習資料，內容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音視頻學習路線圖等等。

見下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

總結

以上是生活随笔為你收集整理的Why WebRTC｜前世今生的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。