“WebRTC 預計將以 34.37% 的復合年增長率增長，到 2031 年市場價值將超過 3000 億美元”

近年來，許多企業(yè)開始在網(wǎng)上開展業(yè)務(wù)。他們使用視頻聊天軟件APP作為與客戶和其他企業(yè)聯(lián)系的重要工具。

如果您是這樣的企業(yè)或個人，希望創(chuàng)建視頻聊天軟件APP，那么本文適合您。在本文中，我將引導您完成使用 JavaScript 和 WebRTC 點對點連接創(chuàng)建視頻聊天軟件APP的步驟。

讓我們開始吧！

什么是WebRTC？

WebRTC 是一個在瀏覽器中啟用實時通信 (RTC) 功能的框架。它允許在沒有任何服務(wù)器的情況下進行點對點通信。它允許客戶端之間直接交換音頻、視頻和聊天數(shù)據(jù)。

為什么將 WebRTC 用于通信軟件APP？

人們使用 Whatsapp、Signal 和 Telegram 等流行的聊天軟件APP進行業(yè)務(wù)溝通。但專用的電子會議軟件APP與簡單的聊天系統(tǒng)在不同方面有所不同。

要為您的企業(yè)開發(fā)這樣的軟件APP，首先您需要了解視頻聊天的工作原理。

讓我用一個簡單的例子來解釋這一點。想象一下您正在開發(fā)一個網(wǎng)絡(luò)視頻聊天軟件APP?，F(xiàn)在，您需要 2 個瀏覽器（客戶端）——一個調(diào)用者和一個被調(diào)用者。要連接呼叫者和被呼叫者設(shè)備，您需要中間有一個服務(wù)器。該服務(wù)器將負責在兩個瀏覽器之間交換消息。

一般來說，這是很耗時的。這意味著，視頻/語音數(shù)據(jù)必須從呼叫者客戶端傳輸?shù)椒?wù)器。然后服務(wù)器必須將數(shù)據(jù)傳遞給被調(diào)用者客戶端。這是一個漫長的過程，并且您的語音和視頻有很大的機會出現(xiàn)延遲。

想象一下您的用戶在您的軟件APP上遇到口吃和結(jié)巴的情況。不受歡迎吧？

如果我們刪除服務(wù)器并直接連接瀏覽器會怎么樣？

這正是 WebRTC 在實時視頻通話中所做的事情。

WebRTC 是一種無需服務(wù)器即可連接客戶端軟件APP的技術(shù)。

對于WebRTC，服務(wù)器的作用非常有限。這意味著，它支持兩個瀏覽器相互發(fā)現(xiàn)并直接連接。

那么，您可以在沒有 WebRTC 的情況下開發(fā)網(wǎng)絡(luò)視頻軟件APP嗎？是的，但您可能會面臨以下典型問題：

• 連接中斷

• 數(shù)據(jù)丟失

• NAT穿越

• 回聲消除

• 動態(tài)抖動緩沖

• 自動增益控制

• 降噪和抑制

• 帶寬適應(yīng)性

總的來說，當您使用 WebRTC 進行視頻通話時，您可以消除這些問題。此外，這項技術(shù)甚至不需要任何插件或第三方軟件。此外，作為開源項目，其所有源代碼均可在https://webrtc.org/免費獲取

此外，所有主流瀏覽器（如 Firefox、Bing 和 Chrome）都支持 WebRTC。

注意：開始之前請檢查 WebRTC視頻通話 API的兼容性。

現(xiàn)在，廢話不多說，讓我們詳細了解一下。

WebRTC 在軟件APP開發(fā)中的好處

如果您計劃在沒有服務(wù)器的情況下將實時通信功能開發(fā)到您的軟件APP中，WebRTC 是一種理想的技術(shù)。您可以輕松地將以下交互功能開發(fā)到您的軟件APP中：

• 文字通訊：

這使得用戶可以在所有支持 Webrtc 音頻和視頻的 iOS/Android 聊天軟件APP上通過文本進行實時聊天體驗。

• 語音通訊：

基于 IP 語音技術(shù)，通過互聯(lián)網(wǎng)實時聊天軟件APP。低延遲可在所有設(shè)備上建立一對一或一對多的 WebRTC語音聊天軟件APP連接。

• 視頻通訊：

視頻連接有助于在 Android/iOS 聊天軟件APP上以低延遲持續(xù)進行高質(zhì)量的支持 WebRTC 的視頻和音頻通話。 

WebRTC：詳細探索該技術(shù)

WebRTC 兼容平臺

• 桌面：

• Chrome、火狐、Opera

• 移動的：

• 安卓和iOS支持

WebRTC 的功能依賴

