基于P2P的TCP穿透NAT技術研究

劉健 周仲文 劉洋

四川廣播電視大學 四川 610107

0 引言

Internet飛速發(fā)展，IPv4地址日益不足，不得不使用NAT技術來提高地址使用率，從邏輯意義上擴展地址空間。P2P技術的出現(xiàn)也是 Internet發(fā)展的結果，其優(yōu)點在于任意兩節(jié)點間可以隨意通信，擺脫了客戶端對服務器的依賴。

NAT背后的私有地址對公網地址節(jié)點不可見，雖然內網主機可以主動訪問外部網絡，但公網主機不能主動訪問內網主機。同時，內網主機間不能相互識別，進而導致不能直接向對方提供服務。這類問題與P2P技術的初衷——“對等”相違背，阻礙了P2P的發(fā)展。在目前NAT技術大面積應用的狀態(tài)下，急需一種簡單有效的辦法解決這個問題，同時還要滿足“不需要改變現(xiàn)有網絡結構”的要求。

1 NAT類型

根據端口映射方式不同，NAT主要分為兩大類：ConeNAT(克隆式 NAT)和 SymmetricNAT(對稱式 NAT)。ConeNAT把來自于同一個內網地址 A:B的請求都映射到一個公網地址X:Y上。SymmetricNAT把來自于同一內網地址A:B，去往同一個外網地址C:D的請求映射成同一個公網地址X:Y1，去往另外一個外網地址E:F的請求映射成同一個公網地址，但端口不同X:Y2。

研究表明，現(xiàn)存的NAT有88.1%是屬于第一種類型，只有2.3%左右的NAT屬于第二種。因此，針對ConeNAT的穿透研究更具有實際應用價值。

2 穿透NAT

最新的STUN已經規(guī)定其自身只是一種應用于NAT的工具，不再是一整套解決方案。結合TCP建立連接的特點，即要經過三次握手，此過程需要第三方的服務器協(xié)助才能穿透NAT，具體步驟見圖1。

圖1 TCP穿透NAT流程

（1）用戶A與公網上的服務器S建立TCP連接。S判斷A所連接的NAT A類型，并記錄下A的私有地址(172.16.1.2: 4001)以及經過轉換后的公網地址(211.0.0.2:5001)(第1步)。同樣的信息在用戶B與服務器S建立連接后也記錄下來：私有地址(192.168.1.3：6001)和公網地址(222.0.0.3：7001)(第2步)。

（2）當A與B之間需要建立TCP連接時，A先向S發(fā)送一個請求(第3步)，S把B的公網地址(222.0.0.3：7001)回復給A(第4步)。于是A斷開與S的連接，并且向B發(fā)出一個SYN(A-＞B)信息，接著A保持監(jiān)聽狀態(tài)，并每隔一段時間向B發(fā)送一個SYN(A-＞B)(第6步)。當?shù)谝粋€SYN信息到達NAT A后，NAT A記錄下A主動與B通信的狀態(tài)，此后來自B的數(shù)據包可以自由穿透NAT A。

（3）S在把B的公網地址回復給A的同時，也把A的公網地址通知給B(第5步)。

（4）B收到S的通知后，斷開與S的連接，并且向A發(fā)送一個SYN(B-＞A)信息(第7步)，接著B保持監(jiān)聽狀態(tài)。當這個SYN(B-＞A)到達NAT B后，NAT B記錄下B主動與A通信的狀態(tài)，此后來自A的數(shù)據包可以自由穿透NAT B。如果SYN(A-＞B)比SYN(B-＞A)先到達NAT B，SYN(A-＞B)會被認為是非法而拋棄，如第6步的SYN(A-＞B)；只有比SYN (B-＞A)晚到達NAT B的SYN(A-＞B)才會被認為是合法，如第8步的SYN(A-＞B)。

（5）當合法的SYN（A-＞B）穿透NAT B到達B（第8步）后，B向A回發(fā)一個SYN+ACK（B-＞A）信息（第9步）。此時來自 B的數(shù)據包都被 NAT A認為是合法，所以這個SYN+ACK（B-＞A）可以自由穿透NAT A到達A。

（6）當 A收到 SYN+ACK(B-＞A)后，向 B回發(fā)一個ACK(A-＞B)(第10步）。這個ACK(A-＞B)也可以自由穿透NAT B到達B。于是雙方的TCP經過三次握手，建立連接成功(第11步)。

此種穿透法可以在前述的大多數(shù)情況下正常建立P2P的TCP連接，具有實際應用價值。但是如果其中有一個 NAT是 SymmetricNAT，那么上述方法就會失效。因為對于不同的目的公網地址，都會映射成不同的端口。

3 結語

通過第三方的協(xié)助，P2P順利穿透NAT，各節(jié)點間建立TCP連接。此方法的優(yōu)點在于簡單有效，不需要改變現(xiàn)有的網絡結構，在相當長的一段時間都可以應用于實踐當中，為網絡結構升級換代提供了更加充分的時間。缺點就是需要借助第三方的幫助，增加了設備購置的成本，也增加了管理的成本，同時還增加了安全風險。

[1]Jennigs C. NAT Classification Results using STUN. IETF Internet Draft. October 2004.

[2]RFC5389 Session Traversal Utilities for NAT (STUN). J. Rosenberg, R. Mahy, P. Matthews, D. Wing. October 2008.

[3]BEHAVE-NAT MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using STUN", Work in Progress, July 2008.

[4]BEHAVE-TURN Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, July 2008.

[5]Jeffrey L. Eppinger. TCP connections for P2P apps: A software approach to solving the NAT problem. Technical Report CMUISRI-05-104, Carnegie Mello University. January 2005.

[6]Andrew Biggadike, Daniel Ferullo, Geoffrey Wilson, and Adrian Perrig. NAT BLASTER: Establishing TCP connections between hosts behind NATs. In ACMSIGCOMM Asia Workshop, Beijing China. April 2005.

[7]RFC2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000.