網路打洞(P2P軟體穿透內網進行通訊) 原理

標籤：

http://www.cnblogs.com/gansc23/archive/2010/10/20/1857066.html

 

首先先介紹一些基本概念：
NAT(Network Address Translators)，網路位址轉譯：網路位址轉譯是在IP地址日益缺乏的情況下產生的，它的主要目的就是為了能夠地址重用。NAT分為兩大類，基本的NAT和NAPT(Network Address/Port Translator)。

最開始NAT是運行在路由器上的一個功能模組。

最先提出的是基本的NAT，它的產生基於如下事實：一個私人網路（域）中的節點中只有很少的節點需要與外網串連（呵呵，這是在上世紀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才是我們真正討論的主角。看：
Server S1
18.181.0.31:1235
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 155.99.25.11:62000 v |
|
NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234

有一個私人網路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:1235發送到62000連接埠的資料會被NAT自動的轉寄到 10.0.0.1:1234上。（注意：這裡是說18.181.0.31:1235發送到62000連接埠的資料會被轉寄，其他的IP或者 18.181.0.31上的其它連接埠發送到這個連接埠的資料將被NAT拋棄）這樣Client A就與Server S1建立以了一個串連。

呵呵，上面的基礎知識可能很多人都知道了，那麼下面是關鍵的部分了。看看下面的情況：
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
|
Cone NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234

接上面的例子，如果Client A的原來那個Socket(綁定了1234連接埠的那個UDP Socket)又接著向另外一個Server S2發送了一個UDP包，那麼這個UDP包在通過NAT時會怎麼樣呢？
這時可能會有兩種情況發生，一種是NAT再次建立一個 Session，並且再次為這個Session分配一個連接埠號碼（比如：62001）。另外一種是NAT再次建立一個Session，但是不會新分配一個連接埠號碼，而是用原來分配的連接埠號碼62000。前一種NAT叫做Symmetric NAT，後一種叫做Cone NAT。我們期望我們的NAT是第二種，呵呵，如果你的NAT剛好是第一種，那麼很可能會有很多P2P軟體失靈。(特別是如果雙方都是Symmetric NAT，或者一方是Symmetric NAT，另一方是Restricted Cone NAT，這種情況下，建立p2p的串連將會比較困難。關於Restricted Cone NAT，請參看http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt)(draft-ford-midcom-p2p-01.zip)

好了，我們看到，通過NAT,子網內的電腦向外連結是很容易的（NAT相當於透明的，子網內的和外網的電腦不用知道NAT的情況）。但是如果外部的電腦想訪問子網內的電腦就比較困難了（而這正是P2P所需要的）。那麼我們如果想從外部發送一個資料報給內網的電腦有什麼辦法呢？

首先，我們必須在內網的NAT上打上一個“洞”（也就是前面我們說的在NAT上建立一個Session），這個洞不能由外部來打，只能由內網內的主機來打。而且這個洞是有方向的，比如從內部某台主機（比如：192.168.0.10:11111）向外部的某個IP(比如：219.237.60.1:22222)發送一個UDP包，那麼就在這個內網的NAT裝置上打了一個方向為219.237.60.1:22222的 “洞”，（這就是稱為UDP Hole Punching的技術）以後219.237.60.1:11111就可以通過這個洞與內網的192.168.0.10:22222聯絡了。（但是其他的 IP或者219.237.60.1上的其它連接埠不能利用這個洞）。

呵呵，現在該輪到我們的正題P2P了。有了上面的理論，實現兩個內網的主機通訊就差最後一步了：那就是雞生蛋還是蛋生雞的問題了，兩邊都無法主動發出串連請求，誰也不知道誰的公網地址，那我們如何來打這個洞呢？我們需要一個中間人來聯絡這兩個內網主機。現在我們來看看一個P2P軟體的流程，以為例：
Server S （219.237.60.1）
|
|
+----------------------+----------------------+
| |
NAT A (外網IP:202.187.45.3) NAT B (外網IP:187.34.1.56)
| (內網IP:192.168.0.1) | (內網IP:192.168.0.1)
| |
Client A (192.168.0.20:4000) Client B (192.168.0.10:40000)

首先，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：60000（即Client A的外網地址）的洞，那麼Client A發送到187.34.1.56:40000的資訊,Client B就能收到了。既然Client A不能夠通知Client B來打這個洞，那麼我們只能通過伺服器來轉寄這個命令了。

總結一下這個過程：如果Client A想向Client B發送資訊，那麼Client A發送命令給Server S，請求Server S命令Client B向Client A方向打洞。呵呵，是不是很繞口，不過沒關係，想一想就很清楚了，何況還有原始碼呢（侯老師說過：在原始碼面前沒有秘密 8）），然後Client A就可以通過Client B的外網地址與Client B通訊了。

這是一個Client A與Client B建立p2p連結的大概的流程：
(1) Client A->Server S (Client A向Server S發送一個請求，請求資訊是希望Client B向Client A方向打洞)
(2) Server S->Client B (S要求B向A打洞)
(3) Client B->Client A (打洞訊息，這個訊息Client A很可能不會收到，但是收不到沒有關係，NAT B上的洞已經打好了)
(4) Client A->Client B (發送正真的訊息)

注意：以上過程只適合於Cone NAT的情況，如果是Symmetric NAT，那麼當Client B向Client A打洞的連接埠已經重新分配了，Client B將無法知道這個連接埠（如果Symmetric NAT的連接埠是順序分配的，那麼我們或許可以猜測這個連接埠號碼，可是由於可能導致失敗的因素太多，我們不推薦這種猜測連接埠的方法）。

下面是一個類比P2P聊天的過程的原始碼，過程很簡單，P2PServer運行在一個擁有公網IP的電腦上，P2PClient運行在兩個不同的NAT後（注意，如果兩個用戶端運行在一個NAT後，本程式很可能不能運行正常，這取決於你的NAT是否支援loopback translation，詳見http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt(draft-ford-midcom-p2p-01.zip)，當然，此問題可以通過雙方先嘗試串連對方的內網IP來解決，但是這個代碼只是為了驗證原理，並沒有處理這些問題），後登入的電腦可以獲得先登入電腦的使用者名稱，後登入的電腦通過send username message的格式來發送訊息。如果發送成功，說明你已取得了直接與對方串連的成功。
程式現在支援三個命令：send , getu , exit
send格式：send username message
功能：發送資訊給username
getu格式：getu
功能：獲得當前伺服器使用者列表
exit格式：exit
功能：登出與伺服器的串連（伺服器不會自動監測客戶是否吊線）

代碼很短，相信很容易懂，如果有什麼問題，可以給我發郵件 [email protected] 或者在CSDN上發送短訊息。同時，歡迎轉寄此文，但希望保留作者著作權8-）。

附: NAT/NAPT模組是通過一張記錄表來記錄我們打洞後的映射關係，但是這個映射關係是有生命期的(除非在網關上設定了靜態映射)，所以它不會一直都存在於記錄表中，如果我們需要保持我們打洞後的映射關係，就可能需要有一端以心跳包的方式來使NAT/NAPT模組保持我們打洞後的映射關係。


參考：http://www.k8w.net/technology/develop/200710/81.html

網路打洞(P2P軟體穿透內網進行通訊) 原理