首先先介紹一些基本概念：
NAT(Network Address Translators)，網絡地址轉換：網絡地址轉換是在IP地址日益缺少的狀況下產生的，它的主要目的就是爲了可以地址重用。NAT從歷史發展上分爲兩大類，基本的NAT和NAPT(Network Address/Port Translator)。
最早提出的是基本的NAT(peakflys注：剛開始其實只是路由器上的一個功能模塊)，它的產生基於以下事實：一個私有網絡（域）中的節點中只有不多的節點須要與外網鏈接（這是在上世紀90年代中期提出的）。那麼這個子網中其實只有少數的節點須要全球惟一的IP地址，其餘的節點的IP地址應該是能夠重用的。
所以，基本的NAT實現的功能很簡單，在子網內使用一個保留的IP子網段，這些IP對外是不可見的。子網內只有少數一些IP地址能夠對應到真正全球惟一的IP地址。若是這些節點須要訪問外部網絡，那麼基本NAT就負責將這個節點的子網內IP轉化爲一個全球惟一的IP而後發送出去。(基本的NAT會改變IP包中的原IP地址，可是不會改變IP包中的端口)
關於基本的NAT能夠參看RFC 1631
另一種NAT叫作NAPT，從名稱上咱們也能夠看得出，NAPT不但會改變通過這個NAT設備的IP數據報的IP地址，還會改變IP數據報的TCP/UDP端口。基本NAT的設備可能咱們見的很少（基本已經淘汰了），NAPT纔是咱們真正須要關注的。看下圖：
有一個私有網絡10.*.*.*，Client A是其中的一臺計算機，這個網絡的網關（一個NAT設備）的外網IP是155.99.25.11(應該還有一個內網的IP地址，好比10.0.0.10)。若是Client A中的某個進程（這個進程建立了一個UDP Socket,這個Socket綁定1234端口）想訪問外網主機18.181.0.31的1235端口，那麼當數據包經過NAT時會發生什麼事情呢？
有一個私有網絡10.*.*.*，Client A是其中的一臺計算機，這個網絡的網關（一個NAT設備）的外網IP是155.99.25.11(應該還有一個內網的IP地址，好比10.0.0.10)。若是Client A中的某個進程（這個進程建立了一個UDP Socket,這個Socket綁定1234端口）想訪問外網主機18.181.0.31的1235端口，那麼當數據包經過NAT時會發生什麼事情呢？
首先NAT會改變這個數據包的原IP地址，改成155.99.25.11。接着NAT會爲這個傳輸建立一個Session（Session是一個抽象的概念，若是是TCP，也許Session是由一個SYN包開始，以一個FIN包結束。而UDP呢，以這個IP的這個端口的第一個UDP開始，結束呢，呵呵，也許是幾分鐘，也許是幾小時，這要看具體的實現了）而且給這個Session分配一個端口，好比62000，而後改變這個數據包的源端口爲62000。因此原本是
（10.0.0.1:1234->18.181.0.31:1235）的數據包到了互聯網上變爲了（155.99.25.11:62000->18.181.0.31:1235）。
一旦NAT建立了一個Session後，NAT會記住62000端口對應的是10.0.0.1的1234端口，之後從18.181.0.31發送到62000端口的數據會被NAT自動的轉發到10.0.0.1上。（注意：這裏是說18.181.0.31發送到62000端口的數據會被轉發，其餘的IP發送到這個端口的數據將被NAT拋棄）這樣Client A就與Server S1創建以了一個鏈接。
上面的是一些基礎知識，下面的纔是關鍵的部分了。
看看下面的狀況：
接上面的例子，若是Client A的原來那個Socket(綁定了1234端口的那個UDP Socket)又接着向另一個Server S2發送了一個UDP包，那麼這個UDP包在經過NAT時會怎麼樣呢？
接上面的例子，若是Client A的原來那個Socket(綁定了1234端口的那個UDP Socket)又接着向另一個Server S2發送了一個UDP包，那麼這個UDP包在經過NAT時會怎麼樣呢？
這時可能會有兩種狀況發生，一種是NAT再次建立一個Session，而且再次爲這個Session分配一個端口號（好比：62001）。另一種是NAT再次建立一個Session，可是不會新分配一個端口號，而是用原來分配的端口號62000。前一種NAT叫作Symmetric NAT，後一種叫作Cone NAT。若是你的NAT恰好是第一種，那麼極可能會有不少P2P軟件失靈。（能夠慶幸的是，如今絕大多數的NAT屬於後者，即Cone NAT）
peakflys注：Cone NAT具體又分爲3種：
(1)全克隆( Full Cone) : NAT把全部來自相同內部IP地址和端口的請求映射到相同的外部IP地址和端口。任何一個外部主機都可經過該映射發送IP包到該內部主機。
(2)限制性克隆(Restricted Cone) : NAT把全部來自相同內部IP地址和端口的請求映射到相同的外部IP地址和端口。可是,只有當內部主機先給IP地址爲X的外部主機發送IP包,該外部主機才能向該內部主機發送IP包。
(3)端口限制性克隆( Port Restricted Cone) :端口限制性克隆與限制性克隆相似,只是多了端口號的限制,即只有內部主機先向IP地址爲X,端口號爲P的外部主機發送1個IP包,該外部主機纔可以把源端口號爲P的IP包發送給該內部主機。
好了，咱們看到，經過NAT,子網內的計算機向外連結是很容易的（NAT至關於透明的，子網內的和外網的計算機不用知道NAT的狀況）。
可是若是外部的計算機想訪問子網內的計算機就比較困難了（而這正是P2P所須要的）。
那麼咱們若是想從外部發送一個數據報給內網的計算機有什麼辦法呢？首先，咱們必須在內網的NAT上打上一個「洞」（也就是前面咱們說的在NAT上創建一個Session），這個洞不能由外部來打，只能由內網內的主機來打。並且這個洞是有方向的，好比從內部某臺主機（好比：192.168.0.10）向外部的某個IP(好比：219.237.60.1)發送一個UDP包，那麼就在這個內網的NAT設備上打了一個方向爲219.237.60.1的「洞」，（這就是稱爲UDP Hole Punching的技術）之後219.237.60.1就能夠經過這個洞與內網的192.168.0.10聯繫了。（可是其餘的IP不能利用這個洞）。
P2P的經常使用實現
1、普通的直連式P2P實現
經過上面的理論，實現兩個內網的主機通信就差最後一步了：那就是雞生蛋仍是蛋生雞的問題了，兩邊都沒法主動發出鏈接請求，誰也不知道誰的公網地址，那咱們如何來打這個洞呢？咱們須要一箇中間人來聯繫這兩個內網主機。
如今咱們來看看一個P2P軟件的流程，如下圖爲例：
首先，Client A登陸服務器，NAT A爲此次的Session分配了一個端口60000，那麼Server S收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網地址了。一樣，Client B登陸Server S，NAT B給這次Session分配的端口是40000，那麼Server S收到的B的地址是187.34.1.56:40000。
此時，Client A與Client B均可以與Server S通訊了。若是Client A此時想直接發送信息給Client B，那麼他能夠從Server S那兒得到B的公網地址187.34.1.56:40000，是否是Client A向這個地址發送信息Client B就能收到了呢？答案是不行，由於若是這樣發送信息，NAT B會將這個信息丟棄（由於這樣的信息是不請自來的，爲了安全，大多數NAT都會執行丟棄動做）。如今咱們須要的是在NAT B上打一個方向爲202.187.45.3（即Client A的外網地址）的洞，那麼Client A發送到187.34.1.56:40000的信息,Client B就能收到了。這個打洞命令由誰來發呢？天然是Server S。
總結一下這個過程：若是Client A想向Client B發送信息，那麼Client A發送命令給Server S，請求Server S命令Client B向Client A方向打洞。而後Client A就能夠經過Client B的外網
地址與Client B通訊了。
注意：以上過程只適合於Cone NAT的狀況，若是是Symmetric NAT，那麼當Client B向Client A打洞的端口已經從新分配了，Client B將沒法知道這個端口（若是Symmetric NAT的端口是順序分配的，那麼咱們或許能夠猜想這個端口號，但是因爲可能致使失敗的因素太多，這種狀況下通常放棄P2P ---peakflys）。
2、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的任何迴應包，那只有兩種可能：一、STUN服務器不存在，或者你弄錯了port。二、你的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的介紹，待續……
參考資料：
一、維基百科之STUN
二、http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt（shootingstars）
參考資料：
一、維基百科之STUN
二、http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt（shootingstars）
posted on 2013-01-25 15:43 peakflys 閱讀(5445) 評論(2) 編輯 收藏 引用 所屬分類: P2P算法