1? ? ? ?說(shuō)明

2?????? 打洞和穿越的概念... 1

3?????? P2P中的打洞和穿越... 2

4?????? 使用STUN系列 協(xié)議穿越的特點(diǎn)... 2

5?????? STUN/ TURN/ICE協(xié)議的關(guān)系... 3

6?????? STUN協(xié)議(RFC 5389) 3

? ? ? ??6.1 ? ? ? ? ? ??為什么會(huì)用到STUN協(xié)議... 3

? ? ? ??6.2 ? ? ? ? ? ??STUN協(xié)議的工作原理... 4

7?????? TURN協(xié)議... 4

? ? ? ??7.1???????????? 為什么會(huì)用到TURN協(xié)議... 4

? ? ? ??7.2???????????? TURN協(xié)議的工作原理... 5

? ? ? ??? ? ? ??7.2.1???????? Allocate請(qǐng)求... 5

? ? ? ??? ? ? ??7.2.2???????? Relay端口消息的轉(zhuǎn)發(fā)... 6

? ? ? ?? ? ? ??? ? ? ???7.2.2.1??? A的Relay端口接受其他客戶端的消息... 6

? ? ? ??? ? ? ??? ? ? ??7.2.2.2??? A的響應(yīng)消息原路返回... 6

? ? ? ??? ? ? ??? ? ? ??7.2.2.3???? 思考... 7

? ? ? ??? ? ? ??7.2.3???????? Refresh請(qǐng)求... 7

? ? ? ??? ? ? ??7.2.4???????? STUN端口的保活... 8

? ? ? ??? ? ? ??7.2.5???????? Relay轉(zhuǎn)發(fā)的時(shí)候添加STUN頭（Send和Data請(qǐng)求）... 8

? ? ? ??? ? ? ??7.2.6???????? 使用TURN協(xié)議的必要性... 9

8?????? ICE協(xié)議... 9

? ? ? ??8.1???????????? 打洞原理... 9

? ? ? ??8.2???????????? ICE的打洞... 10

? ? ? ??8.3???????????? ICE的打洞的4次握手... 11

? ? ? ??8.4???????????? ICE擴(kuò)展的Binding消息... 12

? ? ? ??8.5???????????? REGULAR NOMINATION 和 AGGRESSIVE NOMINATION.. 12

? ? ? ??8.6???????????? Peer Reflexive. 13

? ? ? ??? ? ? ??8.6.1???????? Peer Reflexive Candidates的概念... 13

? ? ? ??? ? ? ??8.6.2???????? Peer Reflexive Candidates的發(fā)現(xiàn)... 13

? ? ? ?? ? ? ???? ? ? ??8.6.2.1???? 當(dāng)通信雙方處在不同層次的NAT下的情況... 14

? ? ? ??? ? ? ??? ? ? ??8.6.2.2???? 與NAT的類(lèi)型相關(guān)... ...15

? ? ? ??? ? ? ??? ? ? ??8.6.2.3???? 其他情況... ...16

? ? ? ??? ? ? ??? ? ? ??8.6.2.4???? 公網(wǎng)P2P中的Peer Reflexive. ...16

9?????? ICE在SIP中的應(yīng)用... 16

? ? ? ??9.1???????????? 呼叫雙方分別收集3組地址...... 17

? ? ? ??9.1???????????? A發(fā)送INVITE給B. ...18

? ? ? ??9.2???????????? B給A回100、101、180. ...18

? ? ? ??9.3???????????? B給A回200 ok. ...19

? ? ? ??9.4? ? ? ? ? ? ?A給B回ACK?? ...19

?

? ? ? ?上個(gè)禮拜寫(xiě)了第1、2、3、4、5，今天把6、7也寫(xiě)完了，另外也總結(jié)了第8和第9，準(zhǔn)備再分兩次發(fā)布。

? ? ? ?關(guān)于第1、2、3、4、5 請(qǐng)查看： STUN/TURN/ICE協(xié)議在P2P SIP中的應(yīng)用（一）

? ? ? ?本次書(shū)接上回，現(xiàn)在開(kāi)始。

