stun, turn, ice協(xié)議概述

stun,turn,ice是ietf提出的處理voip網(wǎng)絡(luò)中nat穿越問題的協(xié)議族。

    stun 可以處理大部分nat問題，turn是stun協(xié)議的一個(gè)增強(qiáng)版，專用于處理對稱形nat問題，而ice則是綜合stun及turn的產(chǎn)物，是一個(gè)框架，綜合運(yùn)用STUN和TURN的結(jié)構(gòu)，它提供可靠的VoIP或視頻通話配置以及媒體傳輸，通過一個(gè)SIP供給/應(yīng)答模型供端點(diǎn)交換多個(gè)候選IP地址和端口（比如私有地址和TURN服務(wù)器地址）。

    采用此框架可以完美解決voip 中 媒體傳輸中遇到的 nat及防火墻問題，而信令穿越則需要另一套機(jī)制，過去人們提出了多種處理nat問題的方案，但都有局限性，采用ice則完全解決了這些問題，ice的另一個(gè)特點(diǎn)時(shí)能夠通過一定機(jī)制檢測nat類型，從而決定采用何種方案處理，比如對于大多數(shù)呼叫，媒體可能直接用p2p方式即可，而有些方案可能不論什么nat類型都用media-relay方式，這種方式增加了端到端延時(shí)及丟包概率。

    stun和turn都是client/server協(xié)議，說白了就是客戶端向服務(wù)器要自己的公網(wǎng)地址及端口，然后放在自己invite請求的sdp消息體及對invite的 200 ok  sdp 消息體中。

大多數(shù)sip客戶端和服務(wù)器支持stun協(xié)議，所以都有一定缺陷。

http://blog.csdn.net/perfectpdl/article/details/7636067

概括一下：

若一個(gè)主機(jī)位于NAT后面，那么在特定的環(huán)境下，它不可能跟其他主機(jī)通信。這種情況下，這臺主機(jī)有必要通過一個(gè)轉(zhuǎn)發(fā)的主機(jī)來實(shí)現(xiàn)通信。有種協(xié)議叫TURN，允許主機(jī)通過轉(zhuǎn)發(fā)來和其他主機(jī)通信。TURN協(xié)議與其他轉(zhuǎn)發(fā)協(xié)議不同的地方在于它允許客戶端用一個(gè)轉(zhuǎn)發(fā)地址同多個(gè)主機(jī)交流。

 1 簡介

一個(gè)位于NAT后面的主機(jī)可能相同其他位于NAT后面的主機(jī)交流。為了達(dá)到目的，可以用打洞的方法來找到一條路徑，但是不通過轉(zhuǎn)發(fā)。

當(dāng)兩臺主機(jī)都位于對稱NAT之后時(shí)，打洞技術(shù)可能會失敗。

TURN協(xié)議允許一個(gè)位于NAT之后的主機(jī)請求另一臺主機(jī)轉(zhuǎn)發(fā)?？蛻舳丝梢酝ㄟ^服務(wù)端轉(zhuǎn)發(fā)包到另一端。并且可以控制轉(zhuǎn)發(fā)如何結(jié)束。這個(gè)客戶端通過在服務(wù)端獲取一個(gè)IP端口對，也被稱作轉(zhuǎn)發(fā)端口地址來進(jìn)行上述操作。

當(dāng)對方發(fā)送一個(gè)包到轉(zhuǎn)發(fā)端口地址時(shí)，服務(wù)器就將這個(gè)包轉(zhuǎn)發(fā)到客戶端。當(dāng)一個(gè)客戶端發(fā)送一個(gè)數(shù)據(jù)包到服務(wù)器時(shí)，服務(wù)器轉(zhuǎn)發(fā)這個(gè)包到轉(zhuǎn)發(fā)端口地址所對應(yīng)的客戶端。

一個(gè)采用TURN協(xié)議的客戶端一定有一些方法把自己的轉(zhuǎn)發(fā)地址告訴對方，并且知道每個(gè)通信伙伴的IP端口地址對。

若TURN協(xié)議被用作ICE協(xié)議中，那么它的轉(zhuǎn)發(fā)IP端口對和其他伙伴的IP端口對都包含在ICE候選者信息中。例如，如果TURN和ICE被SIP用于媒體傳輸時(shí)，SIP以會話協(xié)議的方式，將ICE候選者的信息放進(jìn)SIP消息體中。若TURN和ICE協(xié)議被用在其他會話協(xié)議中，那么【MUSIC-ICE-NONSIP】將提供一些會話協(xié)議必須實(shí)現(xiàn)的功能。

雖然TURN服務(wù)器的應(yīng)用能使兩個(gè)位于NAT之后的主機(jī)交流成為可能，但是這對TURN服務(wù)器來說開銷太大。因而，最后是在直接交流沒法執(zhí)行的時(shí)候，才用TURN服務(wù)器。當(dāng)客戶端與伙伴通過ICE協(xié)議來確定通信路徑的時(shí)候，ICE協(xié)議將首先通過打洞的方法來尋找一條直接的路徑來讓兩方通信，僅僅當(dāng)這條路徑找不到的時(shí)候才會用TURN服務(wù)器。

TURN原來被設(shè)計(jì)用來支持基于SIP的多媒體會話信號傳輸。

TURN被設(shè)計(jì)成ICE中的用于NAT穿越的一部分。

