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類型分為：全錐形、地址限制錐形、端口限制錐形、對稱型)，都可以通過這種方式實現兩個客戶端的通信。
該方法的弊端有兩個：
- 第一個是，如果通信兩端傳輸的數據量過大（比如客戶端之間傳輸的是音視頻），那么每個數據包都要經過TURN服務器的轉發，那么會造成數據的丟失以及傳送時延的增加；
- 第二個是，成本問題，如果每兩個客戶端之間的通信都要經過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