原文連接：http://blog.csdn.net/softmanfly/article/details/12310227
1 P2P簡介
P2P即點對點通信，或稱爲對等聯網，與傳統的服務器客戶端模式有着明顯的區別，傳統的服務器客戶端模型如圖2所示。P2P這一術語在不同的上下文環境裏可能有不同的內涵，它可以指一種通信模式、一種邏輯網絡模型、一種技術、甚至一種理念。在P2P網絡中如圖1所示，所有通信節點的地位都是對等的，每個節點都扮演着客戶機和服務器雙重角色，節點之間通過直接通信實現文件信息、處理器運算能力、存儲空間等資源的共享。P2P網絡具有分散性、可擴展性、健壯性等特點，這使得P2P技術在信息共享、實時通信、協同工作、分佈式計算、網絡存儲等領域都有廣闊的應用。
圖1 P2P結構模型
圖2 CS模式
2 NAT簡介
目前，IPv4地址資源的緊缺使得NAT技術獲得了廣泛的應用。NAT技術是一種把內部網絡（簡稱爲內網）私有IP地址轉換爲外部網絡（簡稱爲外網）公共IP地址的技術，它使得一定範圍內的多臺主機只利用一個公共IP地址連接到外網，可以在很大程度上緩解了公網IP地址緊缺的問題。3 NAT對P2P通信的影響
NAT技術雖然在一定程度上解決了IPv4地址短缺的問題，在構建防火牆、保證網絡安全方面都發揮了一定的作用，卻破壞了端到端的網絡通信。NAT阻礙主機進行P2P通信的主要原因是NAT不允許外網主機主動訪問內網主機，因爲NAT設備上沒有相關轉發表項，要在NAT網絡環境中進行有效的P2P通信，就必須尋找相應的解決方案。本文就着重介紹幾種常見的解決方案。4 P2P穿越NAT的幾種方案
4.1 反向鏈接技術
當通信的雙方中只有一方位於NAT之後時，它們可以利用反向鏈接技術來進行P2P通信。圖3中Client A（擁有內網IP地址10.0.0.1）位於NAT之後，它通過TCP端口1234連接到服務器（擁有外網IP地址）的TCP端口1235上，NAT設備（擁有外網IP地址155.99.25.11）爲這個連接重新分配了TCP端口62000。Client B（擁有外網IP地址138.76.29.7）也通過TCP端口1234連接到服務器端口1235上。Client A和Client B從服務器處獲知的對方的外網地址二元組{IP地址:端口號}分別爲{138.76.29.7:1234}和{155.99.25.11:62000}，它們在各自的本地端口上進行偵聽。由於Client B 擁有外網IP地址，所以Client A要發起與Client B的通信，那麼它可以直接通過TCP連接到Client B。但如果Client B嘗試通過TCP連接到Client A進行P2P通信，則會失敗，原因是Client A位於NAT設備後，雖然Client B發出的TCP SYN請求能夠到達NAT設備的端口62000，但NAT設備會拒絕這個連接請求。要想與Client A通信，Client B要通過服務器給Client A轉發一個連接請求，反過來請求Client A連接到Client B（即進行反向鏈接），從而建立起它們之間的TCP連接。
反向鏈接示意圖
4.2 UDP打洞技術
如果兩個P2P客戶端都位於NAT設備後面，想要進行P2P通信，那又該如何解決呢？UDP打洞技術就是爲解決這個問題而應運而生的，它能夠通過中間服務器實現P2P客戶端互連。該技術在RFC 3027的第5.1節中有所提及，目前在多種在線遊戲協議中已經得到了應用，下面來重點介紹下。4.2.1 集中服務器
打洞技術假定客戶端A和客戶端B都可以與公網內的已知集中服務器建立UDP連接，一個客戶端在集中服務器上登陸的時候，服務器記錄下該客戶端的兩對地址二元組信息{IP地址:UDP端口}，一對是該客戶端與集中服務器進行通信的自身的IP地址和端口號，另一對是集中服務器記錄下的由服務器“觀察”到的該客戶端實際與自己通信所使用的IP地址和端口號。我們可以把前一對地址二元組看作是客戶端的內網IP地址和端口號，把後一對地址二元組看作是客戶端的內網IP地址和端口號經過NAT轉換後的外網IP地址和端口號。集中服務器可以從客戶端的登陸消息中得到該客戶端的內網相關信息，還可以通過登陸消息的IP頭和UDP頭得到該客戶端的外網相關信息。如果該客戶端不是位於NAT設備後面，那麼採用上述方法得到的兩對地址二元組信息是完全相同的。4.2.2 建立P2P的Session
假定客戶端A要發起對客戶端B的直接連接，具體的“打洞”過程如下：（1）客戶端A最初不知道如何向客戶端B發起連接，於是客戶端A向集中服務器發送消息，請求集中服務器幫助建立與客戶端B的UDP連接。
（2）集中服務器將含有客戶端B的外網和內網的地址二元組發給客戶端A，同時，集中服務器將包含有客戶端A的外網和內網的地址二元組信息的消息也發給客戶端B。這樣一來，客戶端A與客戶端B就都知道對方外網和內網的地址二元組信息了。
（3）當客戶端A收到由集中服務器發來的包含客戶端B的外網和內網的地址二元組信息後，客戶端A開始向客戶端B的地址二元組發送UDP數據包，並且客戶端A會自動鎖定第一個給出響應的客戶端B的地址二元組。同理，當客戶端B收到由集中服務器發來的客戶端A的外網和內網地址二元組信息後，也會開始向客戶端A的外網和內網的地址二元組發送UDP數據包，並且自動鎖定第一個得到客戶端A迴應的地址二元組。由於客戶端A與客戶端B互相向對方發送UDP數據包的操作是異步的，所以客戶端A和客戶端B發送數據包的時間先後並沒有時序要求。
下面來看下這三者之間是如何進行UDP打洞的。在這我們分三種具體情景來討論：
第一種是最簡單的一種情景，兩個客戶端都位於同一個NAT設備後面，即位於同一內網中；
第二種是最普遍的一種情景，兩個客戶端分別位於不同的NAT設備後面，分屬不同的內網；
第三種是客戶端位於兩層NAT設備之後，通常最上層的NAT是由網絡提供商提供的，第二層NAT是家用的NAT路由器之類的設備提供的。
4.2.3 P2P的兩個客戶端位於同一個NAT設備後面
首先假設兩個客戶端位於同一個NAT設備後面，並且位於內網，如圖4所示。客戶端A與集中服務器建立了UDP連接，經過NAT轉換後，A的公網端口被映射爲62000。客戶端B同樣與集中服務器建立了UDP連接，公網端口映射爲62005。
圖4 位於同一個NAT設備後的UDP打洞過程
假設客戶端A想通過集中服務器，發起對客戶端B的連接。客戶端A向集中服務器發出消息請求與客戶端B進行連接，集中服務器將客戶端B的外網地址二元組以及內網地址二元組發給客戶端A，同時把客戶端A的外網以及內網的地址二元組信息發給客戶端B。客戶端A和客戶端B發往對方公網地址二元組信息的UDP數據包不一定會被對方收到，這取決於當前的NAT設備是否支持不同端口之間的UDP數據包能否到達即Hairpin轉換特性，無論如何客戶端A與客戶端B發往對方內網的地址二元組信息的UDP數據包是一定可以到達的，內網數據包不需要路由，且速度更快。客戶端A與客戶端B推薦採用內網的地址二元組信息進行常規的P2P通信。
假定NAT設備支持Hairpin轉換，具體的Hairpin轉換見4.2.5章節，應用程序也應忽略與內網地址二元組的連接，如果客戶端A、客戶端B採用外網的地址二元組做爲P2P通信的連接，這勢必會造成數據包無謂地經過NAT設備，這是一種對資源的浪費。就目前的網絡情況而言，應用程序在“打洞”的時候，最好還是把外網和內網的地址二元組都嘗試一下。如果都能成功，優先以內網地址進行連接。
4.2.4 P2P客戶端位於不同的NAT設備後面
假定客戶端A與客戶端B在不同的NAT設備後面，分屬不同的內網，如圖5所示。客戶端A與客戶端B都經由各自的NAT設備與集中服務器建立了UDP連接，客戶端A與客戶端B的本地端口號均爲4321，集中服務器的公網端口號爲1234。在向外的會話中，客戶端A的外網IP被映射爲155.99.25.11，外網端口爲62000，客戶端B的外網IP被映射爲138.76.29.7，外網端口爲31000。
如下所示：
客戶端A——>本地IP:10.0.0.1，本地端口:4321，外網IP:155.99.25.11，外網端口:62000
客戶端B——>本地IP:10.1.1.3，本地端口:4321，外網IP:138.76.29.7，外網端口:31000
圖5 位於不同NAT設備後的UDP打洞過程
在客戶端A向服務器發送的登陸消息中，包含有客戶端A的內網地址二元組信息，即10.0.0.1:4321；服務器會記錄下客戶端A的內網地址二元組信息，同時會把自己觀察到的客戶端A的外網地址二元組信息記錄下來，即155.99.25.11:62000。同理，服務器也會記錄下客戶端B的內網地址二元組信息爲10.1.1.3:4321和由服務器觀察到的客戶端B的外網地址二元組信息，138.76.29.7:31000。無論A與B二者中的任何一方向服務器發送P2P連接請求，服務器都會將其記錄下來的上述的外網和內網地址二元組發送給A或B。
A、B分屬不同的內網，它們彼此的內網地址在外網中是沒有路由的，所以發往各自內網地址的UDP數據包會發送到錯誤的主機或者根本不存在的主機上。現在假定A的第一個消息將發往B的外網地址，如圖5所示。該消息途經A的NAT設備，並在該設備上生成一個會話表項，該會話的源地址二元組信息是{10.0.0.1:4321}，該地址二元組信息和客戶端A與服務器建立連接的時候NAT生成的源地址二元組信息一樣，但它的目的地址不同。如果A的NAT設備給出的響應是OK的，那麼A的NAT設備將保留A的內網地址二元組信息，並且所有來自A的源地址二元組信息爲{10.0.0.1:4321}的數據包都沿用A與集中服務器事先建立起來的會話，外網地址二元組信息均爲{155.99.25.11:62000}。
A向B的外網地址發送消息的過程就是“打洞”的過程，從A的內網的角度來看應爲從{10.0.0.1:4321}發往{138.76.29.7:31000}，從A在其NAT設備上建立的會話來看，是從{155.99.25.11:62000}發到{138.76.29.7:31000}。
如果A發給B的外網地址二元組的消息包在B向A發送消息包之前到達B的NAT設備，B的NAT設備會認爲A發過來的消息是未經授權的外網消息，會丟棄掉該數據包。B發往A的消息包與上述的過程一樣，會在B的NAT設備上建立一個{10.1.1.3:4321，155.99.25.11:62000}的會話（通常也會沿用B與集中服務器連接時建立的會話，只是該會話現在不僅接受由服務器發給B的消息，還可以接受從A的NAT設備155.99.25.11:6200發來的消息），一旦A與B都向對方的NAT設備在外網上的地址二元組發送了數據包，就打開了A與B之間的“洞”，A與B向對方的外網地址發送數據，等效爲向對方的客戶端直接發送UDP數據包了。一旦應用程序確認已經可以通過往對方的外網地址發送數據包的方式讓數據包到達NAT後面的目的應用程序，程序會自動停止繼續發送用於“打洞”的數據包，轉而開始真正的P2P數據傳輸。
4.2.5 P2P客戶端位於多層NAT設備後面
有的網絡拓撲結構包含了多個NAT設備，如果沒有掌握該拓撲結構的詳細信息，兩個客戶端之間是無法建立“最優化”的P2P路由的。現在我們來討論最後一種情況，如圖6所示。假定NAT C是由ISP(Internet Service Provider)提供的NAT設備，NAT C提供將多個用戶節點映射到有限的幾個公網IP的服務，NAT A和NAT B作爲NAT C的內網節點將把用戶的家庭網絡或內部網絡接入NAT C的內網，然後用戶的內部網絡就可以經由NAT C訪問公網了。從這種拓撲結構上來看，只有服務器與NAT C是真正擁有公網可路由IP地址的設備，而NAT A和NAT B所使用的公網IP地址，實際上是由ISP服務提供商設定的（相對於NAT C而言）內網地址（本文的後續部分把這個由ISP提供的內網地址相對於NAT C稱之爲“僞”公網地址），同理隸屬於NAT A與NAT B的客戶端，相對與NAT A，NAT B而言，它們處於NAT A，NAT B的內網，以此類推，客戶端可以放到到多層NAT設備後面。客戶端A和客戶端B發起對服務器S的連接的時候，就會依次在NAT A和NAT B上建立向外的Session，而NAT A、NAT B要聯入公網的時候，會在NAT C上再建立向外的Session。
圖6 多層NAT下的打洞過程
現在假定客戶端A和B希望通過UDP“打洞”完成兩個客戶端的P2P直連。最優化的路由策略是客戶端A向客戶端B的“僞公網”IP上發送數據包，即ISP服務提供商指定的內網IP，NAT B的“僞”公網地址二元組，{10.0.1.2:55000}。由於從服務器的角度只能觀察到真正的公網地址，也就是NAT A，NAT B在NAT C建立session的真正的公網地址{155.99.25.11:62000}以及{155.99.25.11:62005}，非常不幸的是客戶端A與客戶端B是無法通過服務器知道這些
“僞”公網的地址，而且即使客戶端A和B通過某種手段可以得到NAT A和NAT B的“僞”公網地址，我們仍然不建議採用上述的“最優化”的打洞方式，這是因爲這些地址是由ISP服務提供商提供的或許會存在與客戶端本身所在的內網地址重複的可能性（例如:NAT A的內網的IP地址域恰好與NAT A在NAT C的“僞”公網IP地址域重複，這樣就會導致打洞數據包無法發出的問題）。
因此客戶端別無選擇，只能使用由公網服務器觀察到的A，B的公網地址二元組進行“打洞”操作，用於“打洞”的數據包將由NAT C進行轉發。
當客戶端A向客戶端B的公網地址二元組{155.99.25.11:62005}發送UDP數據包的時候，NAT A首先把數據包的源地址二元組由A的內網地址二元組{10.0.0.1:4321}轉換爲“僞”公網地址二元組{10.0.1.1:45000}，現在數據包到了NAT C，NAT C應該可以識別出來該數據包是要發往自身轉換過的公網地址二元組，如果NAT C可以給出“合理”響應的話，NAT C將把該數據包的源地址二元組改爲{155.99.25.11:62000}，目的地址二元組改爲{10.0.1.2:55000}，即NAT
B的“僞”公網地址二元組，NAT B最後會將收到的數據包發往客戶端B。同樣，由B發往A的數據包也會經過類似的過程。目前也有很多NAT設備不支持類似這樣的“Hairpin轉換”，但是已經有越來越多的NAT設備商開始加入對該轉換的支持中來。
4.2.6 UDP在空閒狀態下的超時問題
由於UDP轉換協議提供的“洞”不是絕對可靠的，多數NAT設備內部都有一個UDP轉換的空閒狀態計時器，如果在一段時間內沒有UDP數據通信，NAT設備會關掉由“打洞”操作打出來的“洞”，作爲應用程序來講如果想要做到與設備無關，就最好在穿越NAT以後設定一個穿越的有效期。很遺憾目前沒有標準有效期，這個有效期與NAT設備內部的配置有關，某些設備上最短的只有20秒左右。在這個有效期內，即使沒有P2P數據包需要傳輸，應用程序爲了維持該“洞”可以正常工作，也必須向對方發送“打洞”心跳包。這個心跳包是需要雙方應用程序都發送的，只有一方發送不會維持另一方的Session正常工作。除了頻繁發送“打洞”心跳包以外，還有一個方法就是在當前的“洞”超時之前，P2P客戶端雙方重新“打洞”，丟棄原有的“洞”，這也不失爲一個有效的方法。
4.3 關於TCP打洞技術
建立穿越NAT設備的P2P的TCP連接只比UDP複雜一點點，TCP協議的”“打洞”從協議層來看是與UDP的“打洞”過程非常相似的。儘管如此，基於TCP協議的打洞至今爲止還沒有被很好的理解，這也造成了的對其提供支持的NAT設備不是很多。在NAT設備支持的前提下，基於TCP的“打洞”技術實際上與基於UDP的“打洞”技術一樣快捷、可靠。實際上，只要NAT設備支持的話，基於TCP的P2P技術的健壯性將比基於UDP技術的更強一些，因爲TCP協議的狀態機給出了一種標準的方法來精確的獲取某個TCP session的生命期，而UDP協議則無法做到這一點。4.3.1 套接字和TCP端口的重用
實現基於TCP協議的P2P打洞過程中，最主要的問題不是來自於TCP協議，而是來自於應用程序的API接口。這是由於標準的伯克利(Berkeley)套接字的API是圍繞着構建客戶端/服務器程序而設計的，API允許TCP流套接字通過調用connect()函數來建立向外的連接，或者通過listen()和accept函數接受來自外部的連接，但是，API不提供類似UDP那樣的，同一個端口既可以向外連接，又能夠接受來自外部的連接。而且更糟的是，TCP的套接字通常僅允許建立1對1的響應，即應用程序在將一個套接字綁定到本地的一個端口以後，任何試圖將第二個套接字綁定到該端口的操作都會失敗。爲了讓TCP“打洞”能夠順利工作，我們需要使用一個本地的TCP端口來監聽來自外部的TCP連接，同時建立多個向外的TCP連接。幸運的是，所有的主流操作系統都能夠支持特殊的TCP套接字參數，通常叫做“SO_REUSEADDR”，該參數允許應用程序將多個套接字綁定到本地的一個地址二元組（只要所有要綁定的套接字都設置了SO_REUSEADDR參數即可）。BSD系統引入了SO_REUSEPORT參數，該參數用於區分端口重用還是地址重用，在這樣的系統裏面，上述所有的參數必須都設置才行。
4.3.2 打開P2P的TCP流
假定客戶端A希望建立與B的TCP連接。我們像通常一樣假定A和B已經與公網上的已知服務器建立了TCP連接。服務器記錄下來每個接入的客戶端的公網和內網的地址二元組，如同爲UDP服務的時候一樣。從協議層來看，TCP“打洞”與UDP“打洞”是幾乎完全相同的過程。l 客戶端A使用其與服務器的連接向服務器發送請求，要求服務器協助其連接客戶端B；
l 服務器將B的公網和內網的TCP地址的二元組信息返回給A，同時，服務器將A的公網和內網的地址二元組也發送給B；
l 客戶端A和B使用連接服務器的端口異步地發起向對方的公網、內網地址二元組的TCP連接，同時監聽各自的本地TCP端口是否有外部的連接聯入；
l A和B開始等待向外的連接是否成功，檢查是否有新連接聯入。如果向外的連接由於某種網絡錯誤而失敗，如：“連接被重置”或者“節點無法訪問”，客戶端只需要延遲一小段時間（例如延遲一秒鐘），然後重新發起連接即可，延遲的時間和重複連接的次數可以由應用程序編寫者來確定；
l TCP連接建立起來以後，客戶端之間應該開始鑑權操作，確保目前聯入的連接就是所希望的連接。如果鑑權失敗，客戶端將關閉連接，並且繼續等待新的連接聯入。客戶端通常採用“先入爲主”的策略，只接受第一個通過鑑權操作的客戶端，然後將進入P2P通信過程不再繼續等待是否有新的連接聯入。
圖7 TCP打洞
與UDP不同的是，因爲使用UDP協議的每個客戶端只需要一個套接字即可完成與服務器的通信，而TCP客戶端必須處理多個套接字綁定到同一個本地TCP端口的問題，如圖7所示。現在來看實際中常見的一種情景，A與B分別位於不同的NAT設備後面，如圖5所示，並且假定圖中的端口號是TCP協議的端口號，而不是UDP的端口號。圖中向外的連接代表A和B向對方的內網地址二元組發起的連接，這些連接或許會失敗或者無法連接到對方。如同使用UDP協議進行“打洞”操作遇到的問題一樣，TCP的“打洞”操作也會遇到內網的IP與“僞”公網IP重複造成連接失敗或者錯誤連接之類的問題。
客戶端向彼此公網地址二元組發起連接的操作，會使得各自的NAT設備打開新的“洞”允許A與B的TCP數據通過。如果NAT設備支持TCP“打洞”操作的話，一個在客戶端之間的基於TCP協議的流通道就會自動建立起來。如果A向B發送的第一個SYN包發到了B的NAT設備，而B在此前沒有向A發送SYN包，B的NAT設備會丟棄這個包，這會引起A的“連接失敗”或“無法連接”問題。而此時，由於A已經向B發送過SYN包，B發往A的SYN包將被看作是由A發往B的包的迴應的一部分，所以B發往A的SYN包會順利地通過A的NAT設備，到達A，從而建立起A與B的P2P連接。
4.3.3 從應用程序的角度來看TCP“打洞”
從應用程序的角度來看，在進行TCP“打洞”的時候都發生了什麼呢？假定A首先向B發出SYN包，該包發往B的公網地址二元組，並且被B的NAT設備丟棄，但是B發往A的公網地址二元組的SYN包則通過A的NAT到達了A，然後，會發生以下的兩種結果中的一種，具體是哪一種取決於操作系統對TCP協議的實現：（1）A的TCP實現會發現收到的SYN包就是其發起連接並希望聯入的B的SYN包，通俗一點來說就是“說曹操，曹操到”的意思，本來A要去找B，結果B自己找上門來了。A的TCP協議棧因此會把B作爲A向B發起連接connect的一部分，並認爲連接已經成功。程序A調用的異步connect()函數將成功返回，A的listen()等待從外部聯入的函數將沒有任何反映。此時，B聯入A的操作在A程序的內部被理解爲A聯入B連接成功，並且A開始使用這個連接與B開始P2P通信。
由於收到的SYN包中不包含A需要的ACK數據，因此，A的TCP將用SYN-ACK包迴應B的公網地址二元組，並且將使用先前A發向B的SYN包一樣的序列號。一旦B的TCP收到由A發來的SYN-ACK包，則把自己的ACK包發給A，然後兩端建立起TCP連接。簡單的說，第一種，就是即使A發往B的SYN包被B的NAT丟棄了，但是由於B發往A的包到達了A。結果是，A認爲自己連接成功了，B也認爲自己連接成功了，不管是誰成功了，總之連接是已經建立起來了。
（2）另外一種結果是，A的TCP實現沒有像（1）中所講的那麼“智能”，它沒有發現現在聯入的B就是自己希望聯入的。就好比在機場接人，明明遇到了自己想要接的人卻不認識，誤認爲是其他的人，安排別人給接走了，後來才知道是自己錯過了機會，但是無論如何，人已經接到了任務已經完成了。然後，A通過常規的listen()函數和accept()函數得到與B的連接，而由A發起的向B的公網地址二元組的連接會以失敗告終。儘管A向B的連接失敗，A仍然得到了B發起的向A的連接，等效於A與B之間已經聯通，不管中間過程如何，A與B已經連接起來了，結果是A和B的基於TCP協議的P2P連接已經建立起來了。
第一種結果適用於基於BSD的操作系統對於TCP的實現，而第二種結果更加普遍一些，多數Linux和Windows系統都會按照第二種結果來處理。
轉載自：http://www.h3c.com.cn/MiniSite/Technology_Circle/Net_Reptile/The_Five/Home/Catalog/201206/747035_97665_0.htm#