webrtc系列3——对于stun和turn的理解
文章目錄
- 對(duì)于stun和turn的理解
- 1. SDP協(xié)議
- 2. 地址轉(zhuǎn)換NAT
- 3. candidate
- stun
- TURN
- ICE
對(duì)于stun和turn的理解
在介紹turn和stun之前我們先來了解幾個(gè)概念
1. SDP協(xié)議
我們來思考,如果兩個(gè)不同的手機(jī),一個(gè)手機(jī)支持VP8、VP9的媒體格式,另一個(gè)支持VP8、h264的協(xié)議,他們?nèi)绻ㄐ诺脑挄?huì)選擇什么格式的媒體來進(jìn)行交流?
[外鏈圖片轉(zhuǎn)存失敗(img-uB81o8AW-1567468988824)(SDP協(xié)商.png)]
這時(shí)候我們就需要用到這個(gè)SDP協(xié)議了,在WebRTC中,參與視頻通訊的雙方必須先交換SDP信息,這樣雙方才能知根知底,而交換SDP的過程,也稱為"媒體協(xié)商"。
記住一點(diǎn),SDP不叫媒體協(xié)商,交換SDP的過程才叫媒體協(xié)商,SDP全名叫會(huì)話描述協(xié)議
2. 地址轉(zhuǎn)換NAT
經(jīng)常有人問我=
好吧,其實(shí)我也不是很清楚
歷史告訴我們,當(dāng)我們無法觸及到某個(gè)真理的時(shí)候,我們只能通過類比或者工具模擬的方式來解釋我們所看到的一切。
說起nat,其實(shí)就是不知道對(duì)方實(shí)際地址,然后通過扔一個(gè)探測(cè)包,然后有回應(yīng)就拿到對(duì)方地址的方式
我們說的nat不通,是因?yàn)樵蹅冞@個(gè)國(guó)內(nèi)網(wǎng)絡(luò)情況比較復(fù)雜,究其歷史原因,就要說到移動(dòng)、聯(lián)通、電信的歷史了,篇幅太長(zhǎng),暫時(shí)擱置。
總而言之,不通就不通嘛,總還有別的辦法
3. candidate
我們先來看下Ice candidate類中的屬性
public final String sdpMid;//描述協(xié)議的idpublic final int sdpMLineIndex;//描述協(xié)議的行索引public final String sdp;//會(huì)話描述協(xié)議好了,到這為止,應(yīng)該已經(jīng)了解到,這玩意就是個(gè)模版
當(dāng)我們調(diào)用setLocalDescription的時(shí)候,底層的代碼就會(huì)幫我們的收集candidate(候選信息),然后回調(diào)到上層,然后我們將其發(fā)送到服務(wù)器,然后服務(wù)器再發(fā)送到另一端
一定會(huì)好奇這個(gè)candidate里有啥是吧,其實(shí)就是一些網(wǎng)絡(luò)信息的候選地址,一個(gè)不通換另一種的那種。
我們稱交換candidate的過程稱為網(wǎng)絡(luò)協(xié)商
stun
好了,我們的主角登場(chǎng)
STUN(Session Traversal Utilities for NAT,NAT會(huì)話穿越應(yīng)用程序)是一種網(wǎng)絡(luò)協(xié)議,它允許位于NAT(或多重
NAT)后的客戶端找出自己的公網(wǎng)地址,查出自己位于哪種類型的NAT之后以及NAT為某一個(gè)本地端口所綁定的
Internet端端口。這些信息被用來在兩個(gè)同時(shí)處于NAT路由器之后的主機(jī)之間創(chuàng)建UDP通信。該協(xié)議由RFC 5389定
義。
其實(shí)有好多人問我,在局域網(wǎng)需不需要stun服務(wù)器?
我很認(rèn)真的告訴你,不需要!
這時(shí)候,又會(huì)有人問了,你的demo為啥不部署stun,局域網(wǎng)內(nèi)不通呢?
我也很認(rèn)真的告訴你,請(qǐng)看官方demo,有個(gè)直連的類你可以借鑒,直接填寫對(duì)方的地址,因?yàn)樾枰缹?duì)方的地址才能進(jìn)行通信的咧
來張圖
STUN并不是每次都能成功的為需要NAT的通話設(shè)備分配IP地址的,P2P在傳輸媒體流時(shí),使用的本
地帶寬,在多人視頻通話的過程中,通話質(zhì)量的好壞往往需要根據(jù)使用者本地的帶寬確定。
這時(shí)候,就需要turn來協(xié)調(diào),保證通話質(zhì)量,用服務(wù)器來解壓
TURN
TURN的全稱為Traversal Using Relays around NAT,是STUN/RFC5389的一個(gè)拓展,主要添加了Relay功能。如果
終端在NAT之后, 那么在特定的情景下,有可能使得終端無法和其對(duì)等端(peer)進(jìn)行直接的通信,這時(shí)就需要公網(wǎng)
的服務(wù)器作為一個(gè)中繼, 對(duì)來往的數(shù)據(jù)進(jìn)行轉(zhuǎn)發(fā)。這個(gè)轉(zhuǎn)發(fā)的協(xié)議就被定義為TURN。
再來張圖
在STUN分配公網(wǎng)IP失敗后,可以通過TURN服務(wù)器請(qǐng)求公網(wǎng)IP地址作為中繼地址。這種方式的帶寬由服務(wù)器端承
擔(dān),在多人視頻聊天的時(shí)候,本地帶寬壓力較小,并且,根據(jù)Google的說明,TURN協(xié)議可以使用在所有的環(huán)境中。
ICE
ICE跟STUN和TURN不一樣,ICE不是一種協(xié)議,而是一個(gè)框架(Framework),它整合了STUN和TURN。
coturn開源項(xiàng)目集成了STUN和TURN的功能
好了這篇文章到此位置,看看代碼消化一下
Android端:https://github.com/ddssingsong/webrtc_android
服務(wù)器端:https://github.com/ddssingsong/webrtc_server_node
總結(jié)
以上是生活随笔為你收集整理的webrtc系列3——对于stun和turn的理解的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: NAT- STUN和TURN简介
- 下一篇: 一种简单的睡眠评分规则