---------------------------------------------------------------------------------------------------------------------------

? ? ? ??

6?????????? STUN協(xié)議(RFC 5389)

6.1????????? 為什么會(huì)用到STUN協(xié)議

? ? ???首先要明確的概念是：STUN協(xié)議沒(méi)有穿越的能力，它只是為穿越提供反射地址(Server Reflexive Address)。在雙方進(jìn)行通訊的時(shí)候，我們雙方的目的地址可以分別為對(duì)方的反射地址，但是反射地址不能穿越成功的時(shí)候（NAT類(lèi)型為對(duì)稱(chēng)類(lèi)型的時(shí)候），必須使用TURN。

?????? 本文所說(shuō)的STUN協(xié)議指的是RFC(5389) ，RFC(5389)已經(jīng)移除了NAT類(lèi)型探測(cè)的能力（RFC(3489)定義了NAT類(lèi)型探測(cè)的能力），STUN協(xié)議主要有2個(gè)功能：

• 讓一個(gè)位于NAT后的客戶端得到自己的公網(wǎng)地址(反射地址，Server Reflexive Address)，該功能通過(guò)向服務(wù)端發(fā)送一個(gè) Binding請(qǐng)求，服務(wù)端返回一個(gè)success response消息來(lái)完成。success response消息中包含一個(gè)叫做XOR-MAPPED-ADDRESS的屬性，該屬性的值就是“反射地址”經(jīng)過(guò)異或后的值

?

• 在ICE(交互式連接建立)時(shí)，用于探測(cè)雙方的連通性。該功能也是通過(guò)向?qū)Ψ娇蛻舳税l(fā)送Binding消息，對(duì)方響應(yīng)該請(qǐng)求實(shí)現(xiàn)。需要說(shuō)明一點(diǎn)的是，在ICE交互時(shí)的Binding消息與1中所說(shuō)的Binding消息不一樣。ICE添加了幾個(gè)新的屬性，從而擴(kuò)展了Binding消息：PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, ICE-CONTROLLING。這種擴(kuò)展了的Binding消息，只會(huì)用在ICE的探測(cè)中。

6.2????????? STUN協(xié)議的工作原理

A. ? ?? 客戶端用于得到自己的外網(wǎng)地址( 反射地址，Server Reflexive Address) ，如下圖所示 ：

a)???????? 客戶端A向STUN Port發(fā)送Binding請(qǐng)求(圖中綠色部分)

b)??????? STUN服務(wù)器接收到客戶端A的Binding請(qǐng)求，它能得到該請(qǐng)求的源地址與端口(該地址和端口就是經(jīng)過(guò)NAT映射過(guò)的)，將該地址和端口記為Server Reflexive Address。

c)???????? STUN服務(wù)器發(fā)送response響應(yīng)，在response響應(yīng)中攜將Server Reflexive Address經(jīng)過(guò)異或后填入XOR-MAPPED-ADDRESS屬性。

d)???????? 客戶端A接受到STUN服務(wù)器的response后，就知道了自己的外網(wǎng)地址(反射地址，Server Reflexive Address)。

?

B.????? 在ICE( 交互式連接建立) 是，用于雙方的連通性探測(cè)。

在ICE打洞探測(cè)的時(shí)候再詳細(xì)介紹

7?????????? TURN協(xié)議

7.1????????? 為什么會(huì)用到TURN協(xié)議

?????? 前面也提到過(guò)，TURN協(xié)議是STUN 協(xié)議的有效補(bǔ)充，在使用反射地址（Server Reflexive Address）穿越方式失敗的時(shí)候才會(huì)用到TURN。

?????? 簡(jiǎn)單的說(shuō)就是，TURN協(xié)議使用中轉(zhuǎn)的方式實(shí)現(xiàn)位于兩個(gè)不同NAT后的客戶端通信。TURN協(xié)議為每個(gè)連接到該服務(wù)器的客戶端都分配一個(gè)公網(wǎng)地址(Relayed? Address)，該Relayed地址專(zhuān)門(mén)為該客戶端中轉(zhuǎn)消息。

