WebRTC由很多模塊構(gòu)成。你想了解它的工作原理嗎？

WebRTC工作起來就像施魔法一樣。你將瀏覽器指向一個URL，讓其他人也將他的瀏覽器指向一個URL，然后，你們就能看到彼此了。是不是很酷？

如果你了解WebRTC內(nèi)部的工作原理，你就會知道那里發(fā)生了很多事。

我將從不同角度向大家解釋W(xué)ebRTC的工作原理。最后，它們將向你呈現(xiàn)出WebRTC的完整面貌。

WebRTC的基本概念

下面是我介紹WebRTC時首先強(qiáng)調(diào)的兩點(diǎn)：

WebRTC原生支持Web瀏覽器進(jìn)行實(shí)時通信

WebRTC是使用JavaScript API的媒體引擎

WebRTC是一種直接在Web瀏覽器內(nèi)部實(shí)現(xiàn)實(shí)時通信（語音、音頻和任意數(shù)據(jù)）的方法，無需任何插件和下載。

從另一方面看，WebRTC只是一個媒體引擎，其上層是JavaScript API，每個人都知道如何使用它（盡管瀏覽器實(shí)現(xiàn)依然各不相同）。所以從這一角度，我就不多做解釋了。

現(xiàn)在，讓我們從瀏覽器的角度開始了解真正令WebRTC獨(dú)一無二的原因。

如果到現(xiàn)在為止，當(dāng)你想到Web應(yīng)用的時候，呈現(xiàn)在你眼前的是客戶端和服務(wù)器：

你將瀏覽器作為客戶端，它連接服務(wù)器后，并向其請求內(nèi)容（讓我們稱之為請求）。服務(wù)器對請求發(fā)送響應(yīng)。這里我們先拋開WebSocket，但它們的內(nèi)在原理是一樣的。如果我想給正在使用瀏覽器的朋友發(fā)送一條信息，這條信息需要先來到服務(wù)器，從那里再發(fā)送給我的朋友。這與現(xiàn)實(shí)生活中的郵局非常相似。

WebRTC的交互流程和上述的流程不大一樣。

雖然我們?nèi)匀恍枰阅撤N方式從一個瀏覽器向另一個瀏覽器發(fā)送信令（以便我們能夠相互定位），但一旦發(fā)送信令結(jié)束，我們就可以直接在兩個瀏覽器之間發(fā)送消息——而Web服務(wù)器永遠(yuǎn)不會獲取到這些消息。是不是像魔法一樣？

這也是WebRTC被稱為點(diǎn)對點(diǎn)技術(shù)（簡稱為P2P）的原因。因?yàn)闉g覽器之間可以直接通信。

媒體和信令的分離

在加載網(wǎng)頁時，我們已經(jīng)習(xí)慣了瀏覽器為了渲染頁面要去獲取100種不同的資源，這些資源來自各種不同的服務(wù)器：頁面的托管服務(wù)器、保存靜態(tài)文件的CDN和一些第三方網(wǎng)站。也就是說，這些文件主要被分為三類：

HTML和CSS，構(gòu)成了網(wǎng)站及其形式的主要內(nèi)容

JS，通常運(yùn)行網(wǎng)站的交互部分

圖片文件和其他類似資源

最終，靜態(tài)文件和少許代碼的組合實(shí)現(xiàn)了這一切。

而WebRTC不同。

它需要通過網(wǎng)絡(luò)進(jìn)行兩種類型的交互：信令和媒體。

信令傳輸發(fā)生在HTTPS連接或者WebSocket上，通過JS代碼實(shí)現(xiàn)。你在信令中所做的就是決定用戶找到彼此，并開啟對話。關(guān)于信令有一件很重要的事：它并不是WebRTC的組成部分。由開發(fā)人員決定如何傳遞創(chuàng)建WebRTC會話所需的信息。WebRTC將生成發(fā)送所需的信息，并處理接收到的信息，但它不會在網(wǎng)絡(luò)上對這些信息進(jìn)行任何操作。現(xiàn)在，WebRTC將這些信息打包進(jìn)SDP消息中。

實(shí)際的媒體在一個完全不同的媒介和連接上傳輸：“媒體渠道（media channels）”。需要使用SRTP（用于語音和視頻）或者SCTP（用于數(shù)據(jù)通道）實(shí)現(xiàn)。

