stun協議（rfc3489、詳見http://www.ietf.org/rfc/rfc3489.txt） 提出了4種nat型別的定義及其分類，並給出了如何檢測
在用的nat究竟屬於哪種分類的標準。但是，具體到p2p程式如何應用stun協議及其分類法穿越nat，則是仁者見仁、智者見智。
（因為stun協議並沒有給出也沒有必要給出如何穿越nat的標準）
在拙作「iptables與stun」一文中，筆者花大幅精力闡述了iptables理論上屬於symmetric nat而非port restricted cone。
對此，很多人（包括筆者最初學習stun協議時）心中都有乙個疑惑，即僅就stun協議本身來說，port restricted cone和
symmetric nat的區別似乎不大，雖然兩者的對映機制是有點不同，但他們都具有埠受限的屬性。初看起來，這兩者在
穿越nat方面的特性也差不多，尤其是對於外部位址欲往nat內部位址發包的情況。既然如此，又為何有必要把iptables分得
這麼清呢，本文順帶解決了讀者在這一方面的疑惑。
**http://midcom-p2p.sourceforge.net/給出了p2p程式具體如何穿越nat的乙個思路，並提供了乙個p2p協議穿越nat相容性的
測試工具natcheck。讓我們仍舊用例項（例1）來說明這一思路吧！
a機器在私網（192.168.0.4）
a側nat伺服器（210.21.12.140）
b機器在另乙個私網（192.168.0.5）
b側nat伺服器（210.15.27.140）
c機器在公網（210.15.27.166）作為a和b之間的中介
a機器連線過c機器，假使是 a（192.168.0.4:5000）-> a側nat**換後210.21.12.140:8000）-> c（210.15.27.166:2000）
b機器也連線過c機器，假使是 b（192.168.0.5:5000）-> b側nat**換後210.15.27.140:8000）-> c（210.15.27.166:2000）
a機器連線過c機器後，a向c報告了自己的內部位址（192.168.0.4:5000），此時c不僅知道了a的外部位址
（c通過自己看到的210.21.12.140:8000）、也知道了a的內部位址。同理c也知道了b的外部位址（210.15.27.140:8000）和
內部位址（192.168.0.5:5000）。之後，c作為中介，把a的兩個位址告訴了b，同時也把b的兩個位址告訴了a。
假設a先知道了b的兩個位址，則a從192.168.0.4:5000處同時向b的兩個位址192.168.0.5:5000和210.15.27.140:8000發包
，由於a和b在兩個不同的nat後面，故從a（192.168.0.4:5000）到b（192.168.0.5:5000）的包肯定不通，現在看
a（192.168.0.4:5000）到b（210.15.27.140:8000）的包，分如下兩種情況：
1、b側nat屬於full cone nat
則無論a側nat屬於cone nat還是symmetric nat，包都能順利到達b。如果p2p程式設計得好，使得b主動到a的包也能借用
a主動發起建立的通道的話，則即使a側nat屬於symmetric nat，b發出的包也能順利到達a。
結論1：只要單側nat屬於full cone nat，即可實現雙向通訊。
2、b側nat屬於restricted cone或port restricted cone
則包不能到達b。再細分兩種情況
（1）、a側nat屬於restricted cone或port restricted cone
雖然先前那個初始包不曾到達b，但該發包過程已經在a側nat上留下了足夠的記錄：
a（192.168.0.4:5000）->（210.21.12.140:8000）->b（210.15.27.140:8000）。如果在這個記錄沒有超時之前，
b也重複和a一樣的動作，即向a（210.21.12.140:8000）發包，雖然a側nat屬於restricted cone或port restricted cone，
但先前a側nat已經認為a已經向b（210.15.27.140:8000）發過包，故b向a（210.21.12.140:8000）發包能夠順利到達a。
同理，此後a到b的包，也能順利到達。
結論2：只要兩側nat都不屬於symmetric nat，也可雙向通訊。換種說法，只要兩側nat都屬於cone nat，即可雙向通訊。
（2）、a側nat屬於symmetric nat
因為a側nat屬於symmetric nat，且最初a到c發包的過程在a側nat留下了如下記錄：
a（192.168.0.4:5000）->（210.21.12.140:8000）-> c（210.15.27.166:2000），故a到b發包過程在a側nat上留下的記錄為：
a（192.168.0.4:5000）->（210.21.12.140:8001）->b（210.15.27.140:8000）（注意，轉換後埠產生了變化）。
而b向a的發包，只能根據c給他的關於a的資訊，發往a（210.21.12.140:8000），因為a埠受限，故此路不通。
再來看b側nat，由於b也向a發過了包，且b側nat屬於restricted cone或port restricted cone，故在b側nat上留下的記錄為：
b（192.168.0.5:5000）->（210.15.27.140:8000）->a（210.21.12.140:8000），此後，如果a還繼續向b發包的話
（因為同一目標，故仍然使用前面的對映），如果b側nat屬於restricted cone，則從a（210.21.12.140:8001）來的包能夠順利到達b；
如果b側nat屬於port restricted cone，則包永遠無法到達b。
結論3：一側nat屬於symmetric nat，另一側nat屬於restricted cone，也可雙向通訊。
顯然，還可得出另乙個不幸的結論4，兩個都是symmetric nat或者乙個是symmetric nat、另乙個是port restricted cone，
則不能雙向通訊。
上面的例子雖然只是分析了最初發包是從a到b的情況，但是，鑑於兩者的對稱性，並且如果p2p程式設計得足夠科學，
則前面得出的幾條結論都是沒有方向性，雙向都適用的。
通過上述分析，我們得知，在穿越nat方面，symmetric nat和port restricted cone是有本質區別的，儘管他們表面上看起來相似。
我們上面得出了四條結論，而natcheck**則把他歸結為一條：只要兩側nat都屬於cone nat
（含full cone、restricted cone和port restricted cone三者），即可雙向通訊。
而且natcheck**還建議盡量使用port restricted cone，以充分利用其埠受限的屬性確保安全性。
P2P之NAT穿透原理
p2p之nat穿透原理介紹 一次專案中，對於主動協議接入的裝置，客戶希望能夠裝置端直接推送碼流到客戶端以此減少中心 的負載。所以對p2p這塊方案做了了解，這裡做下整理。即對等計算機網路，是一種在對等者 peer 之間分配任務和工作負載的分布式應用架構 是對等計算模型在應用層形成的一種組網或網路形式。...
p2p之Tcp穿透路由Nat
終於解決了關於基於tcp的p2p的內網穿透問題 其實本該在去年就解決這個問題的,寫出來了,只是一直沒時間去驗證。這幾天重寫了一下。中國的網路基本是全是內網，通過路由的nat轉換 udp的p2p實現起來非常簡單。只是udp太不穩定了，如果網路快的情況下丟包太嚴重。所以一直想是否能通過tcp來代替udp...
P2P之UDP穿透NAT原始碼分析
p2p之udp 穿透nat 原始碼分析 說明 有關這方面的介紹很多，請參考p2p 之udp 穿透nat 的原理與實現的講解。主要技術就是nat 網路位址轉換。要強調的一點是，當內網客戶端要連線公網伺服器時，會在nat 上建乙個session,並且分配乙個埠 十分重要 並且記錄相應的公網ip 位址和埠...