1? ? ? ?說明

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

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

4?????? 使用STUN系列 協議穿越的特點... 2

5?????? STUN/ TURN/ICE協議的關系... 3

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

? ? ? ??6.1 ? ? ? ? ? ??為什么會用到STUN協議... 3

? ? ? ??6.2 ? ? ? ? ? ??STUN協議的工作原理... 4

7?????? TURN協議... 4

? ? ? ??7.1???????????? 為什么會用到TURN協議... 4

? ? ? ??7.2???????????? TURN協議的工作原理... 5

? ? ? ??? ? ? ??7.2.1???????? Allocate請求... 5

? ? ? ??? ? ? ??7.2.2???????? Relay端口消息的轉發... 6

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

? ? ? ??? ? ? ??? ? ? ??7.2.2.2??? A的響應消息原路返回... 6

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

? ? ? ??? ? ? ??7.2.3???????? Refresh請求... 7

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

? ? ? ??? ? ? ??7.2.5???????? Relay轉發的時候添加STUN頭（Send和Data請求）... 8

? ? ? ??? ? ? ??7.2.6???????? 使用TURN協議的必要性... 9

8?????? ICE協議... 9

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

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

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

? ? ? ??8.4???????????? ICE擴展的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的發現... 13

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

? ? ? ??? ? ? ??? ? ? ??8.6.2.2???? 與NAT的類型相關... ...15

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

? ? ? ??? ? ? ??? ? ? ??8.6.2.4???? 公網P2P中的Peer Reflexive. ...16

9?????? ICE在SIP中的應用... 16

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

? ? ? ??9.1???????????? A發送INVITE給B. ...18

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

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

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

?

? ? ? ?上個禮拜寫了第1、2、3、4、5，今天把6、7也寫完了，另外也總結了第8和第9，準備再分兩次發布。

? ? ? ?關于第1、2、3、4、5 請查看： STUN/TURN/ICE協議在P2P SIP中的應用（一）

? ? ? ?本次書接上回，現在開始。

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

? ? ? ??

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

6.1????????? 為什么會用到STUN協議

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

?????? 本文所說的STUN協議指的是RFC(5389) ，RFC(5389)已經移除了NAT類型探測的能力（RFC(3489)定義了NAT類型探測的能力），STUN協議主要有2個功能：

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

?

• 在ICE(交互式連接建立)時，用于探測雙方的連通性。該功能也是通過向對方客戶端發送Binding消息，對方響應該請求實現。需要說明一點的是，在ICE交互時的Binding消息與1中所說的Binding消息不一樣。ICE添加了幾個新的屬性，從而擴展了Binding消息：PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, ICE-CONTROLLING。這種擴展了的Binding消息，只會用在ICE的探測中。

6.2????????? STUN協議的工作原理

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

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

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

c)???????? STUN服務器發送response響應，在response響應中攜將Server Reflexive Address經過異或后填入XOR-MAPPED-ADDRESS屬性。

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

?

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

在ICE打洞探測的時候再詳細介紹

7?????????? TURN協議

7.1????????? 為什么會用到TURN協議

?????? 前面也提到過，TURN協議是STUN 協議的有效補充，在使用反射地址（Server Reflexive Address）穿越方式失敗的時候才會用到TURN。

?????? 簡單的說就是，TURN協議使用中轉的方式實現位于兩個不同NAT后的客戶端通信。TURN協議為每個連接到該服務器的客戶端都分配一個公網地址(Relayed? Address)，該Relayed地址專門為該客戶端中轉消息。

?????? 該方法是實現位于兩個不同NAT后的客戶端通信的一個方式（其他方式還有p2p）。

?????? 該方法的優點是：不管NAT是什么類型(NAT類型分為：全錐形、地址限制錐形、端口限制錐形、對稱型)，都可以通過這種方式實現兩個客戶端的通信。

?????? 該方法的弊端有兩個：

1. 第一個是，如果通信兩端傳輸的數據量過大（比如客戶端之間傳輸的是音視頻），那么每個數據包都要經過TURN服務器的轉發，那么會造成數據的丟失以及傳送時延的增加；
2. 第二個是，成本問題，如果每兩個客戶端之間的通信都要經過TURN轉發，那么在客戶端到達一定規模后（十萬上百萬），需要架設大量的TURN服務器。這在成本上是無法承受的。所以才有了使用P2P方式。需要說明的有一點，雙方可以進行點對點的直接通信，不是因為它們之間點對點通信后丟包和時延問題就能解決(P2P方式也可能有比較大的丟包)，而是成本問題。

? ? ???所以這種使用TURN協議中轉的方式只會用在雙方通信交互內容數據量較少的情況下。

7.2????????? TURN協議的工作原理

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

7.2.1????????? Allocate請求

? ? ???客戶端通過發送Allocate請求給STUN服務器，從而讓STUN服務器為A用戶開啟一個relay端口。

?

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

? ? ???b)??????? STUN服務器接收到客戶端A的Allocate請求，服務器一看是Allocate請求，則根據relay端口分配策略為A分配一個端口。

? ? ???c)???????? 服務器發送response成功響應。在該response中包含XOR-RELAYED-ADDRESS屬性。該屬性值就是A的relay端口的異或結果。