TURN是一個(gè)STUN的擴(kuò)展版本。大多數(shù)情況下，TURN消息是STUN格式的消息。該文檔的讀者應(yīng)該熟悉STUN協(xié)議。

2 大體看一下操作

這一節(jié)給出了TURN操作的一個(gè)預(yù)覽。

在一個(gè)傳統(tǒng)的配置中，TURN客戶端被連接到私有網(wǎng)絡(luò)中，并且通過這個(gè)一個(gè)或多個(gè)NATS連到共有網(wǎng)絡(luò)中。在這個(gè)沒有共有網(wǎng)絡(luò)中，是TURN服務(wù)器。其他的就是這個(gè)TURN客戶端想連接的同伴客戶端。這些同伴可能處在NAT的后面也可能沒有處在NAT的后面?？蛻舳擞眠@個(gè)服務(wù)器作為一個(gè)轉(zhuǎn)發(fā)來發(fā)送數(shù)據(jù)包到其他的伙伴，并且通過轉(zhuǎn)發(fā)接收來自同伴機(jī)的數(shù)據(jù)包。

圖1顯示了一個(gè)經(jīng)典的過程。這個(gè)圖中，TURN客戶端和TURN服務(wù)端被NAT分割?？蛻舳嗽谒接芯W(wǎng)絡(luò)中，服務(wù)端在公網(wǎng)中。NAT是地址端口對稱。

客戶端通過一個(gè)叫做客戶端主機(jī)傳輸?shù)刂返玫絀P地址端口對同server通話。

客戶端從它的主機(jī)傳輸?shù)刂分袀鬏擳URN消息到一個(gè)TURNServer的一個(gè)端口地址中。

由于這個(gè)客戶端位于NAT的后面，這個(gè)服務(wù)器根據(jù)客戶端在NAT的傳輸?shù)刂房吹搅藦目蛻舳酥袀骰氐陌?。這個(gè)NAT的傳輸?shù)刂方凶鯯ERVER-REFLEXIVEtransport address。

這個(gè)客戶端用TURN命令在服務(wù)端進(jìn)行了一個(gè)ALLOCATION操作。allocation是一個(gè)位于server的數(shù)據(jù)結(jié)構(gòu)體。這個(gè)數(shù)據(jù)結(jié)構(gòu)體包含了分配的RELAYED TRANSPORT ADDRESS?；锇閭兛梢酝ㄟ^這個(gè)RELAYED TRANSPORTADDRESS讓服務(wù)器轉(zhuǎn)發(fā)消息到客戶端。

只要這個(gè)allocation被創(chuàng)建，客戶端就能發(fā)送應(yīng)用程序數(shù)據(jù)到服務(wù)器，并且指明這個(gè)數(shù)據(jù)將送給那個(gè)伙伴。這樣，服務(wù)器將轉(zhuǎn)發(fā)數(shù)據(jù)島相關(guān)的伙伴。客戶端發(fā)送的應(yīng)用程序數(shù)據(jù)包含在TURN消息中。

在服務(wù)端，應(yīng)用程序?qū)?shù)據(jù)從TURN消息中取出。并將數(shù)據(jù)發(fā)送以UDP的形式發(fā)給伙伴。相反的，伙伴同樣可以以UDP的方式發(fā)送應(yīng)用程序數(shù)據(jù)到服務(wù)端分配的轉(zhuǎn)發(fā)傳輸?shù)刂?。服?wù)端將從TURN消息解析出數(shù)據(jù)，并且將這個(gè)數(shù)據(jù)發(fā)送到伙伴指定的客戶端。由于TURN消息總是包含著客戶端將發(fā)給的同伴的地址?？蛻舳丝梢杂梦ㄒ坏囊粋€(gè)allocation和多個(gè)peer通信。

當(dāng)peer位于NAT之后，客戶端必須通過peer的server-reflexive transport address辨別peer而不是host transportaddress。例如上圖，發(fā)送數(shù)據(jù)到PeerA，客戶端必須辨別192.0.2.150:32102而不是192.168.100.2:49582。

每一個(gè)allocation屬于單一的一個(gè)客戶端。并且有確切的一個(gè)relayed transport address。這樣當(dāng)一個(gè)包到達(dá)relayed transport address時(shí)，服務(wù)端知道數(shù)據(jù)將到哪個(gè)客戶端。

每個(gè)allocation屬于唯一的一個(gè)客戶端。但是一個(gè)客戶端可以有多個(gè)allocation。

2.1 Transport

TURN，就如在這個(gè)說明書中定義的那樣，總是通過UDP在服務(wù)端和peer中通信。然而TCP也允許。

2.2 Allocation

為了創(chuàng)建一個(gè)Allocation在服務(wù)端?？蛻舳税l(fā)送一個(gè)Allocate請求道服務(wù)端，服務(wù)端將回復(fù)一個(gè)Allocate Sucessresponse，這個(gè)response包含著一個(gè)allocated relayed transportaddress?？蛻舳丝梢园瑢傩缘竭@個(gè)Allocate request中，這個(gè)屬性可以描述allocation的類型（例如allocation的壽命）。

一旦relayed transport address被分配?？蛻舳吮仨毐ＷCallocation處于活躍狀態(tài)。為了達(dá)到目的，客戶端必須周期性的發(fā)送更新請求到server。更新的頻率跟allocation的壽命相關(guān)。默認(rèn)的allocation的壽命是10分鐘。這個(gè)值已經(jīng)足夠的常，以至于更新及時(shí)。