當今互聯網到處存在著一些中間件(MIddleBoxe-s)，如NAT和防火墻，導致兩個(不在同一內網)中的客戶端無法直接通信，這個問題在開發區塊鏈錢包或移動錢包時極為明顯。

”

本專題將會花幾篇文章詳細闡述如何解決這一類問題。

這類問題即便是到了IPV6時代也會存在，因為即使不需要NAT，但還有其他中間件如防火墻阻擋了鏈接的建立。 目前部署的中間件多都是在C/S架構上設計的，其中相對隱匿的客戶機主動向周知的服務端(擁有靜態IP地址和DNS名稱)發起鏈接請求。 大多數中間件實現了一種非對稱的通訊模型，即內網中的主機可以初始化對外的鏈接，而外網的主機卻不能初始化對內網的鏈接， 除非經過中間件管理員特殊配置（如端口映射或PNP）。

在中間件為常見的NAPT的情況下（也是本文主要討論的），內網中的客戶端沒有單獨的公網IP地址， 而是通過NAPT轉換，和其他同一內網用戶共享一個公網IP。這種內網主機隱藏在中間件后的不可訪問性對于一些客戶端軟件如瀏覽器來說 并不是一個問題，因為其只需要初始化對外的鏈接，從某方面來看反而還對隱私保護有好處。然而在P2P應用中， 內網主機（客戶端）需要對另外的終端（Peer）直接建立鏈接，但是發起者和響應者可能在不同的中間件后面， 兩者都沒有公網IP地址。而外部對NAT公網IP和端口主動的鏈接或數據都會因內網未請求被丟棄掉。本文討論的就是如何跨越NAT實現內網主機直接通訊的問題。

01

術語

防火墻（Firewall）： 防火墻主要限制內網和公網的通訊，通常丟棄未經許可的數據包。防火墻會檢測(但是不修改)試圖進入內網數據包的IP地址和TCP/UDP端口信息。

網絡地址轉換器（NAT）： NAT不止檢查進入數據包的頭部，而且對其進行修改，從而實現同一內網中不同主機共用更少的公網IP（通常是一個）。

基本NAT（Basic NAT）： 基本NAT會將內網主機的IP地址映射為一個公網IP，不改變其TCP/UDP端口號。基本NAT通常只有在當NAT有公網IP池的時候才有用。

網絡地址-端口轉換器（NAPT）： 到目前為止最常見的即為NAPT，其檢測并修改出入數據包的IP地址和端口號，從而允許多個內網主機同時共享一個公網IP地址。

錐形NAT（Cone NAT）： 在建立了一對（公網IP，公網端口）和（內網IP，內網端口）二元組的綁定之后，Cone NAT會重用這組綁定用于接下來該應用程序的所有會話（同一內網IP和端口），只要還有一個會話還是激活的。 例如，假設客戶端A建立了兩個連續的對外會話，從相同的內部端點

（10.0.0.1:1234）

到兩個不同的外部服務端S1和S2。Co-ne NAT只為兩個會話映射了一個公網端點 （155.99.25.11:6 2000）

確保客戶端端口的“身份”在地址轉換的時候保持不變。由于基本NAT和防火墻都不改變數據包的端口號，因此這些類型的中間件也可以看作是退化的Cone NAT。

其中Cone NAT根據NAT如何接收已經建立的（公網IP，公網端口）對的輸入數據還可以細分為以下三類：

全錐形NAT（Full Cone NAT） 在一個新會話建立了公網/內網端口綁定之后，全錐形NAT接下來會接受對應公網端口的所有數據，無論是來自哪個（公網）終端。 全錐NAT有時候也被稱為“混雜”NAT（promiscuous NAT）。

受限錐形NAT（Restricted Cone NAT） 受限錐形NAT只會轉發符合某個條件的輸入數據包。條件為：外部（源）IP地址匹配內網主機之前發送一個或多個數據包的結點的IP地址。 AT通過限制輸入數據包為一組“已知的”外部IP地址，有效地精簡了防火墻的規則。

端口受限錐形NAT（Port-Restricted Cone NAT） 端口受限錐形NAT也類似，只當外部數據包的IP地址和端口號都匹配內網主機發送過的地址和端口號時才進行轉發。 端口受限錐形NAT為內部結點提供了和對稱NAT相同等級的保護，以隔離未關聯的數據。

對稱NAT（Symmetric NAT）: 對稱NAT正好相反，不在所有公網-內網對的會話中維持一個固定的端口綁定。其為每個新的會話開辟一個新的端口。

02

P2P通信

根據客戶端的不同，客戶端之間進行P2P傳輸的方法也略有不同，這里介紹了現有的穿越中間件進行P2P通信的幾種技術。

中繼（Relaying）

這是最可靠但也是最低效的一種P2P通信實現。其原理是通過一個有公網IP的服務器中間人對兩個內網客戶端的通信數據進行中繼和轉發。如下圖所示：

客戶端A和客戶端B不直接通信，而是先都與服務端S建立鏈接，然后再通過S和對方建立的通路來中繼傳遞的數據。這鐘方法的缺陷很明顯， 當鏈接的客戶端變多之后，會顯著增加服務器的負擔，完全沒體現出P2P的優勢。但這種方法的好處是能保證成功，因此在實踐中也常作為一種備選方案。

逆向鏈接（Connection reversal）

第二種方法在當兩個端點中有一個不存在中間件的時候有效。例如，客戶端A在NAT之后而客戶端B擁有全局IP地址，如下圖：

客戶端A內網地址為10.0.0.1，且應用程序正在使用TCP端口1234。A和服務器S建立了一個鏈接，服務器的IP地址為18.181.0.31，監聽1235端口。NAT A給客戶端A分配了TCP端口62000，地址為NAT的公網IP地址155.99.25.11， 作為客戶端A對外當前會話的臨時IP和端口。因此S認為客戶端A就是155.99.25.11:6200 0。而B由于有公網地址，所以對S來說B就是138.76.29.7:1234。當客戶端B想要發起一個對客戶端A的P2P鏈接時，要么鏈接A的外網地址155.99.25.11:62000，要么鏈接A的內網地址10.0.0.1:1234，然而兩種方式鏈接都會失敗。 鏈接10.0.0.1:123 4失敗自不用說，為什么鏈接155.99.25.1 1:62000也會失敗呢？來自B的TCP SYN握手請求到達NAT A的時候會被拒絕，因為對NAT A來說只有外出的鏈接才是允許的。 在直接鏈接A失敗之后，B可以通過S向A中繼一個鏈接請求，從而從A方向“逆向“地建立起A-B之間的點對點鏈接。

很多當前的P2P系統都實現了這種技術，但其局限性也是很明顯的，只有當其中一方有公網IP時鏈接才能建立。越來越多的情況下， 通信的雙方都在NAT之后，因此就要用到我們下面介紹的第三種技術了。