資訊專欄INFORMATION COLUMN
摘要：國際互聯(lián)網(wǎng)工程任務(wù)組，簡(jiǎn)稱創(chuàng)建里和標(biāo)準(zhǔn)來解決穿越的問題。是一個(gè)被穿越算法用來協(xié)助發(fā)現(xiàn)網(wǎng)絡(luò)環(huán)境信息的網(wǎng)絡(luò)協(xié)議包格式。這些類型不能被使用因?yàn)榭赡苡绊憙?nèi)部的處理流程。
前言
最近因?yàn)樵谘芯縒ebRTC，因?yàn)閷?duì)音頻視頻模塊基本都已經(jīng)了解，就對(duì)其中的網(wǎng)絡(luò)模塊針對(duì)性的了解一下。
這里面Transport層主要涉及3個(gè)層次SRTP、Multiplexing、P2P（STUN+TURN+ICE），現(xiàn)在就主要針對(duì)P2P這部分STUN、TURN和ICE的來源和設(shè)計(jì)初衷做個(gè)簡(jiǎn)單的介紹，不涉及具體的算法和技術(shù)實(shí)現(xiàn)，主要內(nèi)容主要是翻譯自外網(wǎng)的這篇文章。里面有一些公司介紹廣告就不說了。
IP地址和視頻連接的一個(gè)棘手問題是NAT的限制和防火墻對(duì)建立可靠呼叫的影響(A setback to IP and Video connectivity has been the restriction NATs and firewalls pose to reliable call completion.這句原話的語法拆解了好久= =)。NAT和防火墻在安全和加強(qiáng)因特網(wǎng)的可用性上扮演了很重要的角色，但是同時(shí)也造成了在建立IP終端上嚴(yán)重的問題。IETF（國際互聯(lián)網(wǎng)工程任務(wù)組 The Internet Engineering Task Force，簡(jiǎn)稱 IETF）創(chuàng)建里STUN, TURN和ICE標(biāo)準(zhǔn)來解決NAT穿越的問題。
STUN能幫助連接IP終端：
發(fā)現(xiàn)他們是否在NAT或者防火墻后面
確定公網(wǎng)IP地址和防火墻的類型。STUN然后使用這些信息去協(xié)助建立點(diǎn)對(duì)點(diǎn)的IP連接
雖然STUN在解決大部分用戶設(shè)備（路由器之類的）的NAT問題上很有效，但是它在很多公司網(wǎng)絡(luò)上問題上不是很有效。TURN，全稱Traversal Using Relay NAT，通過提供使用一個(gè)流媒體預(yù)備服務(wù)來實(shí)現(xiàn)終端之間的流媒體傳輸?shù)慕导?jí)NAT穿越技術(shù)。
ICE是一個(gè)權(quán)衡STUN、TURN來提供可以來的IP建立和媒體傳輸?shù)目蚣?，通過一個(gè)SIP提供一個(gè)終端交換候選IP地址和端口的模型（比如一個(gè)私有地址和TURN服務(wù)地址）。
什么是NATNAT是指Network Address Translation。概括來說就是路由器把本地私有子網(wǎng)IP地址轉(zhuǎn)換稱公網(wǎng)（通常是一個(gè)由因特爾服務(wù)供應(yīng)商ISP分配的IP地址）IP地址的修改IP信息的過程?，F(xiàn)有的一個(gè)主要挑戰(zhàn)就是在網(wǎng)絡(luò)中的客戶端之間建立直接連接。
現(xiàn)在有4中NAT在如今的路由器中，根據(jù)最少限制性到最多限制性來排序可以分為：
Full cone（全錐型）一旦一個(gè)內(nèi)網(wǎng)地址（iAddr:iPort）被映射到一個(gè)外部網(wǎng)絡(luò)地址(eAddr:ePort)，任何iAddr:iPort的包都會(huì)通過eAddr:ePort來發(fā)送。任何外部主機(jī)都可以通過給eAddr:ePort發(fā)送網(wǎng)絡(luò)包來給iAddr:iPort傳送信息。
Address-restricted cone（限制型錐形）一旦一個(gè)內(nèi)網(wǎng)地址（iAddr:iPort）被映射到一個(gè)外部網(wǎng)絡(luò)地址(eAddr:ePort)，任何iAddr:iPort的包都會(huì)通過eAddr:ePort來發(fā)送。但是一個(gè)外部的主機(jī)(hAddr:any)只有在iAddr:iPort之前給hAddr:any發(fā)送過網(wǎng)絡(luò)包的情況下才可以通過eAddr:ePort給iAddr:iPort發(fā)送網(wǎng)絡(luò)包，any這里指任意端口。（總結(jié)下來就是只有內(nèi)部給外部主機(jī)發(fā)送過信息，才能通過外部地址端口往內(nèi)部發(fā)送）。
Port-restricted cone（端口限制型錐型）一旦一個(gè)內(nèi)網(wǎng)地址（iAddr:iPort）被映射到一個(gè)外部網(wǎng)絡(luò)地址(eAddr:ePort)，任何iAddr:iPort的包都會(huì)通過eAddr:ePort來發(fā)送。但是一個(gè)外部的主機(jī)(hAddr:hPort)只有在iAddr:iPort之前給hAddr:hPort發(fā)送過網(wǎng)絡(luò)包的情況下才可以通過eAddr:ePort給iAddr:iPort發(fā)送網(wǎng)絡(luò)包，any這里指任意端口。和地址限制錐型差不多，只是還多了外部主機(jī)的端口的限制。
Symmetric（對(duì)稱型）每個(gè)從相同內(nèi)部IP地址和端口到特定目標(biāo)IP地址和端口的請(qǐng)求都會(huì)被映射到一個(gè)特殊的外部源IP地址和都端口上，如果相同的內(nèi)部主機(jī)發(fā)送了包給相同的源地址和端口，但是是不同的目標(biāo)，也會(huì)使用不同的映射。只有一個(gè)外部的主機(jī)從內(nèi)部主機(jī)接收到過包，才能發(fā)送回去。
什么是STUNSTUN是指Session Traversal Utilities for NAT。是一個(gè)被NAT穿越算法用來協(xié)助發(fā)現(xiàn)網(wǎng)絡(luò)環(huán)境信息的網(wǎng)絡(luò)協(xié)議/包格式(IETF RFC 5389) 。發(fā)送方在發(fā)送服務(wù)器和發(fā)送客戶端之間傳輸使用STUN包。
如果端之間的路由器使用了全錐型，限制型錐形、端口限制型錐型，那么就會(huì)發(fā)現(xiàn)一個(gè)多帶帶STUN的直接連接。如果有有路由器使用了對(duì)稱型NAT，那么只有在其他路由不用對(duì)稱型或者端口限制型NAT的情況下才能發(fā)現(xiàn)一個(gè)STUN包的連接。但是不用擔(dān)心！發(fā)送方會(huì)自動(dòng)的發(fā)現(xiàn)一個(gè)替換TURN的路徑。
TURN是指Traversal Using Relays around NAT。就像STUN，它是一個(gè)被NAT穿越算法用來協(xié)助發(fā)現(xiàn)網(wǎng)絡(luò)內(nèi)終端直接連接路徑的網(wǎng)絡(luò)協(xié)議/包格式(IETF RFC 5766)。和STUN不同的是它用了一個(gè)公網(wǎng)的替換中介提換終端之間的包。當(dāng)沒有其他選擇可用的時(shí)候，發(fā)送方使用TURN來交換流媒體包。因?yàn)樗ㄖ屏朔?wù)資源所以也會(huì)因?yàn)檫@多的一步產(chǎn)生一定的延遲。
TURN只有在一個(gè)端使用了對(duì)稱型NAT，并且其他的端使用了對(duì)稱型NAT或者端口限制型NAT的時(shí)候才需要。
什么是ICEICE是指Interactive Connectivity Establishment。它定義了一個(gè)技術(shù)來使用SDP，STUN和TURN來發(fā)現(xiàn)網(wǎng)絡(luò)里端之間的路徑。發(fā)送方實(shí)現(xiàn)符合標(biāo)準(zhǔn)的ICE specification(IETF RFC 5245) ，就能兼容其他的端來實(shí)現(xiàn)同樣的spec。
每個(gè)RTP包都有一個(gè)7位的payload類型（0-127）和一個(gè)二進(jìn)制payload。payload類型用于區(qū)分payload的格式，并且在創(chuàng)建發(fā)送方連接的時(shí)候需要定義好。IANA留出了一些payload type用于特定的格式。如果你在用一個(gè)不被IANA識(shí)別的編碼格式，那么根據(jù)他們的建議，最好用96-127中的數(shù)字。
發(fā)送方唯一的限制是payload類型72-76是留給RTCP的。這些payload類型不能被使用因?yàn)榭赡苡绊憙?nèi)部RTCP的處理流程。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/106403.html
摘要：為了使連接起作用，對(duì)等方必須獲取元數(shù)據(jù)的本地媒體條件例如，分辨率和編解碼器功能，并收集應(yīng)用程序主機(jī)的可能網(wǎng)絡(luò)地址，用于來回傳遞這些關(guān)鍵信息的信令機(jī)制并未內(nèi)置到中。所有特定于多媒體的元數(shù)據(jù)都使用協(xié)議傳遞。 這是專門探索 JavaScript 及其所構(gòu)建的組件的系列文章的第 18 篇。 想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博客,一年百來篇優(yōu)質(zhì)文章等著你！ 如果你錯(cuò)過了前面的章節(jié)，可以在這里...
摘要：穿透的協(xié)議穿透協(xié)議系列介紹了協(xié)議協(xié)議版本變化屬于的協(xié)議通過與之間發(fā)送數(shù)據(jù)包通信以獲取一些信息。同樣和交互其作用是穿透失敗使用中繼，確保通信成功的低優(yōu)先級(jí)策略。 UDP NAT穿透俗稱p2p打洞。講到NAT, 追溯一下NAT產(chǎn)生原因：使用ipv4的時(shí)候，地址數(shù)量有限，NAT設(shè)備可以讓接上它的其他設(shè)備在其上共享ip,緩解地址不夠用。當(dāng)然ipv6的概念早就來臨了，國內(nèi)推廣的程度和推廣慢原因這...
摘要：在處于使用了設(shè)備的私有網(wǎng)絡(luò)中的主機(jī)之間需要建立連接時(shí)需要使用穿越技術(shù)。目前已經(jīng)有很多穿越技術(shù)，但沒有一項(xiàng)是完美的，因?yàn)榈男袨槭欠菢?biāo)準(zhǔn)化的。 什么是WebRTC？ 眾所周知，瀏覽器本身不支持相互之間直接建立信道進(jìn)行通信，都是通過服務(wù)器進(jìn)行中轉(zhuǎn)。比如現(xiàn)在有兩個(gè)客戶端，甲和乙，他們倆想要通信，首先需要甲和服務(wù)器、乙和服務(wù)器之間建立信道。甲給乙發(fā)送消息時(shí)，甲先將消息發(fā)送到服務(wù)器上，服務(wù)器對(duì)甲...
摘要：對(duì)于接收方來說，則必須實(shí)時(shí)解碼音頻和視頻流，并適應(yīng)網(wǎng)絡(luò)抖動(dòng)和時(shí)延。另外，由于主要是用來解決實(shí)時(shí)通信的問題，可靠性并不是很重要，因此，使用作為傳輸層協(xié)議低延遲和及時(shí)性才是關(guān)鍵。握手記錄嚴(yán)格按照協(xié)議規(guī)定的順序傳輸，順序不對(duì)就報(bào)錯(cuò)。 Web Real-Time Communication（Web實(shí)時(shí)通信，WebRTC）由一組標(biāo)準(zhǔn)、協(xié)議和JavaScript API組成，用于實(shí)現(xiàn)瀏覽器之間（端...
摘要：本質(zhì)上允許網(wǎng)頁程序創(chuàng)建點(diǎn)對(duì)點(diǎn)通信，我們將會(huì)在隨后的章節(jié)中進(jìn)行介紹。信令涉及網(wǎng)絡(luò)檢索和穿透，會(huì)話創(chuàng)建及管理，通信安全，媒體功能元數(shù)據(jù)和調(diào)制及錯(cuò)誤處理。這樣就會(huì)完全建立及激活節(jié)點(diǎn)間的網(wǎng)絡(luò)套接字會(huì)話。 原文請(qǐng)查閱這里，略有刪減，本文采用知識(shí)共享署名 4.0 國際許可協(xié)議共享，BY Troland。 這是 JavaScript 工作原理第十八章。 概述 何為 WebRTC ？首先，字面上已經(jīng)...
閱讀 1065·2019-08-30 12:57
閱讀 2157·2019-08-30 11:11
閱讀 2190·2019-08-29 15:20
閱讀 1882·2019-08-29 14:12
閱讀 3283·2019-08-28 17:51
閱讀 2390·2019-08-26 13:23
閱讀 815·2019-08-26 10:34
閱讀 3876·2019-08-23 12:37