與信令不同，媒體選擇了一條不同的路線在網(wǎng)絡(luò)上進(jìn)行傳輸，并且表現(xiàn)也大不相同。對于你需要運(yùn)行的瀏覽器、網(wǎng)絡(luò)和服務(wù)器，情況也是如此。

音頻和視頻

音頻和視頻是你在使用WebRTC需要注意的主要內(nèi)容。在幾乎所有的WebRTC示例和demo中，你都可以看到它們的展示。原因非常簡單，視頻非常直觀，并且交互性強(qiáng)。WebRTC中的音頻和視頻使用編解碼器進(jìn)行工作。編解碼器是用于壓縮和解壓縮視頻和音頻數(shù)據(jù)的已知算法。WebRTC中有很多不同的編解碼器供你使用，這里我就不細(xì)說了。

音頻和視頻還有一個有趣的地方，就是它們需要低延遲發(fā)送。如果數(shù)據(jù)包因?yàn)榫W(wǎng)絡(luò)出現(xiàn)問題而丟失，那么再重新傳輸它們可能就沒有什么價值了（這是另外一個和HTML不一樣的地方）。

WebRTC使用VoIP技術(shù)處理媒體，并將其通過網(wǎng)絡(luò)發(fā)送，這一切都在SRTP（RTP的安全、加密版本）之上進(jìn)行。通過使用SRTP中的特定機(jī)制（以前并未廣泛使用），WebRTC做了一些小的修改，如果你已經(jīng)部署了VoIP服務(wù)，那么它們的互操作將變得更難。

數(shù)據(jù)

你也可以使用WebRTC傳輸任意數(shù)據(jù)，這個過程在WebRTC中的數(shù)據(jù)通道（data channel）中完成。

當(dāng)你想要在瀏覽器之間直接傳輸信息而不通過任何服務(wù)器時（你也許仍然需要一個TURN服務(wù)器轉(zhuǎn)發(fā)消息），就可以使用數(shù)據(jù)通道。

NAT 穿越

能夠直接通過瀏覽器通信當(dāng)然很棒，但是卻并不總行得通。

三四十年以前，互聯(lián)網(wǎng)創(chuàng)建在客戶端-服務(wù)器模式上，并在之后進(jìn)行了適度的修改。今天，大部分用戶從防火墻或者NAT后方訪問互聯(lián)網(wǎng)，這些設(shè)備通常會更改用戶設(shè)備的IP地址，并將其在開放網(wǎng)絡(luò)中屏蔽。這種屏蔽有時也會提供某種“保護(hù)”措施，防止未經(jīng)請求的流量流向用戶設(shè)備。這種方法的問題在于，WebRTC使用了多種用于信令和媒體的媒介，所以為分辨流量是否被請求帶來了困難。

此外，有些企業(yè)強(qiáng)調(diào)不允許任何類型的流量在未經(jīng)審查的情況下進(jìn)入他們的網(wǎng)絡(luò)。這就產(chǎn)生了下列場景：

由于發(fā)起了STUN請求，左側(cè)小人現(xiàn)在實(shí)際可能知道右側(cè)小人的公有IP地址。但是公有IP地址也許只對STUN服務(wù)器開放，其他人想要通過創(chuàng)建的“針孔（pinhole）”進(jìn)行連接依然會失敗。

想要克服這些問題（用戶設(shè)備無法直接與其他私有網(wǎng)絡(luò)中的設(shè)備直接通信），解決辦法是通過公有服務(wù)器轉(zhuǎn)發(fā)被阻止的媒體。這就是TURN服務(wù)器的目的：

預(yù)計(jì)5~20%的會話都會使用到TURN服務(wù)器。

由于這種復(fù)雜性，WebRTC會話的實(shí)現(xiàn)要經(jīng)過以下幾個步驟：

向Web服務(wù)器發(fā)送SDP請求。這條信息描述了設(shè)備想要交換的媒體通道，以及如何找到它們。

通過Web服務(wù)器接收到一條來自其他設(shè)備的SDP回復(fù)。記住，其他設(shè)備有可能是媒體服務(wù)器。

開啟一個被稱為ICE（Interactive Connectivity Establishment，交互連接建立）協(xié)商的程序，目的是確定設(shè)備是否可直接訪問、點(diǎn)對點(diǎn)傳輸或者是否需要通過TURN轉(zhuǎn)發(fā)媒體。這個過程最好使用trickle ICE完成，但要以后才能實(shí)現(xiàn)。

一旦完成，媒體就可以在設(shè)備之間通信了。