?????? 該方法是實(shí)現(xiàn)位于兩個(gè)不同NAT后的客戶端通信的一個(gè)方式（其他方式還有p2p）。

?????? 該方法的優(yōu)點(diǎn)是：不管NAT是什么類(lèi)型(NAT類(lèi)型分為：全錐形、地址限制錐形、端口限制錐形、對(duì)稱(chēng)型)，都可以通過(guò)這種方式實(shí)現(xiàn)兩個(gè)客戶端的通信。

?????? 該方法的弊端有兩個(gè)：

1. 第一個(gè)是，如果通信兩端傳輸?shù)臄?shù)據(jù)量過(guò)大（比如客戶端之間傳輸?shù)氖且粢曨l），那么每個(gè)數(shù)據(jù)包都要經(jīng)過(guò)TURN服務(wù)器的轉(zhuǎn)發(fā)，那么會(huì)造成數(shù)據(jù)的丟失以及傳送時(shí)延的增加；
2. 第二個(gè)是，成本問(wèn)題，如果每?jī)蓚€(gè)客戶端之間的通信都要經(jīng)過(guò)TURN轉(zhuǎn)發(fā)，那么在客戶端到達(dá)一定規(guī)模后（十萬(wàn)上百萬(wàn)），需要架設(shè)大量的TURN服務(wù)器。這在成本上是無(wú)法承受的。所以才有了使用P2P方式。需要說(shuō)明的有一點(diǎn)，雙方可以進(jìn)行點(diǎn)對(duì)點(diǎn)的直接通信，不是因?yàn)樗鼈冎g點(diǎn)對(duì)點(diǎn)通信后丟包和時(shí)延問(wèn)題就能解決(P2P方式也可能有比較大的丟包)，而是成本問(wèn)題。

? ? ???所以這種使用TURN協(xié)議中轉(zhuǎn)的方式只會(huì)用在雙方通信交互內(nèi)容數(shù)據(jù)量較少的情況下。

7.2????????? TURN協(xié)議的工作原理

? ? ???本節(jié)描述了TURN協(xié)議的大體工作原理，與RFC 5766有一定的出入，了解了此工作原理再去看RFC 5766 會(huì)事半功倍。本節(jié)介紹不涉及到RFC 5766中提到的，CreatePermission、ChannelBind操作。

7.2.1????????? Allocate請(qǐng)求

? ? ???客戶端通過(guò)發(fā)送Allocate請(qǐng)求給STUN服務(wù)器，從而讓STUN服務(wù)器為A用戶開(kāi)啟一個(gè)relay端口。

?

? ? ???a)???????? 客戶端A向STUN Port發(fā)送Allocate請(qǐng)求(圖中綠色部分)

? ? ???b)??????? STUN服務(wù)器接收到客戶端A的Allocate請(qǐng)求，服務(wù)器一看是Allocate請(qǐng)求，則根據(jù)relay端口分配策略為A分配一個(gè)端口。

? ? ???c)???????? 服務(wù)器發(fā)送response成功響應(yīng)。在該response中包含XOR-RELAYED-ADDRESS屬性。該屬性值就是A的relay端口的異或結(jié)果。

? ? ???d)???????? 客戶端接收到response后，就知道了自己的relay地址。該relay地址是個(gè)公網(wǎng)地址，可以看作是客戶端A在公網(wǎng)上的一個(gè)代理，任何想要聯(lián)系A(chǔ)的客戶? ? ???端，只要將數(shù)據(jù)發(fā)送到A的relay地址就可以了，具體的轉(zhuǎn)發(fā)原理請(qǐng)看下一小節(jié)。

7.2.2????????? Relay端口消息的轉(zhuǎn)發(fā)

? ? ???任何想要聯(lián)系客戶端A的人，只要知道客戶端A的relay地址就可以了。

7.2.2.1???????? A的Relay端口接受其他客戶端的消息

?

