udp打洞技術依賴於由公共防火牆和cone nat，允許適當的有計畫的端對端應用程式通過
nat「打洞」，即使當雙方的主機都處於nat之後。這種技術在 rfc3027的5.1節[nat prot]
中進行了重點介紹，並且在internet[kegel]中進行了非正式的描敘，還應用到了最新的一些協
議，例如[teredo,ice]協議中。不過，我們要注意的是，「術」如其名，udp打洞技術的可靠
性全都要依賴於udp。
這裡將考慮兩種典型場景，來介紹連線的雙方應用程式如何按照計畫的進行通訊的，第一
種場景，我們假設兩個客戶端都處於不同的nat之後；第二種場景，我們假設兩個客戶端都處
於同乙個nat之後，但是它們彼此都不知道(他們在同乙個nat中)。
3.3.1. peers behind different nats 處於不同nat之後的客戶端通訊
我們假設 client a 和 client b 都擁有自己的私有ip位址，並且都處在不同的nat之後，端對端
的程式執行於 client a,client b,s之間，並且它們都開放了udp埠1234。 client a和
client b首先分別與s建立通訊會話，這時nat a把它自己的udp埠62000分配給client a
與s的會話，nat b也把自己的udp埠31000分配給client b與s的會話。
假如這個時候 client a 想與 client b建立一條udp通訊直連，如果 client a只是簡單的
傳送乙個udp資訊到client b的公網位址138.76.29.7:31000的話，nat b會不加考慮的將這個
資訊丟棄（除非nat b是乙個 full cone nat），因為 這個udp資訊中所包含的位址資訊，與
client b和伺服器s建立連線時儲存在nat b中的伺服器s的位址資訊不符。同樣的，client
b如果做同樣的事情，傳送的udp資訊也會被 nat a 丟棄。
假如 client a 開始傳送乙個 udp 資訊到 client b 的公網位址上，與此同時，他又通
過s中**送了乙個邀請資訊給client b，請求client b也給client a傳送乙個udp資訊到
client a的公網位址上。這時client a向client b的公網ip(138.76.29.7:31000)傳送的資訊
導致 nat a 開啟乙個處於 client a的私有位址和client b的公網位址之間的新的通訊會
話，與此同時，nat b 也開啟了乙個處於client b的私有位址和client a的公網位址
(155.99.25.11:62000)之間的新的通訊會話。一旦這個新的udp會話各自向對方開啟了，client
a和client b之間就可以直接通訊，而無需s來牽線搭橋了。(這就是所謂的打洞技術)！
udp打洞技術有很多實用的地方：第一，一旦這種處於nat之後的端對端的直連建立之
後，連線的雙方可以輪流擔任 對方的「媒人」，把對方介紹給其他的客戶端，這樣就極大的
降低了伺服器s的工作量；第二，應用程式不用關心這個nat是屬於cone還是symmetric，即便
要，如果連線的雙方有一方或者雙方都恰好不處於nat之後，基於上敘的步驟，他們之間還是
可以建立很好的通訊通道；第三，打洞技術能夠自動運作在多重nat之後，不論連線的雙方經
過多少層nat才到達internet，都可以進行通訊。
3.3.2. peers behind the same nat 客戶端都處於相同的nat之後
現在讓我們來考慮一下兩個客戶端(很有可能不知不覺的就會)同時位於相同的nat之後，
而且是在同乙個子網內部的情況， client a與s之間的會話使用了nat的62000埠，client b與
s之間的會話使用了62001埠
我們假設，client a 和 client b 要使用上一節我們所描述的「udp打洞技術」，並通過服
務器s這個「媒人」來認識，這樣client a 和client b首先從服務端s得到了彼此的公網ip位址和
埠，然後就往對方的公網ip位址和埠上傳送訊息。在這種情況下，如果nat 僅僅允許在內
部網主機與其他內部網主機（處於同乙個nat之後的網路主機）之間開啟udp會話通訊通道，
而內部網主機與其他外部網主機就不允許的話，那麼client a 和client b就可以通話了。我們把
這種情形叫做「loopback translation」(「回環轉換」)，因為資料報首先從區域網的私有ip傳送到
nat轉換，然後「繞一圈」，再回到區域網中來，但是這樣總比這些資料通過公網傳送好。舉
例來說，當 client a傳送了乙個udp資料報到 client b的公網ip位址，這個資料報的報頭中就會
有乙個源位址10.0.0.1:124和乙個目標位址155.99.25.11:62001。nat接收到這個包以後，就會
(進行位址轉換)解析出這個包中有乙個公網位址源位址155.99.25.11:62000和乙個目標位址
10.1.1.3:1234，然後再傳送給b，雖說nat支援「loopback translation」，我們也發現，在這種情形
下,這個解析和傳送的過程有些多餘，並且這個client a 和client b 之間的對話可能潛在性地給
nat增加了負擔。
其實，解決這個問題的方案是顯而易見的。當 client a和clientb 最初通過伺服器s交換彼此
的位址資訊時，它們應該發現了自己的ip位址和埠，也就是自己的 local ip，同時，加上
server s發現的它們的公網位址和埠（即nat分配給它們的） 。兩個客戶端同時的傳送資料
包到對方的公網位址和私有位址上，然後選擇首先使得通訊成功的那個位址就可以了。如果兩
個客戶端都位於同乙個nat之後，那麼發往私有位址的資料報應該先於發往公網位址的資料報
到達，這樣就建立了乙個不包括nat的直連通訊通道。如果兩個客戶端位於不同nat之後，雖
然傳送到對方私有位址的資料報會毫無疑問的傳送失敗，但還是很有可能使用他們各自的公網
ip位址來建立一條通訊通道的。所以檢測這些資料報的方法和工作就變得非常重要，不論如
何，只要雙方都處於不同nat之後，就完全有可能 client a 想傳送到 client b 的資訊會被發到
別的無關的地方去，反之亦然（client b 想傳送到 client a的訊息也會被發到別的無關的地方
去）。
TCP打洞和UDP打洞
1，tcp協議通訊 現在有兩台電腦a和b。在 假設a的位址為 192.168.0.100 假設b的位址為 192.168.0.102 a想給b傳送乙個字串hello,如果a,b之間採用tcp協議，那麼b收到hello的過程是怎樣的呢？首先建立連線 3次握手成功之後，a和b的鏈結才算成功 然後a在給b...
關於TCP打洞和UDP打洞
解決辦法是 a向b的公網ip傳送乙個資料報，則nat a能接收來自nat b的資料報並 給a了 即b現在能訪問a了 再由s命令b向a的公網ip傳送乙個資料報，則nat b能接收來自nat a的資料報並 給b了 即a現在能訪問b了 以上就是 打洞 的原理。但是tcp和udp在打洞上卻有點不同。這是因為...
打洞之我見
兩個處在不同內網的機器上的應用要想直接通訊 不通過第三方來交換資料 由於互相並不知道彼此的外網ip，是做不到的。當然如果是人為干預，你知道了彼此機器的外網ip，並做好埠對映的設定，兩個是能夠互相通訊的，而這裡說的，是在互不相知的情況下如何建立通訊 這也符合生活常理，因為你較少的關注過你自己的外網ip...