在開始開發(fā)實時WebRTC 視頻聊天軟件APP之前，讓我們先明確一下用于開發(fā) WebRTC Android/iOS 和網(wǎng)絡(luò)聊天軟件APP的功能依賴關(guān)系。

• 完善的 WebRTC 庫

每個希望使用WebRTC API為 Android、iOS 或 Web 瀏覽器開發(fā)聊天軟件APP的開發(fā)人員都需要一個完整的WebRTC 點對點本機代碼包。

• jQuery

jQuery 用于處理事件操作，并通過可在多種瀏覽器上運行的易于使用的 API 來簡化 HTML。

• 語義 UI CSS：

一個框架，用于通過人性化的 HTML 和優(yōu)雅的 CSS 框架設(shè)計響應(yīng)式布局，致力于美化聊天平臺的用戶體驗。

• 車把

兼容的模板提供了用 HTML 語言開發(fā)語義模板的潛在能力。這給移動設(shè)備帶來了重大變化，在 Android 和 iOS 平臺上嵌入了簡單的 WebRTC 消息傳遞功能。

WebRTC 中的 API 和對象 

除了依賴項之外，開發(fā)支持 WebRTC 的視頻和語音通話的聊天軟件APP還需要多個框架和功能。

下面提到的是WebRTC中的API和對象：

• WebRTC 中的 API

• getUserMedia()：這是一個 WebRTC API。您可以在 JavaScript 代碼中調(diào)用該方法來請求訪問用戶的攝像頭和麥克風。

• WebRTC 中使用的對象

• MediaRecorder：這是您在 JavaScript 代碼中創(chuàng)建的對象。它用于記錄媒體流，例如音頻和視頻，您可以通過 getUserMedia() API 獲取這些媒體流。

• RTCPeerConnection：這也是您在 JavaScript 代碼中創(chuàng)建的對象。它負責管理對等連接并處理對等點之間的媒體流協(xié)商。

• RTCDataChannel：這是您創(chuàng)建的一個對象，用于在對等點之間建立數(shù)據(jù)通道以傳輸任意數(shù)據(jù)。

探索 WebRTC 基礎(chǔ)設(shè)施

最初，視頻和語音通話功能都依賴于相互連接的兩個客戶端服務(wù)器之間的流媒體。 

互聯(lián)網(wǎng)語音協(xié)議 (VoIP) 是網(wǎng)絡(luò)語音和實時視頻聊天軟件APP最熟悉和最值得信賴的標準技術(shù)之一。

聊天應(yīng)用的視頻/音頻傳輸

正如我們非常清楚的那樣，WebRTC 是將流媒體內(nèi)容從一個客戶端服務(wù)器傳輸?shù)搅硪粋€客戶端服務(wù)器的重要實現(xiàn)。

• 信令

• STUN服務(wù)器

• TURN服務(wù)器

我們來看看細節(jié)：

發(fā)出“連接模式”信號

信令是最重要的概念之一，其中在通信之前，兩個對等方必須知道彼此的信息才能進行連接。這些信息包括，

• 有關(guān)任何其他通信對等點是否存在的更新

• 網(wǎng)絡(luò)數(shù)據(jù)，例如對等方的 IP 地址和端口

• 會話控制消息 – 用于打開和結(jié)束通信

• 錯誤信息

• 媒體元數(shù)據(jù)，包括編解碼器、編解碼器設(shè)置、頻段。

• 寬度和媒體類型

• 安全連接所需的關(guān)鍵數(shù)據(jù)

此信息稱為元數(shù)據(jù)，是發(fā)生任何直接連接所必需的。對于發(fā)出信號來說，服務(wù)器的可用性是必須的。

信令啟動兩個瀏覽器之間的初始通信。在此過程中，對等體交換有關(guān)其他對等體的信息。一旦共享這些數(shù)據(jù)，它就會在對等點之間創(chuàng)建直接連接。該信令機制一直使用到建立直接連接為止。

會話描述協(xié)議

這是一種描述用于公告和邀請的多媒體通信會話的格式。它支持包括VoIP和視頻會議在內(nèi)的流媒體應(yīng)用。這里，WebRTC沒有規(guī)定信令方法和協(xié)議。我們必須自己建造它。

眾所周知，WebRTC 需要兩個對等方作為提供者和應(yīng)答者來進行數(shù)據(jù)交換；通信需要這些會話描述協(xié)議 (SDP) 格式。

會話描述協(xié)議格式如下所示：

• v=0

• o=- 7614219274584779017 2 輸入 IP4 127.0.0.1

• s=-

• t=0 0

• a=組：捆綁音頻視頻

• a=msid-語義：WMS

• m=音頻 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126

• c=IP4 0.0.0.0