?????? 如上圖所示：因?yàn)榭蛻舳薃位于NAT后，所以其他客戶端無(wú)法和A建立直接的通信。但是客戶端A在STUN服務(wù)器上申請(qǐng)了一個(gè)端口(上圖中：A的relay端口)，其他客戶端想要和A通信，那么只需要將信息發(fā)送到“A的relay端口”，STUN服務(wù)器會(huì)將從relay端口接收到的信息通過(guò)STUN Port發(fā)送給A。

7.2.2.2???????? A的響應(yīng)消息原路返回

? ? ???A應(yīng)答其他客戶端發(fā)來(lái)的消息的時(shí)候，是通過(guò)原路返回的。

?

?

7.2.2.3???????? 思考

? ? ? ?1.STUN服務(wù)器為什么不直接從A的relay端口把數(shù)據(jù)轉(zhuǎn)發(fā)給A呢（如下圖所示）？而非要從STUN端口發(fā)送？

? ? ? ? ? ? ?

? ? ? ?2.客戶端A的響應(yīng)消息在原路返回的時(shí)候，A的響應(yīng)消息是先發(fā)送到了STUN Port，然后再經(jīng)由A的relay Port發(fā)出的。那么A的relay Port是怎么知道它要把數(shù)據(jù)發(fā)送到哪呢？

?

?????? 請(qǐng)看7.2.4 和 7.2.5

7.2.3????????? Refresh請(qǐng)求

? ? ???STUN服務(wù)器給客戶端A分配的relay地址都具有一定的有效時(shí)長(zhǎng)，可能是30秒或者1分鐘或者幾十分鐘。客戶端如果需要STUN服務(wù)器一直為它開(kāi)啟這個(gè)端口，就需要定時(shí)的向STUN服務(wù)器發(fā)送請(qǐng)求，該請(qǐng)求用刷新relay端口的剩余時(shí)間。

? ? ???在標(biāo)準(zhǔn)的TURN（RFC 5766）協(xié)議中，客戶端A向STUN服務(wù)器發(fā)送Allocate請(qǐng)求，STUN服務(wù)器在響應(yīng)消息中添加了一個(gè)“LifeTime”的屬性，該屬性表示relay的存活時(shí)間。 客戶端需要在relay的存活時(shí)間內(nèi)周期性的調(diào)用REFRESH請(qǐng)求，服務(wù)端接收到REFRESH請(qǐng)求后，刷新剩余時(shí)間；當(dāng)REFRESH請(qǐng)求中的lifetime屬性為0時(shí)，說(shuō)明是客戶端主動(dòng)要求關(guān)閉relay地址。

7.2.4????????? STUN端口的保活

? ? ???由于與STUN服務(wù)器通信使用的是UDP，所以為了保持一個(gè)長(zhǎng)連接，需要客戶端周期性的向STUN服務(wù)器的STUN Port發(fā)送心跳包。

? ? ???周期性心跳包的目的就是，使得NAT設(shè)備對(duì)客戶端A的反射地址(Server Reflexive Address)一直有效。使得從STUN Port發(fā)送的數(shù)據(jù)能通過(guò)A的反射地址到達(dá)A。此處不理解的可以查閱“NAT 類(lèi)型的分類(lèi)以及NAT的作用”。

? ? ???此處解釋了，7.2.2.3中的第一個(gè)問(wèn)題，因?yàn)榭蛻舳薃沒(méi)有和relay Port保活，又由于NAT的特性，數(shù)據(jù)直接通過(guò)relay port轉(zhuǎn)發(fā)給A時(shí)，NAT直接就丟棄了，所以A是收不到的。所以數(shù)據(jù)必須經(jīng)過(guò)STUN服務(wù)器的STUN ?Port發(fā)送。

7.2.5????????? Relay轉(zhuǎn)發(fā)的時(shí)候添加STUN頭（Send和Data請(qǐng)求）

? ? ???將7.2.2.1、 7.2.2.2合并到一起就是：

?

?

? ? ???如上圖所示是B主動(dòng)給A發(fā)消息：“Hello”，A回應(yīng)“Hi”的過(guò)程。

? ? ???序號(hào)1、2、3、4、5為B的發(fā)送請(qǐng)求(藍(lán)色箭頭方向)；

