內容概述：在p2p通信領域中，由NAT(Network Address Translation，網絡地址轉換)引起的問題已經眾所周知了,它會導致在NAT內部的p2p客戶端在無論以何種有效的公網ip都無法訪問的問題。雖然目前已經發展出多種穿越NAT的技術,但相關的技術文檔卻很少，用來證明這些技術的穩定性和優點的實際數據更少。本文的目的在于描述和分析在實際中運用得最廣泛、最可靠同時也是最簡單的一種NAT穿越技術，該技術通常被稱為“打洞”技術。目前，“打洞”技術已經在UDP通信領域中得到了廣泛的理解和應用，在此，也將討論如何利用它實現可靠的p2p的TCP流通信。在收集了大量的“打洞”技術可以穿越的NAT設備和網絡的數據以后，我們發現82%的已測 NAT設備支持UDP形式的“打洞”穿越，64%的已測NAT設備支持TCP流形式的“打洞”穿越。由于重量級p2p應用程序(如，VOIP、BT、在線游戲等)的用戶需求量持續上升，并且該事實也已經引起了NAT設備生產廠商的廣泛關注，因此，我們認為未來會有越來越多的NAT設備提供對“打洞”穿越技術的支持。
1、介紹
用戶量高速增長以及大量安全問題的巨大壓力迫使Internet技術不斷向前發展，但是這些新興的技術很大程度地增加了應用程序開發的成本和復雜性。Internet最初的地址體系是每個節點有一個唯一不變的全局地址，可以通過該地址直接與任何其它的節點進行通信，而現如今，該地址體系已經被新的實際上廣泛使用的地址體系所替換，新的地址體系是由全局地址域和通過NAT接入全局地址域的大量私有地址域組成。在新的地址體系中（如圖1所示），只有在 “main”全局地址域中的節點可以在網絡中很容易地與任何其它的擁有全局地址的節點通信，因為該節點擁有全局的、唯一的、可路由的地址。在私有網絡中的節點可以與在同一個私有網絡中的其它節點進行通信，并且在通常情況下可以向全局地址中的某個“著名”的節點發起TCP連接或發送UDP數據包。NAT設備在此扮演的角色就是為從內網向公網發起的連接的節點分配臨時的轉發session，將來自內網的數據包的地址和端口轉換為公網的地址和端口，將來自公網的數據包的地址和端口轉換為內網的端口和地址，同時NAT將屏蔽所有未經授權的來自公網的數據包。
新的Internet地址體系非常適合于“客戶端/服務器”這樣的通信模式，一個典型的C/S通信模式是：客戶端在內網（私有地址域），服務器在公網（全局地址域），通過NAT將內網和公網連接起來。這種地址體系使得在不同內網（私有地址域）中的兩個節點很難直接通信，而這恰恰是p2p應用 (如，電話會議或在線游戲)中最基本的要求。很顯然，我們需要一種方法即使在NAT設備存在的前提下，仍然能夠無障礙地實現p2p通信。
在不同內網的兩個節點之間建立p2p連接的最有效的方法就是“打洞”。該技術在基于UDP的應用程序中得到了廣泛的應用，同樣的，該技術也可以用于基于TCP的應用程序。有趣的是，與“打洞”字面上的意思剛好相反，該技術不會影響到內網的安全。事實上，“打洞”技術使得p2p軟件的絕大部分功能都在NAT設備默認的安全策略的控制之下，這些都由NAT設備建立的session來管理。本文闡述了適用于UDP和TCP的“打洞”技術，并詳細描述了重要“打洞”過程中，應用程序和NAT設備之間的行為。
不幸的是，由于NAT設備的響應和行為不是標準的，所以沒有任何技術可以穿越現有的所有NAT設備。本文提供了一些在現有NAT設備上進行“打洞”的實驗結果。我們收集的數據來自于互聯網上使用了“NAT Check”工具并在大量不同生產廠商的NAT設備上進行“打洞”實驗的用戶。由于數據是來自于一個叫做“self-selecting”的用戶社區，或許不會完全代表在Internet上真正部署和使用的NAT設備，但是結果無論如何還是很令人興奮的。
在做基本的“打洞”操作評估的時候，我們應該指出在現有的NAT設備“打洞”的復雜度上，不同的復雜度會有不同的結果。但目前我們把討論的重點集中于開發最簡單的，可以應用于任何網絡拓撲結構的、穩定的、有正確NAT響應的NAT設備上的“打洞”技術。我們有意避免使用一些“聰明的小把戲”通過欺騙某些NAT設備來達到短期內穿越較多的NAT設備，但從長期來看會引起網絡未知錯誤的技術。
盡管引入IPv6會極大地增加互聯網的地址空間，從而減少對于NAT設備的需求量，但短期內IPv6確實增加了對NAT設備的需求量，因為 NAT設備本身提供了一種方便的方法進行IPv4與IPv6地址域轉換。另外私有網絡上建立匿名和加密訪問節點也有利于組織機構的安全性以及不受外界干擾，這些都意味著NAT還將存在相當長的一段時間。同樣，防火墻技術也不會由于有了足夠的ip地址而消失，IPv6的防火墻仍然會默認丟掉所有未經授權的數據包，仍然可以讓在IPv6環境下工作的應用程序“打洞”。
本文接下來的部分按照如下的方式組織：第二章介紹基本的NAT穿越概念和術語；第三章介紹UDP“打洞”過程；第四章介紹TCP“打洞”過程；第五章介紹支持“打洞”的NAT設備必須具有那些特性；第六章介紹我們在目前流行的NAT設備上的“打洞”實驗結果；第七章討論相關的網絡問題；第八章全文總結以及結束語。
2、基本概念本節介紹了本文使用到的基本的NAT術語，著重描述了適用于UDP和TCP兩種協議的通用的NAT穿越技術。
2.1、NAT術語
本文絕大部分術語和分類來自于RFC 2663定義，另外一些來自于較新的RFC 3489中的定義。
理解session是很重要的。一個TCP或UDP的session endpoint是由一個IP地址，端口號組成，每個session是由兩個session endpoint構成。從內網節點的角度來看，一個session由4部分組成分別為：本地IP，本地端口，遠端IP，遠端端口。session的方向通常代表了數據包的初始流動的方向；對于TCP來說就是SYN包的流向，對于UDP來說就是第一個用戶數據包的流向。
NAT有很多種，但最普遍的一種類型叫做“傳統”NAT，或者“向外”NAT。他們在內網和公網之間提供了一個“不對稱”橋的映射。“向外”NAT在默認情況下只允許向外的session穿越NAT：
從外向內的的數據包都會被丟棄掉，除非NAT設備事先已經定義了這些從外向內的數據包是已存在的內網session的一部分。
“外向”NAT會造成p2p協議的混亂，因為當p2p的雙方決定向在不同NAT后面的對方開始通信的時候，無論哪一方試圖初始化一個session，另一方的NAT都會拒絕這個請求。NAT穿越的核心思想就是讓p2p的雙方的NAT看上去都是“向外”的NAT。
“向外”NAT有兩種類型：（1）“基礎”NAT，該NAT只轉換IP地址，不轉換端口號。（2）NAPT(Network Address/Port Translation)NAPT轉換整個session endpoints。由于NAPT允許內網的多個節點通過共享的方式使用同一個的公共的IP地址，因此，支持NAPT的NAT設備才會越來越多。盡管本文通篇討論的內容都是基于支持NAPT的NAT設備的，但這些規律和技術同樣適用于“基礎”NAT。
2.2 轉發方式
最可靠但同時也是效率最低的p2p穿越NAT進行通信的方法是采用類似C/S方式的轉發。假定兩個節點A和B每個節點都有向外的TCP或UDP 連接，聯入公共的已知服務器S，S的公網IP地址是18.181.0.31，端口號是1234（如圖2所示）,每個客戶端位于不同的私有內網中，并且它們的NAT設備妨礙了客戶端之間直接的p2p連接。做為對直連方案的替代方案，兩個客戶端可以利用公共的服務器S進行消息的轉發。例如，A為了將消息送給 B，A只需將消息發給S，然后由S轉發給B，這一過程將使用A與B事先與S建立好的連接。
轉發方式通常只能在雙方客戶端都連接到服務器的時候有效。這種方式的缺點在于，它假定服務器的處理能力和網絡帶寬以及通信延遲都是理想的情況下，不會受到客戶端個數的影響。但是，由于沒有其它的方法能夠像轉發方式那樣，可以穿越現存的所有NAT設備，因此在構建高可靠性的p2p系統的時候，通過服務器轉發的方式依舊是一個非常有用的保證系統可靠性的方法。TURN協議定義了如何實現安全的轉發方式。
2.3 反向連接方式
一些p2p的應用程序采用了直接但是有所限制的技術來實現NAT穿越，該技術叫做“反向連接”，這是用于當兩個節點聯入服務器S的時候，只有一個一個節點在NAT設備的后面（如圖3所示）。如果A希望建立與B的連接，那么A可以直接聯入B，因為B是在公網中存在的，沒有經過NAT轉換，而且A的 NAT設備也允許A直接由內網發起向外網的連接。如果B希望建立與A的連接，很不幸，A的NAT設備會阻止該操作，此時，B可以借助于轉發服務器S，向A 發送“反向連接”請求，由A“主動”連接B，從而達到A與B的p2p通信的目的。
盡管該技術的局限性非常明顯，但是使用已知的服務器做為中介輔助p2p客戶端雙方進行p2p連接的思想已經成為了更加通用的“打洞”技術的基本思想。
3 UDP打洞方式
即使兩個p2p客戶端都位于NAT設備后面，UDP打洞方式也能夠通過已知的服務器實現p2p客戶端直連。該技術在RFC 3027的第5.1節中曾有所提及，在網絡上可以找到對其較模糊的描述，在最近的IP協議實驗中得到應用，在多種在線游戲協議中得到了應用。
3.1 集中服務器
打洞技術假定客戶端A和B可以與公網內的已知的集中服務器建立UDP連接（可以互發UDP數據包）。當一個客戶端在S上登陸的時候，服務器記錄下該客戶端的兩個endpoints（IP地址，UDP端口），一個是該客戶端確信自己是通過該ip和端口與服務器S進行通信的，另一個是服務器S記錄下的由服務器“觀察”到的該客戶端實際與自己通信所使用的ip和端口。我們可以把前一個endpoint看作是客戶端的內網ip和端口，把后一個 endpoint看作是客戶端的內網ip和端口經過NAT轉換后的公網ip和端口。服務器可以從客戶端的登陸消息的消息體中得到該客戶端的內網 endpoint相關信息，可以通過對登陸消息的IP或UDP頭得到該客戶端的公網endpoint。如果該客戶端不是位于NAT設備后面，那么采用上述方法得到的兩個endpoint的值應該完全相同。
也有一些“弱智”的NAT設備會掃描UDP數據包的包體，尋找4字節的位域，看上去很像IP地址的位域，并且把它們改為與IP頭一樣的地址。為了避免這種行為的NAT設備對UDP數據包包體的修改，應用程序可以采用直接對IP地址的值進行加密的方式騙過NAT設備的檢查。
3.2 建立p2p的session
假定A要發起對B的直接連接，“打洞”過程如下所示：(endpoint指ip地址和端口的配對)（1）A最初不知道如何向B發起連接，于是A向服務器S發送消息，請求S幫助建立與B的UDP連接。
（2）S將含有B的公網和內網的endpoint發給A，同時，S將含有A的公網和內網的endpoint的用于請求連接的消息也發給B。一旦這些消息順利到達，A與B就都知道了對方的公網和內網的endpoint。
（3）當A收到由S發來的包含B的公網和內網endpoint的消息，A開始向這些B的endpoint發送UDP數據包，并且A會自動鎖定第一個給出響應的B的endpoint。同理，當B收到由S發來的A的公網和內網endpoint以后，也會開始向A的公網和內網的endpoint發送 UDP數據包，并且自動鎖定第一個得到A的回應的endpoint。由于A與B的互相向對方發送UDP數據包的操作是異步的，所以A和B發送數據包的時間先后并沒有嚴格的時序要求。
下面我們就來看一下這三個角色之間是如何進行UDP“打洞”的。在這里我們分為三種具體情景來討論：第一種也是最“簡單”的一種情景，兩個客戶端都位于同一個NAT設備后面，位于同一個內網中；第二種也是最普遍的一種情景，兩個客戶端分別位于不同的NAT設備后面，分屬不同的內網；第三種是客戶端位于兩層NAT設備之后，通常最上層的NAT是由ISP網絡提供商，第二層的NAT是家用的NAT路由器之類的設備。
通常情況下由應用程序自身確定的網絡物理層連接方式是很困難的，有時甚至是不可能的，即使是上述的若干種情景下可以穿越NAT，也只是代表在一定時期內有效，而不是永久有效的。諸如STUN之類的網絡協議或許可以提供必要的NAT信息，但在遇到多層NAT設備的時候，通常這些信息也不是完全完整和有效的。盡管如此，只要NAT設備的響應是“合理”的，在通常情況下“打洞”技術還是能夠在應用程序對網絡狀況一無所知的前提下自動適用于多數場合。（“合理”的NAT響應將在第五章中詳細討論）
3.3 p2p客戶端位于同一個NAT設備后面
首先假設兩個客戶端位于同一個NAT設備后面，并且位于相同的內網（相同的私有IP地址域）如圖4所示。A與S建立了UDP連接，經過NAT轉換后，A的公網端口被映射為62000。B同樣與S建立了UDP連接，公網端口映射為62005。
(圖4)
假設A想通過服務器S做為介紹人，發起對B的連接。A向S發出消息請求與B進行連接。S將B的公網endpoint（即公網ip和port）以及內網endpoint（即內網ip和port）發給A，同時把A的公網、內網的endpoints發給B。由A和B發往對方公網endpoint的 UDP數據包能否被對方收到，這取決于當前的NAT是否支持“發夾”轉換（hairpin轉換，也就是同一臺設備，不同端口之間的UDP數據包能否到達，詳見3.5節）。但是A與B往對方內網endpoint發送的UDP數據包是一定可以到達的，無論如何，內網數據包不需要路由，并且速度更快。A與B有很大的可能性采用內網的endpoint進行常規的p2p通信。
假定NAT設備支持“發夾”轉換，應用程序也忽略由內網endpoint的連接，那么A、B會采用公網endpoint做為p2p通信的連接，這勢必會造成數據包無謂地經過NAT設備，這是一種對資源的浪費。我們會在第六節討論這種情況，畢竟支持“發夾”轉換的NAT設備還遠沒有對“打洞”技術支持的NAT設備多。就目前的網絡情況而言，應用程序在“打洞”的時候，最好還是把公網endpoint和內網endpoint都實驗一下。
3.4 p2p客戶端位于不同的NAT設備后面
假定A與B在不同的NAT設備后面，分屬不同的內網，如圖5所示。A與B都經由各自的NAT設備與服務器S建立了UDP連接，A與B的本地端口號均為4321，服務器S的公網端口號為1234。在“向外”session中，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)
在A向服務器S發送的登陸消息體中，會包含A的內網endpoint信息，即10.0.0.1:4321；服務器S會記錄下A的內網 endpoint，同時會把自己觀察到的A的公網endpoint記錄下來，即155.99.25.11:62000。同理，服務器S會記錄下B的內網 endpoint，10.1.1.3:4321和由S觀察到的B的公網endpoint，138.76.29.7:31000。無論A與B二者任何一方向 S發送p2p連接請求，服務器都會將其記錄下來的上述的公網、內網endpoint發送給A、B。
由于A、B分屬不同的內網，它們彼此的內網endpoint無法在公網中路由，所以發往各自內網endpoint的UDP數據包會發送到錯誤的主機或者根本不存在的主機。因此應用程序對于收到的消息必須經過授權和過濾，只有通過授權的的消息才能是從對方的endpoint發出來的，例如，可以在消息中加入對方的程序名稱、加密算法，或者至少是一個雙方都從服務器S上的預先得到的隨機數字。
現在假定A的第一個消息將發往B的公網endpoint，如圖5所示。該消息途經A的NAT設備，并在該設備上生成了一個“向外”的 session。新的session源endpoint是10.0.0.1:4321該endpoint和A與服務器S的建立連接的時候NAT生成的源 endpoint一樣，但它的目的endpoint不同。如果A的NAT設備給出的響應是“友好”的，那么A的NAT設備將保留A的內網 endpoint，并且所有來自A的源endpoint（10.0.0.1:4321）的數據包都沿用A與S事先建立起來的session，公網 endpoint均為（155.99.25.11:62000）。A向B的公網endpoint發送消息的過程就是“打洞”的過程，從A的內網的角度來看應為從（10.0.0.1:4321）發往（138.76.29.7:31000）,從A的在其NAT設備上建立的session來看，是從（155.99.25.11:62000）發到（138.76.29.7：31000）。
如果A發給B的公網endpoint的消息包在B向A發送消息包之前到達B的NAT設備，B的NAT會認為A發過來的消息是未經授權的公網消息，會丟棄掉該數據包。B發往A的消息包根上述的過程一樣，會在B的NAT上建立一個（10.1.1.3：4321，155.99.25.11: 62000）的session（通常也會沿用B與S連接時建立的session，只是該session現在不光可以接受由S發給B的消息，還可以接受從A 的NAT設備-155.99.25.11:6200發來的消息）
一旦A與B都向對方的NAT在公網上的endpoint發送了數據包，就打開了A與B之間的“洞”，A與B向對方的公網endpoint發送數據，等效為向對方的客戶端直接發送UDP數據包了。一旦應用程序確認已經可以通過往對方的公網endpoint發送數據包的方式讓數據包到達NAT后面的目的應用程序，程序會自動停止繼續發送用于“打洞”的數據包，轉而開始真正的p2p數據傳輸。
3.5 p2p客戶端位于多層NAT設備后面
有的網絡拓撲結構包含了多個NAT設備，如果沒有掌握該拓撲結構的詳細信息，兩個客戶端之間是無法建立“最優化”的p2p路由的。現在我們來討論最后一種情況，如圖6所示。假定NAT C是由ISP(Internet Service Provider)提供的工業級的NAT設備，NAT C提供將多個下屬的用戶NAT或用戶節點映射到有限的幾個公網IP的服務，NAT A和NAT B做為NAT C的內網節點將把用戶的家庭網絡或內部網絡接入NAT C的內網，然后用戶的內部網絡就可以經由NAT C訪問公網了。從這種拓撲結構上來看，只有服務器S與NAT C是真正擁有公網可路由IP地址的設備，而NAT A和NAT B所使用的“公網”IP地址，實際上是由ISP服務提供商設定的（相對于NAT C而言）內網地址（本位的后續部分我把這個由ISP提供的內網地址相對于NAT A和NAT B稱之為“偽”公網地址），同理隸屬于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）
現在假定客戶端A和B希望通過UDP“打洞”完成兩個客戶端的p2p直連。最優化的路由策略是客戶端A向客戶端B的“偽公網”IP上發送數據包，即ISP服務提供商指定的內網IP，NAT B的“偽”公網endpoint，10.0.1.2:55000。由于從服務器S的角度只能觀察到真正的公網地址，也就是NAT A，NAT B在NAT C建立的session的真正的公網地址155.99.25.11:62000以及155.99.25.11:62005，所以非常不幸，客戶端A與客戶端B是無法通過服務器S知道這些“偽”公網的地址的。而且即使客戶端A和B通過某種手段可以得到NAT A和NAT B的“偽”公網地址，我們仍然不建議采用上述的“最優化”的打洞方式，這是因為這些地址是由ISP服務提供商提供的或許會存在與客戶端本身所在的內網地址重復的可能性。（例如：NAT A的內網的IP地址域恰好與NAT A在NAT C的“偽”公網IP地址域重復，這樣就會導致打洞數據包無法發出的問題）
因此客戶端別無選擇，只能使用由公網服務器S觀察到的A，B的公網endpoint進行“打洞”操作，用于“打洞”的數據包將由NAT C進行轉發，這里NAT C是否支持“發夾”轉換或“環路”轉換非常重要，否則數據包將無法由NAT C轉發給NAT A和NAT B，進而無法到達客戶端A和B。當客戶端A向客戶端B的公網endpoint（155.99.25.11:62005）發送UDP數據包的時候，NAT A首先把數據包的源endpoint由A的內網endpoint（10.0.0.1:4321）轉換為“偽”公網endpoint（10.0.1.1: 45000），現在數據包到了NAT C，NAT C應該可以識別出來該數據包是要發往自身轉換過的公網endpoint，如果NAT C可以給出“合理”響應的話，NAT C將把該數據包的源endpoint改為155.99.25.11:62000，目的endpoint改為10.0.1.2:55000，即NAT B的“偽”公網endpoint，NAT B最后會將收到的數據包發往客戶端B。同樣，由B發往A的數據包也會經過類似的過程。也有很多NAT設備不支持類似這樣的“發夾”轉換，但是已經有越來越多的NAT設備生產廠商開始加入對該轉換的支持。
3.6 UDP在空閑狀態下的超時問題
由于UDP轉換協議提供的“洞”不是絕對可靠的，多數NAT設備內部都有一個UDP轉換的空閑狀態計時器，如果在一段時間內沒有UDP數據通信，NAT設備會關掉由“打洞”操作打出來的“洞”，做為應用程序來講如果想要做到與設備無關，就最好在穿越NAT的以后設定一個穿越的有效期。很遺憾目前沒有標準有效期，這個有效期與NAT設備內部的配置有關，最短的只有20秒左右。在這個有效期內，即使沒有p2p數據包需要傳輸，應用程序為了維持該 “洞”可以正常工作，也必須向對方發送“打洞”維持包。這個維持包是需要雙方應用都發送的，只有一方發送不會維持另一方的session正常工作。除了頻繁發送“打洞”維持包以外，還有一個方法就是在當前的“洞”有效期過期之前，p2p客戶端雙方重新“打洞”，丟棄原有的“洞”，這也不失為一個有效的方法。
4 關于TCP打洞技術建立穿越NAT設備的p2p的TCP連接只比UDP復雜一點點，TCP協議的“打洞”從協議層來看是與UDP的“打洞”過程非常相似的。盡管如此，基于TCP協議的打洞至今為止還沒有被很好的理解，這也造成了對其提供支持的NAT設備不是很多。在NAT設備支持的前提下，基于TCP的 “打洞”技術實際上與基于UDP的“打洞”技術一樣快捷、可靠。實際上，只要NAT設備支持的話，基于TCP的p2p技術的健壯性將比基于UDP的技術的更強一些，因為TCP協議的狀態機給出了一種標準的方法來精確的獲取某個TCP session的生命期，而UDP協議則無法做到這一點。4.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”，該參數允許應用程序將多個套接字綁定到本地的一個endpoint（只要所有要綁定的套接字都設置了SO_REUSEADDR參數即可）。BSD系統引入了SO_REUSEPORT參數,該參數用于區分端口重用還是地址重用，在這樣的系統里面，上述所有的參數必須都設置才行。4.2 打開p2p的TCP流假定客戶端A希望建立與B的TCP連接。我們像通常一樣假定A和B已經與公網上的已知服務器S建立了TCP連接。服務器記錄下來每個聯入的客戶端的公網和內網的endpoints，如同為UDP服務的時候一樣。從協議層來看，TCP“打洞”與UDP“打洞”是幾乎完全相同的過程。1、客戶端A使用其與服務器S的連接向服務器發送請求，要求服務器S協助其連接客戶端B。2、S將B的公網和內網的TCP endpoint返回給A，同時，S將A的公網和內網的endpoint發送給B。3、客戶端A和B使用連接S的端口異步地發起向對方的公網、內網 endpoint的TCP連接，同時監聽各自的本地TCP端口是否有外部的連接聯入。4、A和B開始等待向外的連接是否成功，檢查是否有新連接聯入。如果向外的連接由于某種網絡錯誤而失敗，如：“連接被重置”或者“節點無法訪問”，客戶端只需要延遲一小段時間（例如延遲一秒鐘），然后重新發起連接即可，延遲的時間和重復連接的次數可以由應用程序編寫者來確定。5、TCP連接建立起來以后，客戶端之間應該開始鑒權操作，確保目前聯入的連接就是所希望的連接。如果鑒權失敗，客戶端將關閉連接，并且繼續等待新的連接聯入。客戶端通常采用“先入為主”的策略，只接受第一個通過鑒權操作的客戶端，然后將進入p2p通信過程不再繼續等待是否有新的連接聯入。
（圖 7）
與UDP 不同的是，使用UDP協議的每個客戶端只需要一個套接字即可完成與服務器S通信，并同時與多個p2p客戶端通信的任務，而TCP客戶端必須處理多個套接字綁定到同一個本地TCP端口的問題，如圖7所示。現在來看更加實際的一種情景，A與B分別位于不同的NAT設備后面，如圖5所示，并且假定圖中的端口號是 TCP協議的端口號，而不是UDP的端口號。圖中向外的連接代表A和B向對方的內網endpoint發起的連接，這些連接或許會失敗或者無法連接到對方。如同使用UDP協議進行“打洞”操作遇到的問題一樣，TCP的“打洞”操作也會遇到內網的IP與“偽”公網IP重復造成連接失敗或者錯誤連接之類的問題。客戶端向彼此公網endpoint發起連接的操作，會使得各自的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 從應用程序的角度來看TCP“打洞”從應用程序的角度來看，在進行TCP“打洞”的時候都發生了什么呢？假定A首先向B發出SYN包，該包發往B的公網 endpoint，并且被B的NAT設備丟棄，但是B發往A的公網endpoint的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的公網endpoint，并且將使用先前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的公網endpoint的連接會以失敗告終。盡管A向B的連接失敗，A仍然得到了B發起的向A的連接，等效于A與B之間已經聯通，不管中間過程如何，A與B已經連接起來了，結果是A和B的基于TCP協議的p2p連接已經建立起來了。第一種結果適用于基于BSD的操作系統對于TCP的實現，而第二種結果更加普遍一些，多數linux和windows系統都會按照第二種結果來處理。