WebRTC 根據(jù)您設(shè)備上的音頻/視頻自動創(chuàng)建上述代碼。

現(xiàn)在，讓我們繼續(xù)了解它們?nèi)绾螀f(xié)同工作。

WebRTC 如何在您的軟件APP中工作？

在開始該過程之前，最好了解一些有關(guān) IP 地址和端口的知識。

IP 地址是連接到互聯(lián)網(wǎng)的每個設(shè)備的標識號。而端口號指定了互聯(lián)網(wǎng)或其他網(wǎng)絡(luò)消息從一端轉(zhuǎn)發(fā)到另一端的過程。

此外，主要使用端口號，以便將數(shù)據(jù)定向到設(shè)備內(nèi)的當前位置。然而，一般來說，連接到互聯(lián)網(wǎng)的每個設(shè)備都有一個 IP 地址和端口，通常為 65,536。

從工作流程和 API 開始：

這些RTCPeerConnection API 和信令都是關(guān)于提供、應(yīng)答和候選。我們來詳細看看

您可以使用RTCPeerConnection API 在用戶之間傳輸音頻和視頻。該信令與RTCPeerConnection一起工作。它在瀏覽器之間建立直接連接。

接下來我們看一下RTCPeerConnection的整個流程是如何進行的。首先，這個過程涉及兩個步驟，

元數(shù)據(jù)的使用——獲取本地視音頻媒體條件即通過信令發(fā)送數(shù)據(jù)

另一種是獲取潛在的網(wǎng)絡(luò)地址來托管軟件APP。

當您獲得分辨率和編解碼器功能等元數(shù)據(jù)時，信令機制會在遠程服務(wù)器之間交換它們。

讓我們通過一個例子來理解這個場景。例如，假設(shè)有兩個用戶“X”和“Y”。

如果假設(shè) X 呼叫 Y – 那么在媒體條件下有可能發(fā)生以下步驟：

一旦確定了本地語音和視頻數(shù)據(jù)（例如分辨率和編解碼器功能），就應(yīng)該使用遠程瀏覽器與信令機制進行交換。

讓我們通過一個例子來理解這個場景。例如，假設(shè)有兩個用戶“X”和“Y”。如果假設(shè) X 呼叫 Y – 那么當他們共享信息時，在媒體條件下有可能發(fā)生以下步驟，

• X 將創(chuàng)建RTCPeerConnection對象

• X 將使用RTCPeerConnection createoffer()方法創(chuàng)建報價

• 現(xiàn)在，X調(diào)用setLocalDescription()將創(chuàng)建的offer設(shè)置為本地媒體的描述 

• 然后X使用信令機制提出報價并將其發(fā)送給Y

• Y 調(diào)用setRemoteDescription()并提供 X 的報價，以便他的RTCPeerConnection可以了解所有 X 的設(shè)置

現(xiàn)在，Y根據(jù) X 的數(shù)據(jù)調(diào)用createAnswer() 。因此，成功回調(diào)函數(shù)是用 Y 的答案生成的

• Y 通過調(diào)用setLocalDescription()將 X 的答案設(shè)置為本地描述

• 然后Y使用信號機制通過信號向她發(fā)送答案

• X 使用setRemoteDescription將 Y 的答案設(shè)置為遠程會話描述

現(xiàn)在，X 和 Y 也將交換網(wǎng)絡(luò)信息。這里，“尋找候選者”使用ICE框架來識別網(wǎng)絡(luò)接口和端口。

完成上述所有過程后，X 將創(chuàng)建一個帶有onIcecandidate處理程序的RTCPeerConnection對象

僅當候選網(wǎng)絡(luò)可用時才會調(diào)用此處理程序

在處理程序中，X通過其信號機制向 Y發(fā)送信號候選數(shù)據(jù)

當 Y 從 X 收到候選消息時，Y 將調(diào)用addIceCandidate()將候選者添加到遠程對等點描述中

WebRTC 支持ICE 候選滴注。這意味著，呼叫者一旦提出初始報價，就會向候選人提供被呼叫者。因此，被叫方可以自動開始呼叫并建立連接，而無需等待其他候選人到達。

總的來說，需要注意的一點是，一旦創(chuàng)建報價，WebRTC 就會自動創(chuàng)建 ICE 候選人。因此，我們應(yīng)該實現(xiàn)通過信令接收和發(fā)送這些候選者所需的方法。

一旦有關(guān)媒體條件和 ICE 候選者的信息在兩個對等點之間共享，WebRTC 就會自動在兩個對等點之間創(chuàng)建直接連接，以進行任何視頻聊天或其他對話。

完成信令 — 引入 ICE 來應(yīng)對 NAT 和防火墻

