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)，如下圖所示：

7           TURN協議

7.1          為什麼會用到TURN協議

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

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

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

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

       該方法的弊端有兩個：

       所以這種使用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端口接受其他客戶端的消息