? ? ???d)???????? 客戶端接收到response后，就知道了自己的relay地址。該relay地址是個公網地址，可以看作是客戶端A在公網上的一個代理，任何想要聯系A的客戶? ? ???端，只要將數據發送到A的relay地址就可以了，具體的轉發原理請看下一小節。

7.2.2????????? Relay端口消息的轉發

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

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

?

?????? 如上圖所示：因為客戶端A位于NAT后，所以其他客戶端無法和A建立直接的通信。但是客戶端A在STUN服務器上申請了一個端口(上圖中：A的relay端口)，其他客戶端想要和A通信，那么只需要將信息發送到“A的relay端口”，STUN服務器會將從relay端口接收到的信息通過STUN Port發送給A。

7.2.2.2???????? A的響應消息原路返回

? ? ???A應答其他客戶端發來的消息的時候，是通過原路返回的。

?

?

7.2.2.3???????? 思考

? ? ? ?1.STUN服務器為什么不直接從A的relay端口把數據轉發給A呢（如下圖所示）？而非要從STUN端口發送？

? ? ? ? ? ? ?

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

?

?????? 請看7.2.4 和 7.2.5

7.2.3????????? Refresh請求

? ? ???STUN服務器給客戶端A分配的relay地址都具有一定的有效時長，可能是30秒或者1分鐘或者幾十分鐘。客戶端如果需要STUN服務器一直為它開啟這個端口，就需要定時的向STUN服務器發送請求，該請求用刷新relay端口的剩余時間。

? ? ???在標準的TURN（RFC 5766）協議中，客戶端A向STUN服務器發送Allocate請求，STUN服務器在響應消息中添加了一個“LifeTime”的屬性，該屬性表示relay的存活時間。 客戶端需要在relay的存活時間內周期性的調用REFRESH請求，服務端接收到REFRESH請求后，刷新剩余時間；當REFRESH請求中的lifetime屬性為0時，說明是客戶端主動要求關閉relay地址。

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

? ? ???由于與STUN服務器通信使用的是UDP，所以為了保持一個長連接，需要客戶端周期性的向STUN服務器的STUN Port發送心跳包。

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

? ? ???此處解釋了，7.2.2.3中的第一個問題，因為客戶端A沒有和relay Port保活，又由于NAT的特性，數據直接通過relay port轉發給A時，NAT直接就丟棄了，所以A是收不到的。所以數據必須經過STUN服務器的STUN ?Port發送。

7.2.5????????? Relay轉發的時候添加STUN頭（Send和Data請求）

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

?

?

? ? ???如上圖所示是B主動給A發消息：“Hello”，A回應“Hi”的過程。

? ? ???序號1、2、3、4、5為B的發送請求(藍色箭頭方向)；

? ? ???序號6、7、8、9、10為A的回應，原路返回（綠色箭頭方向）。

? ? ???注意：在“Hello”發送的過程中，1、2階段時，發送的數據為裸的UDP數據。在4、5過程中，是被STUN協議包裝過的“Hello”，稱之為Data indication。

? ? ???同樣在“Hi”發送的過程中，6、7階段為被STUN協議包裝過的“Hi”，稱之為Send indication，9、10是裸的UDP數據。

? ? ???在4、5階段，由于數據是從STUN Port轉發下來的，為了能夠讓客戶端A知道這個包是哪個客戶端發來的，所以，STUN 協議對“Hello”進行了重新的包裝，最主要的就是添加了一個XOR-PEER-ADDRESS屬性，由裸數據包裝成STUN協議的過程，我們稱之為添加了STUN頭。XOR-PEER-ADDRESS的內容就是客戶端B的反射地址（Server Reflexive Address）。

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

? ? ???第3階段是：從A的relay端口收到數據，添加STUN頭后，最后從STUN Port 發出的過程。

? ? ???第8階段是：從STUN Port 接收到帶STUN 頭的數據，去掉STUN頭，最后從A的relay端口發出的過程。

? ? ???此處解釋了7.2.2.3 的第二個問題。

?

? ? ???客戶端B主動發送信息給A的交互流程如上圖所示，那么客戶端A主動發送信息給客戶端B的交互流程是怎樣的呢，你能畫出來嗎？

? ? ???要知道客戶端A主動發消息給客戶端B，應該將消息發往客戶端B的relay port哦。。

7.2.6????????? 使用TURN協議的必要性

? ? ???要想實現消息的中轉，必須使用TURN協議嗎？答案當然是否定的。

? ? ???TURN協議只是一種公認的，標準的協議。我們當然可以實現自己的協議，但是已經有人對標準的TURN協議進行了實現(比如pjproject，它實現了STUN、TURN、ICE、SIP)，我們為什么不拿來就用呢？

? ? ???在拿來就用的過程中，肯定會對已經實現的標準做一定的改動。但這關系不大，實現我們所關注的功能即可。

?

? ? ? 本文為原創，轉載請注明以下內容：

　　名稱：STUN/TURN/ICE協議在P2P SIP中的應用（二）

　　作者：大雪先生

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

STUN/TURN/ICE協議在P2P SIP中的應用（二）