1.簡介
當今網際網路到處存在著一些中介軟體(MIddleBoxes)，如NAT和防火牆，導致兩個(不在同一內網)中的客戶端無法直接通訊。這些問題即便是到了IPV6時代也會存在，因為即使不需要NAT，但還有其他中介軟體如防火牆阻擋了連結的建立。
當今部署的中介軟體大多都是在C/S架構上設計的，其中相對隱匿的客戶機主動向周知的服務端(擁有靜態IP地址和DNS名稱)發起連結請求。大多數中介軟體實現了一種非對稱的通訊模型，即內網中的主機可以初始化對外的連結，而外網的主機卻不能初始化對內網的連結，除非經過中介軟體管理員特殊配置。在中介軟體為常見的NAPT的情況下（也是本文主要討論的），內網中的客戶端沒有單獨的公網IP地址，而是通過NAPT轉換，和其他同一內網使用者共享一個公網IP。這種內網主機隱藏在中介軟體後的不可訪問性對於一些客戶端
軟體如瀏覽器來說並不是一個問題，因為其只需要初始化對外的連結，從某方面來看反而還對隱私保護有好處。
然而在P2P應用中，內網主機（客戶端）需要對另外的終端（Peer）直接建立連結，但是發起者和響應者可能在不同的中介軟體後面，兩者都沒有公網IP地址。而外部對NAT公網IP和埠主動的連結或資料都會因內網未請求被丟棄掉。本文討論的就是如何跨越NAT實現內網主機直接通訊的問題。
2.術語
防火牆（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。Cone NAT只為兩個會話對映了一個公網端點（155.99.25.11:62000），確保客戶端埠的“身份”在地址轉換的時候保持不變。由於基本NAT和防火牆都不改變資料包的埠號，因此這些型別的中介軟體也可以看作是退化的Cone NAT。
對稱NAT（Symmetric NAT）
對稱NAT正好相反，不在所有公網-內網對的會話中維持一個固定的埠繫結。其為每個新的會話開闢一個新的埠。如下圖所示：
其中Cone NAT根據NAT如何接收已經建立的（公網IP，公網埠）對的輸入資料還可以細分為以下三類：
1) 全錐形NAT（Full Cone NAT）
在一個新會話建立了公網/內網埠繫結之後，全錐形NAT接下來會接受對應公網埠的所有資料，無論是來自哪個（公網）終端。全錐NAT有時候也被稱為“混雜”NAT（promiscuous NAT）。
2) 受限錐形NAT（Restricted Cone NAT）
受限錐形NAT只會轉發符合某個條件的輸入資料包。條件為：外部（源）IP地址匹配內網主機之前傳送一個或多個資料包的結點的IP地址。受限NAT通過限制輸入資料包為一組“已知的”外部IP地址，有效地精簡了防火牆的規則。
3) 埠受限錐形NAT（Port-Restricted Cone NAT）
埠受限錐形NAT也類似，只當外部資料包的IP地址和埠號都匹配內網主機傳送過的地址和埠號時才進行轉發。埠受限錐形NAT為內部結點提供了和對稱NAT相同等級的保護，以隔離未關聯的資料。
3. P2P通訊
根據客戶端的不同，客戶端之間進行P2P傳輸的方法也略有不同，這裡介紹了現有的穿越中介軟體進行P2P通訊的幾種技術。
3.1 中繼（Relaying）
這是最可靠但也是最低效的一種P2P通訊實現。其原理是通過一個有公網IP的伺服器中間人對兩個內網客戶端的通訊資料進行中繼和轉發。如下圖所示：
客戶端A和客戶端B不直接通訊，而是先都與服務端S建立連結，然後再通過S和對方建立的通路來中繼傳遞的資料。這鐘方法的缺陷很明顯，當連結的客戶端變多之後，會顯著增加伺服器的負擔，完全沒體現出P2P的優勢。
3.2 逆向連結（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:62000。而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:1234失敗自不用說，為什麼連結155.99.25.11:62000也會失敗呢？來自B的TCP SYN握手請求到達NAT A的時候會被拒絕，因為對NAT A來說只有外出的連結才是允許的。
在直接連結A失敗之後，B可以通過S向A中繼一個連結請求，從而從A方向“逆向“地建立起A-B之間的點對點連結。
很多當前的P2P系統都實現了這種技術，但其侷限性也是很明顯的，只有當其中一方有公網IP時連結才能建立。越來越多的情況下，通訊的雙方都在NAT之後，因此就要用到我們下面介紹的第三種技術了。
3.3 UDP打洞（UDP hole punching）
第三種P2P通訊技術，被廣泛採用的，名為“P2P打洞“。P2P打洞技術依賴於通常防火牆和cone NAT允許正當的P2P應用程式在中介軟體中打洞且與對方建立直接連結的特性。以下主要考慮兩種常見的場景，以及應用程式如何設計去完美地處理這些情況。第一種場景代表了大多數情況，即兩個需要直接連結的客戶端處在兩個不同的NAT之後；第二種場景是兩個客戶端在同一個NAT之後，但客戶端自己並不需要知道。
3.3.1. 端點在不同的NAT之下
假設客戶端A和客戶端B的地址都是內網地址，且在不同的NAT後面。A、B上執行的P2P應用程式和伺服器S都使用了UDP埠1234，A和B分別初始化了與Server的UDP通訊，地址對映如圖所示:
現在假設客戶端A打算與客戶端B直接建立一個UDP通訊會話。如果A直接給B的公網地址138.76.29.7:31000傳送UDP資料，NAT B將很可能會無視進入的資料（除非是Full Cone NAT），因為源地址和埠與S不匹配，而最初只與S建立過會話。B往A直接發資訊也類似。
假設A開始給B的公網地址傳送UDP資料的同時，給伺服器S傳送一箇中繼請求，要求B開始給A的公網地址傳送UDP資訊。A往B的輸出資訊會導致NAT A開啟一個A的內網地址與與B的外網地址之間的新通訊會話，B往A亦然。一旦新的UDP會話在兩個方向都開啟之後，客戶端A和客戶端B就能直接通訊，而無須再通過引導伺服器S了。
UDP打洞技術有許多有用的性質。一旦一個的P2P連結建立，連結的雙方都能反過來作為“引導伺服器”來幫助其他中介軟體後的客戶端進行打洞，極大減少了伺服器的負載。應用程式不需要知道中介軟體具體是什麼（如果有的話），因為以上的過程在沒有中介軟體或者有多箇中介軟體的情況下也一樣能建立通訊鏈路。
3.3.2. 端點在相同的NAT之下
現在考慮這樣一種情景，兩個客戶端A和B正好在同一個NAT之後（而且可能他們自己並不知道），因此在同一個內網網段之內。客戶端A和伺服器S建立了一個UDP會話，NAT為此分配了公網埠62000，B同樣和S建立會話，分配到了埠62001，如下圖：
假設A和B使用了上節介紹的UDP打洞技術來建立P2P通路，那麼會發生什麼呢？首先A和B會得到由S觀測到的對方的公網IP和埠號，然後給對方的地址傳送資訊。兩個客戶端只有在NAT允許內網主機對內網其他主機發起UDP會話的時候才能正常通訊，我們把這種情況稱之為"迴環傳輸“(lookback translation)，因為從內部到達NAT的資料會被“回送”到內網中而不是轉發到外網。例如，當A傳送一個UDP資料包給B的公網地址時，資料包最初有源IP地址和埠地址10.0.0.1:1234和目的地址155.99.25.11:62001，NAT收到包後，將其轉換為源155.99.25.11:62000（A的公網地址）和目的10.1.1.3:1234，然後再轉發給B。即便NAT支援迴環傳輸，這種轉換和轉發在此情況下也是沒必要的，且有可能會增加A與B的對話延時和加重NAT的負擔。
對於這個問題，解決方案是很直觀的。當A和B最初通過S交換地址資訊時，他們應該包含自身的IP地址和埠號（從自己看），同時也包含從伺服器看的自己的地址和埠號。然後客戶端同時開始從對方已知的兩個的地址中同時開始互相傳送資料，並使用第一個成功通訊的地址作為對方地址。如果兩個客戶端在同一個NAT後，傳送到對方內網地址的資料最有可能先到達，從而可以建立一條不經過NAT的通訊鏈路；如果兩個客戶端在不同的NAT之後，傳送給對方內網地址的資料包根本就到達不了對方，但仍然可以通過公網地址來建立通路。值得一提的是，雖然這些資料包通過某種方式驗證，但是在不同NAT的情況下完全有可能會導致A往B傳送的資訊傳送到其他A內網網段中無關的結點上去的。
3.3.3. 固定埠繫結
UDP打洞技術有一個主要的條件：只有當兩個NAT都是Cone NAT（或者非NAT的防火牆）時才能工作。因為其維持了一個給定的（內網IP，內網UDP）二元組和（公網IP， 公網UDP）二元組固定的埠繫結，只要該UDP埠還在使用中，就不會變化。如果像對稱NAT一樣，給每個新會話分配一個新的公網埠，就會導致UDP應用程式無法使用跟外部端點已經打通了的通訊鏈路。由於Cone NAT是當今最廣泛使用的，儘管有一小部分的對稱NAT是不支援打洞的，UDP打洞技術也還是被廣泛採納應用。
4. 具體實現
如果理解了上面所說的內容，那麼程式碼實現起來倒很簡單了 。這裡採用C++的非同步IO庫來實現引導伺服器和P2P客戶端的簡單功能，目的是打通兩個客戶端的通訊鏈路，使兩個不同區域網之間的客戶端可以實現直接通訊。
4.1 引導服務端設計
引導伺服器執行在一個有公網地址的裝置上，並且接收指定埠的來自客戶的命令（這裡是用埠號2333）。
客戶端其實可以而且也最好應該與伺服器建立TCP連結，但我這裡為了圖方便，也只採用了UDP的通訊方式。服務端監聽2333埠的命令，然後執行相應的操作，目前包含的命令有:
login， 客戶端登入，使得其記錄在伺服器traker中，讓其他peer可以對其發出連結請求。
logout，客戶端登出，使其對peer隱藏。因為伺服器不會追蹤客戶端的登入狀態。
list，客戶端檢視目前的登入使用者。
punch <client>， 對指定使用者（序號）進行打洞。
help， 檢視有哪些可用的命令。
4.2 P2P客戶端設計
一般的網路程式設計，都是客戶端比服務端要難，因為要處理與伺服器的通訊同時還要處理來自使用者的事件；對於P2P客戶端來說更是如此，因為P2P客戶端不止作為客戶端，同時也作為對等連線的伺服器端。
這裡的大體思路是，輸入命令傳輸給伺服器之後，接收來自伺服器的反饋，並執行相應程式碼。例如A想要與B建立通訊鏈路，先給伺服器傳送punch命令以及給B傳送資料，伺服器接到命令後給B傳送punch_requst資訊以及A的端點資訊，B收到之後向A傳送資料打通通路，然後A與B就可以進行P2P通訊了。經測試，打通通路後即便把伺服器關閉，A與B也能正常通訊。
一個UDP打洞的例子見 https://github.com/pannzh/P2P-Over-MiddleBoxes-Demo
# 2016-04-06 更新
關於TCP打洞，有一點需要提的是，因為TCP是基於連線的，所以任何未經連線而傳送的資料都會被丟棄，這導致在recv的時候是無法直接從peer端讀取資料。
其實這對UDP也一樣，如果對UDP的socket進行了connect，其也會忽略連線之外的資料，詳見`connect(2)`。
所以，如果我們要進行TCP打洞，通常需要重用本地的endpoint來發起新的TCP連線，這樣才能將已經開啟的NAT利用起來。具體來說，則是要設定socket的
`SO_REUSEADDR`或`SO_REUSEPORT`屬性，根據系統不同，其實現也不盡一致。一般來說，TCP打洞的步驟如下：
- A 傳送 SYN 到 B （出口地址，下同），從而建立NAT A的一組對映
- B 傳送 SYN 到 A， 建立NAT B的一組對映
- 根據時序不同，兩個SYN中有一個會被對方的NAT丟棄，另一個成功通過NAT
- 通過NAT的SYN報文被其中一方收到，即返回SYNACK， 完成握手
- 至此，TCP的打洞成功，獲得一個不依賴於伺服器的連結