? ? ???序號(hào)6、7、8、9、10為A的回應(yīng)，原路返回（綠色箭頭方向）。

? ? ???注意：在“Hello”發(fā)送的過(guò)程中，1、2階段時(shí)，發(fā)送的數(shù)據(jù)為裸的UDP數(shù)據(jù)。在4、5過(guò)程中，是被STUN協(xié)議包裝過(guò)的“Hello”，稱(chēng)之為Data indication。

? ? ???同樣在“Hi”發(fā)送的過(guò)程中，6、7階段為被STUN協(xié)議包裝過(guò)的“Hi”，稱(chēng)之為Send indication，9、10是裸的UDP數(shù)據(jù)。

? ? ???在4、5階段，由于數(shù)據(jù)是從STUN Port轉(zhuǎn)發(fā)下來(lái)的，為了能夠讓客戶端A知道這個(gè)包是哪個(gè)客戶端發(fā)來(lái)的，所以，STUN 協(xié)議對(duì)“Hello”進(jìn)行了重新的包裝，最主要的就是添加了一個(gè)XOR-PEER-ADDRESS屬性，由裸數(shù)據(jù)包裝成STUN協(xié)議的過(guò)程，我們稱(chēng)之為添加了STUN頭。XOR-PEER-ADDRESS的內(nèi)容就是客戶端B的反射地址（Server Reflexive Address）。

? ? ???在6、7階段，A的響應(yīng)原路返回，為了能夠讓A的relay port知道最終發(fā)往哪個(gè)客戶端，因此也為“Hi”添加了STUN頭，也是添加了XOR-PEER-ADDRESS屬性，內(nèi)容就是客戶端B的反射地址（Server Reflexive Address）。這樣A的relay port就知道“Hi”的目的地址。

? ? ???第3階段是：從A的relay端口收到數(shù)據(jù)，添加STUN頭后，最后從STUN Port 發(fā)出的過(guò)程。

? ? ???第8階段是：從STUN Port 接收到帶STUN 頭的數(shù)據(jù)，去掉STUN頭，最后從A的relay端口發(fā)出的過(guò)程。

? ? ???此處解釋了7.2.2.3 的第二個(gè)問(wèn)題。

?

? ? ???客戶端B主動(dòng)發(fā)送信息給A的交互流程如上圖所示，那么客戶端A主動(dòng)發(fā)送信息給客戶端B的交互流程是怎樣的呢，你能畫(huà)出來(lái)嗎？

? ? ???要知道客戶端A主動(dòng)發(fā)消息給客戶端B，應(yīng)該將消息發(fā)往客戶端B的relay port哦。。

7.2.6????????? 使用TURN協(xié)議的必要性

? ? ???要想實(shí)現(xiàn)消息的中轉(zhuǎn)，必須使用TURN協(xié)議嗎？答案當(dāng)然是否定的。

? ? ???TURN協(xié)議只是一種公認(rèn)的，標(biāo)準(zhǔn)的協(xié)議。我們當(dāng)然可以實(shí)現(xiàn)自己的協(xié)議，但是已經(jīng)有人對(duì)標(biāo)準(zhǔn)的TURN協(xié)議進(jìn)行了實(shí)現(xiàn)(比如pjproject，它實(shí)現(xiàn)了STUN、TURN、ICE、SIP)，我們?yōu)槭裁床荒脕?lái)就用呢？

? ? ???在拿來(lái)就用的過(guò)程中，肯定會(huì)對(duì)已經(jīng)實(shí)現(xiàn)的標(biāo)準(zhǔn)做一定的改動(dòng)。但這關(guān)系不大，實(shí)現(xiàn)我們所關(guān)注的功能即可。

?

? ? ? 本文為原創(chuàng)，轉(zhuǎn)載請(qǐng)注明以下內(nèi)容：

　　名稱(chēng)：STUN/TURN/ICE協(xié)議在P2P SIP中的應(yīng)用（二）

　　作者：大雪先生

　　鏈接：http://www.cnblogs.com/ishangs/p/3816689.html

STUN/TURN/ICE協(xié)議在P2P SIP中的應(yīng)用（二）