轉帖地址：http://www.cppblog.com/peakflys/archive/2013/01/25/197562.html
二、STUN方式的P2P實現
STUN是RFC3489規定的一種NAT穿透方式，它采用輔助的方法探測NAT的IP和端口。毫無疑問的，它對穿越早期的NAT起了巨大的作用，並且還將繼續在NAT穿透中占有一席之地。
STUN的探測過程需要有一個公網IP的STUN server，在NAT后面的UAC必須和此server配合，互相之間發送若干個UDP數據包。UDP包中包含有UAC需要了解的信息，比如NAT外網IP，PORT等等。UAC通過是否得到這個UDP包和包中的數據判斷自己的NAT類型。
假設有如下UAC（B），NAT（A），SERVER（C），UAC的IP為IPB，NAT的IP為 IPA ，SERVER的 IP為IPC1 、IPC2。請注意，服務器C有兩個IP，后面你會理解為什么需要兩個IP。
(1)NAT的探測過程
STEP1：
B向C的IPC1的port1端口發送一個UDP包。C收到這個包后，會把它收到包的源IP和port寫到UDP包中，然后把此包通過IP1C和port1發還給B。這個IP和port也就是NAT的外網IP和port，也就是說你在STEP1中就得到了NAT的外網IP。
熟悉NAT工作原理的應該都知道，C返回給B的這個UDP包B一定收到。如果在你的應用中，向一個STUN服務器發送數據包后，你沒有收到STUN的任何回應包，那只有兩種可能：1、STUN服務器不存在，或者你弄錯了port。2、你的NAT設備拒絕一切UDP包從外部向內部通過，如果排除防火牆限制規則，那么這樣的NAT設備如果存在，那肯定是壞了„„
當B收到此UDP后，把此UDP中的IP和自己的IP做比較，如果是一樣的，就說明自己是在公網，下步NAT將去探測防火牆類型，就不多說了(下面有圖)。如果不一樣，說明有NAT的存在，系統進行STEP2的操作。
STEP2：
B向C的IPC1發送一個UDP包，請求C通過另外一個IPC2和PORT（不同與SETP1的IP1）向B返回一個UDP數據包（現在知道為什么C要有兩個IP了吧，為了檢測cone NAT的類型）。
我們來分析一下，如果B收到了這個數據包，那說明什么？說明NAT來着不拒，不對數據包進行任何過濾，這也就是STUN標准中的full cone NAT。遺憾的是，full cone nat太少了，這也意味着你能收到這個數據包的可能性不大。如果沒收到，那么系統進行STEP3的操作。
STEP3：
B向C的IPC2的port2發送一個數據包，C收到數據包后，把它收到包的源IP和port寫到UDP包中，然后通過自己的IPC2和port2把此包發還給B。
和step1一樣，B肯定能收到這個回應UDP包。此包中的port是我們最關心的數據，下面我們來分析：
如果這個port和step1中的port一樣，那么可以肯定這個NAT是個CONE NAT，否則是對稱NAT。道理很簡單：根據對稱NAT的規則，當目的地址的IP和port有任何一個改變，那么NAT都會重新分配一個port使用，而在step3中，和step1對應，我們改變了IP和port。因此，如果是對稱NAT,那這兩個port肯定是不同的。
如果在你的應用中，到此步的時候PORT是不同的，那就只能放棄P2P了，原因同上面實現中的一樣。如果不同，那么只剩下了restrict cone 和port restrict cone。系統用step4探測是是那一種。
STEP4：
B向C的IP2的一個端口PD發送一個數據請求包，要求C用IP2和不同於PD的port返回一個數據包給B。
我們來分析結果：如果B收到了，那也就意味着只要IP相同，即使port不同，NAT也允許UDP包通過。顯然這是restrict cone NAT。如果沒收到，沒別的好說，port restrict NAT.
協議實現的算法運行圖如下：
一旦路經到達紅色節點時，UDP的溝通是沒有可能性的(peakflys注：准備來說除了包被防火牆blocked之外，其他情況也是有可能建立P2P的，只是代價太大，一般放棄)。一旦通過黃色或是綠色的節點，就有連接的可能。
最終通過STUN服務器得到自己的NAT類型和公網IP、Port，以后建立P2P時就非常容易了
peakflys注：Libjingle正是通過ICE&STUN方式，建立的P2P連接。關於libjingle的介紹，待續……
轉帖地址：http://www.cppblog.com/peakflys/archive/2013/01/25/197562.html