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

標籤：

轉載：http://www.cnblogs.com/ishangs/p/3816689.html

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

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中的應用（二）