摘要
目錄
三，STUN（Simple Traversal of UDP Through NAT）
音視頻通話 = 音視頻處理 + 網絡傳輸，而公共互聯網不是爲了實時通信設計的。所以說開發真正可用的實時音視頻服務，從demo到生產上線，中間還差1萬個WebRTC。
一，WebRtc協議棧
二，NAT定義及類型
NAT（Network Address Translation，網絡地址轉換）是1994年提出的。當在專用網內部的一些主機本來已經分配到了本地IP地址（即僅在本專用網內使用的專用地址），但現在又想和因特網上的主機通信（並不需要加密）時，可使用NAT方法。這種通過使用少量的公有IP 地址代表較多的私有IP 地址的方式，將有助於減緩可用的IP地址空間的枯竭，同時保護了局域網內主機的安全。
- NAT實現方式：即靜態轉換Static Nat、動態轉換Dynamic Nat和端口多路複用OverLoad
- NAT穿透方法：目前常用的針對UDP的NAT 穿透（NAT Traversal）方法主要有：STUN、TURN、ICE、uPnP等。
- 其中ICE方式由於其結合了STUN和TURN的特點，所以使用最爲廣泛。
我們生活中大部分主機都在網關之後，他有自己的內網IP地址，並不知道自己的外網IP在網關上有個NAT功能，可以將內網地址映射成外網地址他就是一個四元組，經過映射後，將內網IP和端口映射成外網IP和端口，其他主機可以通過公網IP地址通信了。
三，STUN（Simple Traversal of UDP Through NAT）
兩臺外網主機之間也不能直接通信，它需要第三方服務做介紹，即STUN服務
將各自公網信息進行交換，使他們彼此認識
NAT產生原因
- 由於IPV4的地址不夠
一個內網中可能有上千臺主機，但映射到外網時只有一個或幾個IP地址，通過端口號來區分每臺主機
這樣就形成了一對幾百，一對幾千，大大減少了公網IP地址的使用 - 出於網絡安全的原因
所有辦公內的主機都在內部，他有自己的內網IP地址，但是沒有外網IP地址，外面的主機就很難攻擊到內網的某一臺主機，必須要經過防火牆，經過NAT轉換，才能找到內網中的主機
四，NAT種類以及穿越原理
當經過NAT轉換時，內網的主機出外網的時候形成的映射，並不是一個IP地址和端口，會形成多個IP地址和端口，
和不同的主機連接時都會形成對應的IP地址和端口，限制會更加嚴格，安全性自然也比前面幾種類型要高很多。
五，NAT穿越組合
一旦客戶端得知了Internet端的UDP端口，通信就可以開始了。如果NAT是完全圓錐型的，那麼雙方中的任何一方都可以發起通信。如果NAT是受限圓錐型或端口受限圓錐型，雙方必須一起開始傳輸。
需要注意的是，要使用STUN RFC中描述的技術並不一定需要使用STUN協議——還可以另外設計一個協議並把相同的功能集成到運行該協議的服務器上。
SIP之類的協議是使用UDP分組在Internet上傳輸音頻和／或視頻數據的。不幸的是，由於通信的兩個末端往往位於NAT之後，因此用傳統的方法是無法建立連接的。這也就是STUN發揮作用的地方。
STUN是一個客戶機－服務器協議。一個VoIP電話或軟件包可能會包括一個STUN客戶端。這個客戶端會向STUN服務器發送請求，之後，服務器就會向STUN客戶端報告NAT路由器的公網IP地址以及NAT爲允許傳入流量傳回內網而開通的端口。
以上的響應同時還使得STUN客戶端能夠確定正在使用的NAT類型——因爲不同的NAT類型處理傳入的UDP分組的方式是不同的。四種主要類型中有三種是可以使用的：完全圓錐型NAT、受限圓錐型NAT和端口受限圓錐型NAT——但大型公司網絡中經常採用的對稱型NAT（又稱爲雙向NAT）則不能使用。
STUN（Simple Traversal of User Datagram Protocol through Network Address Translators (NATs)，NAT的UDP簡單穿越）是一種網絡協議，它允許位於NAT（或多重NAT）後的客戶端找出自己的公網地址，查出自己位於哪種類型的NAT之後以及NAT爲某一個本地端口所綁定的Internet端端口。這些信息被用來在兩個同時處於NAT 路由器之後的主機之間建立UDP通信。該協議由RFC 3489定義。
六，NAT類型檢測
STUN 使用下列的算法（取自 RFC 3489）來發現 NAT gateways 以及防火牆（firewalls）:
一旦路經通過紅色箱子的終點時，UDP的溝通是沒有可能性的。一旦通過黃色或是綠色的箱子，就有連線的可能。
七，STUN 方式
- STUN存在的目的就是進行NAT穿越
- STUN是典型的客戶端/服務器模式。客戶端發送請求，服務器進行響應
解決穿透NAT問題的另一思路是，私網中的VOIP終端通過某種機制預先得到出口NAT上的對外地址，然後在淨載中所填寫的地址信息直接填寫出口 NAT上的對外地址，而不是私網內終端的私有IP地址，這樣淨載中的內容在經過NAT時就無需被修改了，只需按普通NAT流程轉換報文頭的IP地址即可，淨載中的 IP地址信息和報文頭地址信息是一致的。STUN協議就是基於此思路來解決應用層地址的轉換問題。
STUN的全稱是Simple Traversal of UDP Through Network Address Translators，即 UDP對NAT的簡單穿越方式。 應用程序(即STUN CLIENT)向NAT外的STUN SERVER通過UDP發送請求STUN 消息， STUN SERVER收到請求消息，產生響應消息，響應消息中攜帶請求消息的源端口，即STUN CLIENT在NAT上對應的外部端口。然後響應消息通過NAT發送給STUN CLIENT，STUN CLIENT通過響應消息體中的內容得知其NAT上的外部地址，並將其填入以後呼叫協議的UDP負載中，告知對端，本端的RTP接收地址和端口號爲NAT 外部的地址和端口號。由於通過STUN協議已在NAT上預先建立媒體流的NAT映射表項，故媒體流可順利穿越NAT.
STUN協議最大的優點是無需現有NAT/FW設備做任何改動。由於實際應用中，已有大量的NAT/FW，並且這些NAT/FW並不支持VoIP的應用，如果用MIDCOM或NAT/ALG方式來解決此問題，需要替換現有的NAT/FW，這是不太容易的。而採用STUN方式無需改動NAT/FW，這是其最大優勢，同時STUN方式可在多個NAT串聯的網絡環境中使用，但MIDCOM方式則無法實現對多級NAT的有效控制。
STUN的侷限性在於需要VOIP終端支持STUN CLIENT的功能，同時STUN並不適合支持TCP連接的穿越，因此不支持H323.另外 STUN方式不支持對防火牆的穿越，不支持對稱NAT (Symmetric NAT)類型(在安全性要求較高的企業網中，出口NAT通常是這種類型)穿越。
八、TURN方式
- 其目的是解決對稱NAT無法穿越的問題
- 其建立在STUN之上，消息格式使用STUN格式消息
- TURN Client 要求服務端分配一個公共IP和Port用於接收或發送數據
在上圖的傳輸過程中 TURN Client端到 TURN server端可以使用 UDP、TCP、TLS over TCP
TURN server端到 peer端 統一使用UDP。
TURN方式解決NAT問題的思路與STUN相似，也是私網中的VOIP終端通過某種機制預先得公網上的服務地址(STUN方式得到的地址爲出口 NAT上外部地址，TURN方式得到地址爲TURN Server上的公網地址)，然後在報文淨載中所要求的地址信息就直接填寫該公網地址。
TURN的全稱爲Traversal Using Relay NAT，即通過Relay方式穿越NAT.TURN應用模型通過分配 TURN Server的地址和端口作爲私網中VOIP終端對外的接受地址和端口，即私網終端發出的報文都要經過TURN Server進行Relay轉發，這種方式除了具有STUN方式的優點外，還解決了STUN應用無法穿透對稱NAT(Symmetric NAT)以及類似的Firewall設備的缺陷，同時TURN支持基於TCP的應用，如H323協議。此外TURN Server控制分配地址和端口，能分配RTP/RTCP地址對(RTCP端口號爲RTP端口號加1)作爲私網終端用戶的接受地址，避免了STUN方式中出口NAT對RTP/RTCP地址端口號的任意分配，使得客戶端無法收到對端發來的RTCP報文(對端發RTCP報文時，目的端口號缺省按RTP端口號加 1發送)。
TURN的侷限性在於需要VOIP終端支持TURN Client，這一點同STUN一樣對網絡終端有要求。此外，所有報文都必須經過TURN Server轉發，增大了包的延遲和丟包的可能性。
九，TURN的使用步驟
- STUN binding
客戶端到服務端打通，拿到映射的IP地址 - Caller TURN allocation
發起方（Caller）調用 allocation，讓TURN server開闢一個服務，接收發送數據的IP地址和端口 - Caller sends offer
Caller 通過信令 SDP的offer 將媒體信息，網絡信息等發送給被調用者 - Callee TURN allocation
對方（Callee）接到信息後也要發送給TURN服務發送 allocation - Callee answers OK
Callee 回覆OK - Exchange candidate IP addresses
交換 IP地址 - ICE check for P2P connection
首先檢查 P2P是否能打通NAT - If P2P unsuccessful, make relay connection
不成功的話，通過中繼服務
參考文章：
https://my.oschina.net/mye/blog/129921
https://webrtc.github.io/samples/