使用唯一的 IP 地址和端口號獲取用于視頻聊天的WebRTC連接，并在對等方之間交換它們以直接通信，可能聽起來很簡單，但要困難得多。這是由于兩個因素可能導致這里出現(xiàn)問題。因此，在使用任何網(wǎng)絡(luò)視頻會議軟件APP之前處理這些問題至關(guān)重要。

讓我們檢查這兩個導致問題/因素，

1）網(wǎng)絡(luò)地址轉(zhuǎn)換

網(wǎng)絡(luò)地址轉(zhuǎn)換 (NAT) 是將一個或多個本地 IP 地址轉(zhuǎn)換為一個或多個全局 IP 地址的過程，目的是為本地主機提供 Internet 訪問。

好吧，我們都知道它是標識互聯(lián)網(wǎng)上設(shè)備連接的地址。因此，每個人都認為所有設(shè)備都會有一個唯一的 IP 地址，但事實并非如此。

一般來說，IPv4 地址的長度為 32 位，這表明總共大約有 40 億個唯一地址 (232 = 4,294,967,296) 可用。但研究發(fā)現(xiàn)，僅 2018 年就有約 220 億臺設(shè)備連接到互聯(lián)網(wǎng)。

現(xiàn)在，您可能會想這怎么可能？ – 當只有 40 億個可能的唯一地址可用時，為什么 220 億臺設(shè)備可以連接到互聯(lián)網(wǎng)？正確的！

對此，答案是“NAT”。

在這里，當這些 IP 地址分為兩類時，整個故事發(fā)生了轉(zhuǎn)變：公共 IP 地址和私有 IP 地址。

現(xiàn)在，公共IP地址只能分配給一臺設(shè)備，而私有IP地址則不然。 NAT 的理念是為多個設(shè)備提供通過單個公共地址訪問互聯(lián)網(wǎng)的能力。

因此，這表明每個設(shè)備將僅擁有有關(guān)其私有 IP 地址的信息，而不是有關(guān)路由器的公共 IP 地址的信息。此外，在 Google 搜索期間，Google 也會跟蹤并僅告訴您路由器的公共 IP 地址。

因此，我們可以說每個設(shè)備都有兩個 IP 地址，既是私有 IP 地址，也是公共 IP 地址。在這種情況下，網(wǎng)絡(luò)候選僅包含有關(guān)設(shè)備的私有 IP 地址的詳細信息。它根本不知道公共 IP 地址。所以，現(xiàn)在我們需要找到一種方法讓瀏覽器知道公共IP地址，以便候選人創(chuàng)建公共IP地址。

此后，使用 STUN（NAT 會話遍歷實用程序）服務(wù)器。在這里，當設(shè)備向 STUN 服務(wù)器發(fā)出請求時，STUN 將回復一條消息。它包含路由器的公共IP并幫助瀏覽器生成候選者。

2）防火墻

防火墻是一種網(wǎng)絡(luò)安全設(shè)備，用于監(jiān)視傳入和傳出的網(wǎng)絡(luò)流量。它還決定是否需要允許或阻止特定流量，所有這些都取決于定義的安全協(xié)議集。

現(xiàn)在，讓我們看看這個防火墻如何在 WebRTC 方面造成問題。

好吧，為了解決這里的防火墻問題，我們需要利用 TURN（使用中繼 NAT 遍歷）服務(wù)器。當直接對等連接失敗時，TURN 服務(wù)器直接在兩個瀏覽器或?qū)Φ赛c之間中繼流量。

現(xiàn)在我們知道，這些 STUN 和 TURN 服務(wù)器用于使用 WebRTC 進行點對點連接。我們可以將 TURN/STUN 與WebRTC 視頻聊天軟件APP集成，只需將包含 TURN 和 STUN 服務(wù)器 URL 的對象傳遞給RTCPeerConnection作為其參數(shù)即可。

讓我們用編碼來進行說明，以便更好地理解整個概念。

WebRTC 編碼示例

在上面的示例中，我們必須單獨傳遞 URL，其余的事情將由 WebRTC 管理。

查看插圖，其中包含使用 Javascript 和 WebRTC 技術(shù)進行實時視頻通話期間建立的所有連接。

但在整個過程中，也有一些需要注意的地方。這包括，

使用 STUN 服務(wù)器成功連接而不需要 TURN 是很常見的。但有時，TURN服務(wù)器也用于撥打電話

XirSys 等一些組織免費提供 TURN 和 STUN 服務(wù)器

這是開發(fā) JavaScript 視頻聊天軟件APP的步驟的開始。但在實施方面還有很多值得探索的地方。我們將在未來的博客中對其進行研究，因此請保持警惕并了解更多信息。