WebRTC允許應(yīng)用使用P2P通信。WebRTC是一個廣泛的話題，在本文中，我們將重點(diǎn)討以下問題。
為什么Web RTC 如此受歡迎？
在P2P連接過程中會發(fā)生什么
信號傳遞
NATs和ICE
STUN & TURN服務(wù)器
VP9視頻編解碼器
WebRTC APIs
安全
1.為什么Web RTC 如此受歡迎？
開放源代碼 它為瀏覽器提供了端到端的通信，并且很容易使用。
速度提升 不需要通過服務(wù)器進(jìn)行路由，它減少了延遲和帶寬消耗。直接通信提高了數(shù)據(jù)傳輸&文件共享的速度。
不需要第三方應(yīng)用程序 不需要額外的軟件、插件或服務(wù)器持續(xù)參與（僅在初始的時候需要）。可以輕松嵌入到任何網(wǎng)站中，就可以連接互聯(lián)網(wǎng)上的Peer。
易于實(shí)現(xiàn) 使用P2P（點(diǎn)對點(diǎn)）連接更加容易。所有的功能都可以通過客戶端完成。開發(fā)者只需要下載一個與WebRTC兼容的瀏覽器。
兼容性 支持大多數(shù)流行的瀏覽器。Microsoft Edge、Google Chrome、Mozilla Firefox、Safari、Safari、Opera、Vivaldi。支持Android、Chrome OS、Firefox OS、黑莓10、iOS、Tizen。
提供跨多種瀏覽器的安全連接 所有的WebRTC組件都必須進(jìn)行加密。由于它不是一個插件，所以它運(yùn)行在瀏覽器的沙盒內(nèi)，不需要創(chuàng)建一個新的進(jìn)程，這樣就不會有任何惡意軟件進(jìn)入用戶操作系統(tǒng)。無需跟蹤更新。它會隨著瀏覽器版本的自動更新。
2.在P2P連接期間會發(fā)生什么？
要連接兩個瀏覽器，Web RTC需要執(zhí)行五個步驟來建立P2P連接。
信號處理，以去除音頻或視頻中的環(huán)境噪聲。
編解碼器處理，以壓縮和解壓音頻或視頻。
通過防火墻、（NAT）和中繼器建立從一個Peer 到另一個Peer的路由，以創(chuàng)建一個ICE(交互式鏈接建立)。
用戶數(shù)據(jù)在進(jìn)行連接傳輸前都會進(jìn)行加密。
管理帶寬，給每個Peer的帶寬不同
2.1信號傳遞
瀏覽器中的P2P連接由服務(wù)器建立，以確保所有Peer同意建立會話。
Peer之間共享會話密鑰、錯誤信息、媒體元數(shù)據(jù)、編解碼器、帶寬、公共IP地址和端口等信息以創(chuàng)建連接。 服務(wù)器向兩個Peer發(fā)出信號，以確定使用什么媒體格式以及每個Peer要向?qū)Ψ桨l(fā)送什么。
2.2網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）和ICE
NATs將家庭路由器等設(shè)備上的私有IP地址轉(zhuǎn)換為公網(wǎng)IP地址。防火墻和NATs通過阻止特定的協(xié)議或端口來減慢這一過程。WebRTC使用的解決方案是ICE框架。
ICE通過并行嘗試所有連接并選擇最有效的路徑，在互聯(lián)網(wǎng)上建立P2P連接。有兩種類型的連接可選 STUN & TURN
2.3STUN服務(wù)器
它首先連接到STUN(Session Traversal Utilities for NAT)服務(wù)器，獲得直接連接。
STUN服務(wù)器為請求者提供了公網(wǎng)IP地址，以便與他人進(jìn)行通信。其目的是幫助請求者回答 "我的IP地址是啥 "這個問題。
STUN服務(wù)器如何工作
?文章來源地址http://www.zghlxwxcb.cn/news/detail-503076.html
?文章來源：http://www.zghlxwxcb.cn/news/detail-503076.html
要建立與其他Peer的連接，需要終端知道自己的公網(wǎng)IP才能與他人共享。
當(dāng)一個Peer(Calvin)在NAT/防火墻后面時，它只能識別它的私有IP地址，而另一個Peer(Elana)由于防火墻的安全性，無法連接到本地IP。
這個Peer會向STUN服務(wù)器請求，獲取它的公網(wǎng)IP地址和一種可用NAT類型。
另一個Peer(Elana)可以使用STUN服務(wù)器給定的公網(wǎng)IP地址嘗試進(jìn)行連接。
如果成功，數(shù)據(jù)將通過點(diǎn)對點(diǎn)網(wǎng)絡(luò)傳輸，而不需要第三方或其他服務(wù)器。
為了安全起見，所有STUN服務(wù)器將被丟棄并等待下一次查詢。
限制 - 對稱NAT
但是，上述情況有時可能會失敗，IP地址和端口會發(fā)生變化。 這種情況稱為 "對稱NAT"，STUN服務(wù)器的公網(wǎng)IP地址沒有足夠的能力在這里建立連接，因?yàn)槎丝谝残枰D(zhuǎn)換。
有些路由器使用對稱NAT，是為了使終端設(shè)備更加安全，或者說避免很多陌生人連到你的設(shè)備上。對稱NAT不僅可以將IP地址從私有地址轉(zhuǎn)換成公共地址，還可以轉(zhuǎn)換端口。
換句話說，路由器只會接受用戶已經(jīng)有過的連接。因此，另一種確保兩個Peer之間連接的解決方案是通過TURN服務(wù)器。
為什么STUN服務(wù)器如此有用
作為一種協(xié)議，STUN具有超快、輕量的特點(diǎn)。它可以在很短的時間內(nèi)將數(shù)據(jù)直接傳送給對方。STUN有利于加快連接速度，更快地獲取結(jié)果。
當(dāng)用戶使用LAN局域網(wǎng)傳輸數(shù)據(jù)時，場景類似，比使用Wi-Fi傳輸更快。最重要的是，可以直接在兩個Peer之間傳輸數(shù)據(jù)。
TURN 服務(wù)器
TURN（Traversal Using Relays around NAT）服務(wù)器作為中繼服務(wù)器，以防P2P連接中斷。當(dāng)STUN服務(wù)器用于建立連接時，TURN服務(wù)器在整個連接過程中保持活躍。
TURN服務(wù)器在WebRTC Peer之間不斷中繼數(shù)據(jù)。這就是為什么用 "中繼 "一詞來定義TURN。
TURN 服務(wù)器如何工作
這個中繼服務(wù)器是在STUN服務(wù)器出現(xiàn)故障時用來中繼流量的，同時也具有STUN的功能。
TURN服務(wù)器是一個內(nèi)置傳輸功能的STUN服務(wù)器。更具體地說，TURN是用來中繼Peer之間的音視頻/數(shù)據(jù)流，而不是信令數(shù)據(jù)。
按照上文STUN服務(wù)器的步驟運(yùn)行
如果STUN失敗，終端用戶會與TURN服務(wù)器建立連接，通知所有Peer向服務(wù)器發(fā)送數(shù)據(jù)，服務(wù)器負(fù)責(zé)向第一個終端用戶傳輸數(shù)據(jù)。
為什么總是先使用STUN服務(wù)器，主要原因是TURN服務(wù)器成本太高，如果在線傳輸高清視頻的話，會消耗大量帶寬。
2.4VP9視頻編解碼器
為什么很多人開始使用WebRTC，其中一個主要原因就是因?yàn)橐曨l。隨著視頻直播越來越成為主流，視頻質(zhì)量的要求也越來越高，這就要求數(shù)據(jù)傳輸?shù)乃俣纫?，或者?shù)據(jù)包的大小要小，才能方便傳輸速度高。
VP9視頻編解碼器用于對音頻或視頻進(jìn)行壓縮和解壓。音視頻數(shù)據(jù)壓縮后大大減小體積，因此VP9可以幫助流媒體視頻更快傳輸。Safari 12.1（通過支持VP8）可以與其他Peer進(jìn)行在線實(shí)時視頻。
VP9是在VP8的基礎(chǔ)上改進(jìn)而來的，是谷歌旗下的由On2科技公司創(chuàng)建的視頻壓縮格式。主要功能是隱藏丟包和清理嘈雜的圖像，以及多平臺的采集和播放功能。
通過VP9，用戶可以使用WebRTC傳輸720p視頻，而不會出現(xiàn)丟包或延遲。同時，它還可以在同樣的帶寬下支持1080p視頻通話，并幫助優(yōu)化連接和數(shù)據(jù)使用，避免帶寬成本過于高昂。
3.JS APIs
有三個主要的Javascript API可以處理音頻捕獲、視頻會議和數(shù)據(jù)傳輸。
MediaStream
使用用戶的攝像頭和麥克風(fēng)來獲取和傳輸音頻和視頻。使用這個API可以讓你獲得麥克風(fēng)和網(wǎng)絡(luò)攝像頭等設(shè)備的訪問權(quán)限。
當(dāng)開發(fā)人員將WebRTC集成到他們的網(wǎng)站中時，他們可以對他們想要的音頻和視頻流的參數(shù)進(jìn)行設(shè)置，比如幀率、視頻幀的大小、分辨率等。
這個API是作為HTML 5的一部分提供的，而其他兩個API是專門為WebRTC提供的。
RTCPeerConnection
將采集到的音視頻流實(shí)時發(fā)送至另一個WebRTC Peer。使用該API，用戶可以將getUserMedia捕獲的音頻和視頻傳輸給其他Peer。
該API具有連接到遠(yuǎn)程Peer，維護(hù)和監(jiān)控連接，并在完成后關(guān)閉連接等功能。
RTCDataChannel
傳輸任意數(shù)據(jù)。每個數(shù)據(jù)通道都與一個RTCPeerConnection相關(guān)聯(lián)。內(nèi)置安全（DTLS）和擁塞控制。
4.安全
在實(shí)時通信的數(shù)據(jù)傳輸過程中可能會產(chǎn)生很多安全風(fēng)險。因此，加密是WebRTC的強(qiáng)制性功能，并在所有組件上強(qiáng)制執(zhí)行。
WebRTC使用兩種標(biāo)準(zhǔn)加密協(xié)議。
數(shù)據(jù)報傳輸層安全協(xié)議（DTLS）
一種建立在瀏覽器中的標(biāo)準(zhǔn)化協(xié)議。它用于加密數(shù)據(jù)流。它基于傳輸層協(xié)議（TLP）。
保留了傳輸語義，DTLS使用用戶數(shù)據(jù)協(xié)議（UDP）。
它是安全套接字層（SSL）的擴(kuò)展；任何SSL協(xié)議都可以用來保護(hù)WebRTC數(shù)據(jù)的安全，允許端到端加密。
安全實(shí)時傳輸協(xié)議(SRTP)
用于加密媒體流。
它是實(shí)時傳輸協(xié)議（RTP）的擴(kuò)展，RTP沒有任何內(nèi)置的安全機(jī)制。
在RTP的基礎(chǔ)上增加了保護(hù)、完整性檢查和消息認(rèn)證。
缺點(diǎn)是 雖然它為RTP數(shù)據(jù)包提供了加密，但它并沒有對報頭進(jìn)行加密。
確保2個Peer之間連接安全的步驟
啟動信令過程在兩個Peer之間交換元數(shù)據(jù)。
執(zhí)行ICE檢查，ICE在雙方之間建立通道。
進(jìn)行DTLS握手。如果有多媒體傳輸，SRTP使用DTLS握手步驟中導(dǎo)出的密鑰。
所有Peer都有安全通道。
Peer之間交換密鑰。
使用WebRTC的應(yīng)用
Google Meet/ Google Hangout
Facebook Messenger
Discord
Amazon Chime
?
?
到了這里，關(guān)于WebRTC音視頻會議底層支撐技術(shù)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