以上這些步驟需要在瀏覽器上使用JS進(jìn)行異步編程，使用JS Promises也能實(shí)現(xiàn)。在服務(wù)器端，你可以使用任何你想管理媒體和信令的工具。

很多時候，開發(fā)者不會直接針對WebRTC API進(jìn)行開發(fā)，而會使用第三方框架和模塊（開源或者商業(yè)）來做這件事。

WebRTC工作原理速覽

WebRTC直接在瀏覽器間發(fā)送數(shù)據(jù)：P2P。

它可以實(shí)時發(fā)送音頻、視頻或者任意數(shù)據(jù)。

它需要通過NAT穿越機(jī)制使瀏覽器之間相互訪問。

有時，P2P必須經(jīng)過中繼服務(wù)器（TURN）。

使用WebRTC，你需要考慮到信令和媒體，它們彼此分離。

并不一定要使用P2P，它只是一種選擇。你也可以在需要時使用媒體服務(wù)器。這種方式“破壞”了P2P，但是我們的目的是解決問題，而不是寫學(xué)術(shù)論文。

WebRTC中你需要的服務(wù)器包括：

信令服務(wù)器（或者作為你的應(yīng)用服務(wù)器的一部分，或者是一個獨(dú)立個體）。

STUN/TURN服務(wù)器（用于NAT穿越）。

媒體服務(wù)器（可選，只有在你的用例需要時才使用）

WebRTC API觀點(diǎn)

WebRTC擁有三個API，分別是：

1.getUserMedia

2.PeerConnection

3.Data Channel

getUserMedia

getUserMedia負(fù)責(zé)讓用戶訪問攝像頭、麥克風(fēng)和屏幕。它僅為本地執(zhí)行的操作提供服務(wù)，而無法實(shí)現(xiàn)實(shí)時對話。下列是getUserMedia的一些用法：

獲取用戶頭像圖片

收集音頻樣本，將它們發(fā)送給音頻轉(zhuǎn)文本的引擎

錄制音頻和視頻（不會因?yàn)閬G包而導(dǎo)致質(zhì)量下降）

我敢肯定你可以想到它的更多用法。

PeerConnection

PeerConnection是WebRCT的核心內(nèi)容，也是最難實(shí)現(xiàn)和理解的部分。在某種程度上，它是萬能的。

它負(fù)責(zé)處理所有SDP信息交換（不是將它們通過網(wǎng)絡(luò)發(fā)送，而是生成信息并處理傳入的信息）。

為了連接媒體通道，它實(shí)現(xiàn)了ICE（如果需要，它會經(jīng)過TURN轉(zhuǎn)發(fā)信息）。

它可以實(shí)時編碼、解碼視頻和音頻數(shù)據(jù)。

它通過網(wǎng)絡(luò)發(fā)送和接收媒體。

它通過使用自適應(yīng)jitter buffer、帶寬估計(jì)、丟包隱藏和前向糾錯等算法處理網(wǎng)絡(luò)問題（雖然你很不想了解這些算法，但最后都需要學(xué)習(xí)）。

使用回聲消除等算法處理本地音頻問題。

大部分這些影響最終媒體質(zhì)量的操作（發(fā)生在PeerConnection內(nèi)部）都是基于探測：一組特定規(guī)則。因此，不同的實(shí)現(xiàn)也許具有不同的表現(xiàn)和媒體質(zhì)量。

DataChannel

我之前曾討論過數(shù)據(jù)通道（data channel）。

這里我唯一要補(bǔ)充的是：

數(shù)據(jù)通道可以配置為可靠或者非可靠。如果將它設(shè)置為非可靠，那么信息將無法自動通過它重傳。有時，這要看你的個人喜好。數(shù)據(jù)通道也可以被配置為有序和無序傳輸信息。

數(shù)據(jù)通道被設(shè)計(jì)為在類似于WebSocket的API上運(yùn)行，一旦你打開它，你可以按照類似的方式進(jìn)行操作。

你可以在這里找到更多使用數(shù)據(jù)通道的方法：

https://bloggeek.me/webrtc-data-channel-uses/

WebRTC實(shí)現(xiàn)者的觀點(diǎn)

如果你想利用WebRTC實(shí)現(xiàn)一個應(yīng)用，你需要處理以下活動：

客戶端

信令

NAT穿越

媒體

客戶端

客戶端可以是瀏覽器、移動應(yīng)用、PC應(yīng)用，也可以是嵌入式設(shè)備。

對于Web瀏覽器來說，你需使用JavaScript進(jìn)行開發(fā)：或者直接使用WebRTC的API（不太可能），或者使用現(xiàn)存的框架，很多開發(fā)者會從Github開始（只要確保你選擇的是最近更新的流行平臺即可）。

對于移動應(yīng)用來說，最重要的是找到適合你使用的SDK。Github上有一些可以選用，也可以使用來自Google的一些官方SDK（用于iOS和Android）。有些商業(yè)的SDK也很好用。

對于PC應(yīng)用，你可以通過Electron實(shí)現(xiàn)。也可以使用嵌入式方法，這意味著你或者將官方的Google WebRTC代碼庫移植到你的設(shè)備上，或者自己開發(fā)。這兩種方法都有效。

信令

你需要信令服務(wù)器。WebRTC客戶端做的第一件事就是連接信令服務(wù)器。這么做的目的是協(xié)調(diào)你發(fā)起的任何會話。

信令服務(wù)器并不在WebRTC規(guī)定的范圍之內(nèi)，所以你需要自行決定在此處使用的代碼。大部分代碼你可以在Github中找到，實(shí)際上瀏覽器客戶端將會成為信令服務(wù)器的實(shí)現(xiàn)。

請記住信令服務(wù)器可以和你的Web服務(wù)器分開，或者它們位于同一進(jìn)程中（由你自己來決定）。不管如何，首先要做的是檢查是否已經(jīng)為你的應(yīng)用提供了某種信令機(jī)制，用于檢查非WebRTC事務(wù)。你也許可以在此機(jī)制上搭載SDP信息和其他與信令服務(wù)器相關(guān)的WebRTC。

NAT穿越

NAT穿越需要部署STUN/TURN服務(wù)器。我們先來看看哪些事不要做：

不要認(rèn)為你不需要TURN。

不要使用公有STUN服務(wù)器。

不要讓一臺服務(wù)器做所有事。

不要從構(gòu)建世界級服務(wù)器網(wǎng)絡(luò)開始，你會實(shí)現(xiàn)它，但需要時間。

現(xiàn)在來看看你該做哪些事：

將STUN和TURN部署在同一服務(wù)器，在相同進(jìn)程。

使用coturn（大家都在用）。

或者從他人那里獲得NAT穿越服務(wù)，XirSys和Twilio都是很好的選擇。

媒體

如果你計(jì)劃開啟群組語音和視頻會話、連接到PSTN或其他網(wǎng)絡(luò)，錄制或者其他高級功能，那么你就將需要使用媒體服務(wù)器。

尋找適用于你用例的服務(wù)器。

我甚至?xí)f，在你的技術(shù)棧里選擇任何技術(shù)之前就從這里開始。

還有一些開源或者商業(yè)選擇，它們在很多方面都不同。

WebRTC工作原理問與答

WebRTC可以用于移動應(yīng)用嗎？

可以。WebRTC在瀏覽器和操作系統(tǒng)間（包括iOS和Android）工作。作為開源項(xiàng)目，許多人也將它移植到自己的環(huán)境。

開發(fā)WebRTC我都需要做什么?

除了支持WebRTC的瀏覽器，你需要安裝自己的信令服務(wù)器和TURN服務(wù)器。根據(jù)你的用例，也可以使用媒體服務(wù)器。

我在哪里了解更多關(guān)于WebRTC工作原理的知識？

你可以關(guān)注WebRTC Weekly和webrtcHacks，上面的資源非常豐富。也可以訪問官方網(wǎng)站（https://webrtc.org/）。

結(jié)語

本篇文章的目的是幫助你理解最基礎(chǔ)的WebRTC知識（如果你是一個新手）。我不想從創(chuàng)建“hello world”應(yīng)用程序開始，你可以在網(wǎng)上找到很多這樣的應(yīng)用。我想做的是帶你到更高的地方，讓你一覽全局。

在很多情況下，人們從一個“hello world”WebRTC實(shí)現(xiàn)開始，并想要使其適用于他們自己的場景。我發(fā)現(xiàn)很多時候這種方法是錯誤的，因?yàn)樗蕾囉谀阆胍獦?gòu)建的內(nèi)容（它將決定你的WebRTC旅程的起點(diǎn)）。

花些時間閱讀這篇文章，然后再閱讀一兩個WebRTC的“hello world”手冊。如果你能夠這樣做，你的WebRTC實(shí)現(xiàn)將會更高效。

審核編輯 ：李倩