NAT穿越
原文版權(quán)：Copyright (C) The Internet Society (2003).All Rights Reserved.
原文地址：
http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt譯文版權(quán)申明：請引用此文的作者或網(wǎng)站注明出處：
http://blog.csdn.net/hxhbluestar，以尊重譯者的勞動成果！隨著IPv6時代的到來，我也一直懷疑，是不是還有必要再去學(xué)習(xí)NAT技術(shù)——因?yàn)榫W(wǎng)絡(luò)的資源不再如IPv4時代匱乏，而NAT技術(shù)正是為解決IP地址的緊缺而存在的，如此，NAT便沒有存在的必要了。
但是，隨著這篇文章的翻譯，我的懷疑慢慢變成慶幸，漸而又變?yōu)榭隙?，通過翻譯所學(xué)到的東西，不再僅僅是翻譯第一手資料帶來的成就感，更多的是通過翻譯，去領(lǐng)悟技術(shù)前輩們的智慧與經(jīng)驗(yàn)，也通過翻譯，養(yǎng)成自己從第一手資料獲得信息的習(xí)慣，從而將視野放得更寬，讓理解更為透徹——至少，很多東西都是要經(jīng)過仔細(xì)斟酌才真正轉(zhuǎn)化為自己思想的一部分的。正是如此，我才堅定的要把這篇文章翻譯完，也如之前所提到的，如果時間允許的話，我會用C#來寫一些例子，讓大家更好的理解NAT技術(shù)，掌握NAT技術(shù)（主要涉及到即時通訊、文件對等傳輸和語音應(yīng)用三個方面）。
這篇文章主要是介紹一下“代理”機(jī)制的起因以及給P2P應(yīng)用帶來的不便，不需要任何基礎(chǔ)知識：）
1. Introduction
1、簡介
關(guān)鍵詞：
middleboxe(s) —— 我翻譯成“代理”，也許有更好的翻譯
host —— 我翻譯成“主機(jī)”，希望大家不要理解成服務(wù)器了，主機(jī)就是一臺普通的終端機(jī)
在當(dāng)今的Internet中，普遍存在使用“代理”設(shè)備來進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT），導(dǎo)致這種現(xiàn)象的原因是 IPV4 地址空間的資源耗盡危機(jī)。雖然不對稱 asymmetric 的地址分配和連通性制度已經(jīng)在代理中被定義，但是卻給端對端應(yīng)用程序和協(xié)議制定造成了一些特殊的問題。像電話會議和多媒體網(wǎng)絡(luò)游戲。這些問題即使在 IPV6世界中還是會存在，因?yàn)镹AT作為IPV4的一種兼容性機(jī)制經(jīng)常被使用[NAT-PT]，并且防火墻將仍然將普遍存在，即使不再需要NAT技術(shù)。
當(dāng)前使用的“代理”技術(shù)主要是為 客戶端/服務(wù)端 C/S 結(jié)構(gòu)設(shè)計的，為了實(shí)現(xiàn)那些需要連接但是又沒有固定IP地址的客戶端能夠連接到一臺配置好的擁有固定IP和DNS域名的服務(wù)器。
大 多數(shù)的“代理”使用一種 asymmetric 通信模型，即 私網(wǎng)（局域網(wǎng)） 的主機(jī)能發(fā)起一個“外出”連接去連接公網(wǎng)上的主機(jī)。但是公網(wǎng)上的主機(jī)卻無法發(fā)送信息給私網(wǎng)上的主機(jī)（除非對“代理”進(jìn)行特殊的配置），NAPT（網(wǎng)絡(luò)地址端口轉(zhuǎn)換）的普通情況是，一個私網(wǎng)客戶端不需要一個公網(wǎng)的固定的IP地址，但是必須要共享一個由NAPT控制的公網(wǎng)的固定IP地址（當(dāng)然這個NAPT是處于同一個私網(wǎng)內(nèi)部的）。這樣的話，這些匿名的并且看起來難以觸及的藏在NAT之后的內(nèi)網(wǎng)主機(jī)對于像 Web瀏覽器這種軟件來說就不是一個問題,因?yàn)閮?nèi)網(wǎng)的主機(jī)只需要發(fā)起向外部的連接就可以了。這樣一來，無法觸及也還是有他的優(yōu)點(diǎn)的——那就是具有保密性。
然而，在P2P的應(yīng)用中，Internet上的“客戶機(jī)”之間是需要建立一個通信會話直連的。邀請者和響應(yīng)者也許會處于不同的NAT之后，也許他們都沒有固定IP或者即使有也不是公網(wǎng)的IP地址。舉例來說，在一個普通的網(wǎng)絡(luò)游戲體系結(jié)構(gòu)中，都是通過客戶端向一個具有公網(wǎng)固定IP的服務(wù)器發(fā)起申請進(jìn)行初始化并通過驗(yàn)證的。同時，客戶端之間也要建立直連，才使網(wǎng)絡(luò)間傳輸?shù)乃俣燃涌?，保證數(shù)據(jù)即時更新（不然搶不到裝備啊，呵呵）。
同樣的，一個文件共享應(yīng)用程序也必須通過到一個服務(wù)器上去查找它想要的資源，然后再到擁有這個數(shù)據(jù)的主機(jī)上去下載（BT網(wǎng)站，走了一個中介），“代理”造成了很多P2P直連的問題，因?yàn)椴卦?#8220;代理”之后的的主機(jī)通常沒有固定的端口來使其他的客戶端發(fā)起的TCP或UDP連接能夠最終到達(dá)。
RFC 3235[NAT-APPL] 簡要的提到了這個問題，但是沒有給出任何的解決方案。
在這篇文章中，我們用兩種方式討論 P2P/代理的問題。首先，概要的講敘已有的P2P應(yīng)用程序能夠在現(xiàn)有的代理機(jī)制中的工作原理。然后，我們提供一組應(yīng)用程序設(shè)計指南，基于已有的實(shí)踐，在現(xiàn)有的配置好的代理上，來使得P2P應(yīng)用程序操作更加有條理。最后，我們提供了設(shè)計指南，為以后的代理機(jī)制能夠更方便支持P2P應(yīng)用程序。討論的焦點(diǎn)是如何直接的、廣泛的 配置那些需要經(jīng)過“代理”的P2P應(yīng)用程序。
2. 術(shù)語
在這一章節(jié)中，首先概要的介紹一下“代理”技術(shù)的一些術(shù)語。然后集中討論兩種造成P2P應(yīng)用問題的代理機(jī)制。
防火墻
防火墻限制了私網(wǎng)與公網(wǎng)的通信，它主要是將（防火墻）認(rèn)為未經(jīng)授權(quán)的的包丟棄，防火墻只是檢驗(yàn)包的數(shù)據(jù)，并不修改數(shù)據(jù)包中的IP地址和TCP/UDP端口信息。
網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）
當(dāng)有數(shù)據(jù)包通過時，網(wǎng)絡(luò)地址轉(zhuǎn)換器不僅檢查包的信息，還要將包頭中的IP地址和端口信息進(jìn)行修改。以使得處于NAT之后的機(jī)器共享幾個僅有的公網(wǎng)IP地址（通常是一個）。網(wǎng)絡(luò)地址轉(zhuǎn)換器主要有兩種類型：
基礎(chǔ)NAT
基礎(chǔ)NAT 將私網(wǎng)主機(jī)的私有IP地址轉(zhuǎn)換成公網(wǎng)IP地址，但并不將TCP/UDP端口信息進(jìn)行轉(zhuǎn)換。基礎(chǔ)NAT一般用在當(dāng)NAT擁有很多公網(wǎng)IP地址的時候，它將公網(wǎng)IP地址與內(nèi)部主機(jī)進(jìn)行綁定，使得外部可以用公網(wǎng)IP地址訪問內(nèi)部主機(jī)。（譯者注：實(shí)際上是只將IP轉(zhuǎn)換，192.168.0.23 <-> 210.42.106.35,這與直接設(shè)置IP地址為公網(wǎng)IP還是有一定區(qū)別的，特別是對于企業(yè)來說，外部的信息都要經(jīng)過統(tǒng)一防火墻才能到達(dá)內(nèi)部，但是內(nèi)部主機(jī)又可以使用公網(wǎng)IP）
網(wǎng)絡(luò)地址和端口轉(zhuǎn)換 （NAPT）
這是最普遍的情況，網(wǎng)絡(luò)地址/端口轉(zhuǎn)換器檢查、修改包的IP地址和TCP/UDP端口信息，這樣，更多的內(nèi)部主機(jī)就可以同時使用一個公網(wǎng)IP地址。
請參考[NAT-TRAD]和[NAT-TERM]兩個文檔了解更多的NAT分類和術(shù)語信息。另外，關(guān)于NAPT的分類和術(shù)語，[STUN]在最近做了更多的定義。當(dāng)一個內(nèi)部網(wǎng)主機(jī)通過NAT打開一個“外出”的TCP或UDP會話時，NAPT分配給這個會話一個公網(wǎng)IP和端口，用來接收外網(wǎng)的響應(yīng)的數(shù)據(jù)包，并經(jīng)過轉(zhuǎn)換通知內(nèi)部網(wǎng)的主機(jī)。這樣做的效果是，NAPT在 [私有IP:私有端口] 和[公網(wǎng)IP:公網(wǎng)端口]之間建立了一個端口綁定。
端口綁定指定了NAPT將在這個會話的生存期內(nèi)進(jìn)行地址轉(zhuǎn)換任務(wù)。這中間存在一個這樣的問題，如果P2P應(yīng)用程序從內(nèi)部網(wǎng)絡(luò)的一個[私有IP地址:端口]對同時發(fā)出多條會話給不同的外網(wǎng)主機(jī)，那么NAT會怎樣處理呢？請看以下幾種方案。
錐形NAT
（譯者注：為什么叫做錐形呢？請看以下圖形,終端和外部服務(wù)器，都通過NAT分派的這個綁定地址對來傳送信息，就象一個漏斗一樣，篩選并傳遞信息）
當(dāng)建立了一個 [私有IP:端口]-[公網(wǎng)IP:端口] 端口綁定之后，對于來自同一個[私有IP:端口]會話，錐形NAT服務(wù)器允許發(fā)起會話的應(yīng)用程序重復(fù)使用這個端口綁定，一直到這個會話結(jié)束才解除（端口綁定）。
例 如，假設(shè) Client A（IP地址信息如上圖所示）通過一個 錐形NAT 同時發(fā)起兩個外出的連接，它使用同一個內(nèi)部端口（10.0.0.1:1234）給公網(wǎng)的兩臺不同的服務(wù)器，S1和S2。錐形NAT 只分配一個公網(wǎng)IP和端口（155.99.25.11:62000）給這個兩個會話，通過地址轉(zhuǎn)換可以 確保 Client使用端口的“同一性”（譯者注：即這個Client只使用這個端口）。而基礎(chǔ)NATs和防火墻卻不能修改經(jīng)過的數(shù)據(jù)包端口號，它們可以看作是錐形NAT的精簡版本。
對稱NAT
對稱NAT，與Cone NAT是大不相同的，并不對會話進(jìn)行端口綁定，而是分配一個全新的 公網(wǎng)端口 給每一個新的會話。
還 是上面那個例子：如果 Client A (10.0.0.1:1234)同時發(fā)起兩個 "外出" 會話,分別發(fā)往S1和S2。對稱Nat會分配公共地址155.99.25.11:62000給Session1，然后分配另一個不同的公共地址 155.99.25.11:62001給Session2。對稱Nat能夠區(qū)別兩個不同的會話并進(jìn)行地址轉(zhuǎn)換，因?yàn)樵?Session1 和 Session2中的外部地址是不同的，正是因?yàn)檫@樣，Client端的應(yīng)用程序就迷失在這個地址轉(zhuǎn)換邊界線了，因?yàn)檫@個應(yīng)用程序每發(fā)出一個會話都會使用一個新的端口，無法保障只使用同一個端口了。
在TCP和UDP通信中，（到底是使用同一個端口，還是分配不同的端口給同一個應(yīng)用程序），錐形NAT和對稱NAT各有各的理由。當(dāng)然錐形NAT在根據(jù)如何公平地將NAT接受的連接直達(dá)一個已創(chuàng)建的地址對上有更多的分類。這個分類一般應(yīng)用在Udp通信（而不是Tcp通信上），因?yàn)镹ATs和防火墻阻止了試圖無條件傳入的TCP連接，除非明確設(shè)置NAT不這樣做。這些分類如下：
全雙工錐形NAT
當(dāng)內(nèi)部主機(jī)發(fā)出一個“外出”的連接會話，就會創(chuàng)建了一個 公網(wǎng)/私網(wǎng)地址，一旦這個地址對被創(chuàng)建，全雙工錐形NAT會接收隨后任何外部端口傳入這個公共端口地址的通信。因此，全雙工錐形NAT有時候又被稱為"混雜"NAT。
受限制的錐形NAT
受限制的錐形NAT會對傳入的數(shù)據(jù)包進(jìn)行篩選，當(dāng)內(nèi)部主機(jī)發(fā)出“外出”的會話時，NAT會記錄這個外部主機(jī)的IP地址信息，所以，也只有這些有記錄的外部 IP地址，能夠?qū)⑿畔魅氲絅AT內(nèi)部，受限制的錐形NAT 有效的給防火墻提煉了篩選包的原則——即限定只給那些已知的外部地址“傳入”信息到NAT內(nèi)部。
端口受限制的Cone NAT
端口受限制的錐形NAT，與受限制的錐形NAT不同的是：它同時記錄了外部主機(jī)的IP地址和端口信息，端口受限制的錐形NAT給內(nèi)部節(jié)點(diǎn)提供了同一級別的保護(hù)，在維持端口“同一性”過程中，將會丟棄對稱NAT傳回的信息。
最后，在這篇文檔里我們將定義一組新的術(shù)語 ，以便更好的對P2P代理相關(guān)的行為進(jìn)行分類。
P2P應(yīng)用程序
P2P應(yīng)用程序是指，在已有的一個公共服務(wù)器的基礎(chǔ)上，并分別利用自己的私有地址或者公有地址（或者兩者兼?zhèn)洌﹣斫⒁粋€端到端的會話通信。
P2P代理
P2P代理是一個允許 P2P應(yīng)用程序進(jìn)行通信的代理機(jī)制
P2P防火墻
P2P防火墻是一個提供了防火墻的功能的P2P代理，但是不進(jìn)行地址轉(zhuǎn)換.
P2P-NAT
P2P-NAT 是一個 P2P代理,提供了NAT的功能,也提供了防火墻的功能,一個最簡的P2P代理必須具有錐形NAT對Udp通信支持的功能,并允許應(yīng)用程序利用Udp打洞技術(shù)建立強(qiáng)健的P2P連接。
回環(huán)轉(zhuǎn)換
當(dāng)NAT的私網(wǎng)內(nèi)部機(jī)器想通過公共地址來訪問同一臺局域網(wǎng)內(nèi)的機(jī)器的時，NAT設(shè)備等價于做了兩次NAT的事情，在包到達(dá)目標(biāo)機(jī)器之前，先將私有地址轉(zhuǎn)換為公網(wǎng)地址，然后再將公網(wǎng)地址轉(zhuǎn)換回私有地址。我們把具有上敘轉(zhuǎn)換功能的NAT設(shè)備叫做“回環(huán)轉(zhuǎn)換”設(shè)備。
3、基于代理服務(wù)上的P2P通信技術(shù)
本章節(jié)詳細(xì)地回顧了當(dāng)前比較流行的一些基于當(dāng)前代理設(shè)備的點(diǎn)對點(diǎn)通信技術(shù)，來源于應(yīng)用或協(xié)議設(shè)計者的前瞻。
3.1 轉(zhuǎn)發(fā)
最可靠，但又是最低效的點(diǎn)對點(diǎn)通信方法，莫過于將p2p網(wǎng)絡(luò)通信看作一個C/S結(jié)構(gòu)，通過（服務(wù)器來）轉(zhuǎn)發(fā)信息。舉例來說，如下圖，兩個客戶端A和B，均與服務(wù)器S初始化了一個TCP或UDP連接，服務(wù)器S具有公網(wǎng)固定IP地址,兩個客戶端分布在不同的私網(wǎng)中，這樣，他們各自的NAT代理服務(wù)器將不允許他們進(jìn)行直連。
取而代之的方式是，兩個客戶端可以把服務(wù)器S當(dāng)作信使來轉(zhuǎn)發(fā)消息。比如，為了將消息發(fā)送到B，A先發(fā)送一條信息給服務(wù)器S，服務(wù)器S再利用初始化時已經(jīng)建立的連接，將信息轉(zhuǎn)發(fā)給B。
4.程序設(shè)計指南
4.1. P2P代理的現(xiàn)狀
對于兩端都處于NAT之后的P2P直連，當(dāng)前最佳解決方案仍然是UDP打洞技術(shù)，而在各種NAT系統(tǒng)中這種技術(shù)也得到了相當(dāng)廣泛的應(yīng)用。當(dāng)程序需要進(jìn)行有效的p2p直連的通訊時候，推薦使用UDP打洞技術(shù)，當(dāng)然，當(dāng)無法建立直連時，也要做好消息轉(zhuǎn)發(fā)的處理。
4.2. 位于同一個NAT后的端與端通信指南
在實(shí)際的情況中，還有相當(dāng)大一部分用戶不止兩個IP地址（多網(wǎng)卡情況），而是三個或者更多，這種情況下，如果很難決定到底使用哪個地址來注冊到服務(wù)器，就要應(yīng)用程序?qū)⑺械牡刂范甲缘椒?wù)器上去。
4.3. 主機(jī)發(fā)現(xiàn)
應(yīng)用程序發(fā)送很多包到網(wǎng)絡(luò)的幾個地址上，用于發(fā)現(xiàn)哪個地址對于指定的主機(jī)來說是最好的。這樣是導(dǎo)致網(wǎng)絡(luò)“空間浪費(fèi)”的源頭之一，就象是在網(wǎng)絡(luò)上倒垃圾一樣；端將會選擇不正確的路由地址；就像在內(nèi)部網(wǎng)中一樣（例如：11.0.1.1，分配給DOD [DOD還不能確定是什么，查到相關(guān)文獻(xiàn)是與美國國防部相關(guān)的協(xié)議] 的）;因此應(yīng)用程序在發(fā)送hello包時，應(yīng)該小心地練習(xí)。(這段話翻譯得不是很好，請求指正)
4.4. 基于TCP 的P2P應(yīng)用程序
套 接字API被應(yīng)用程序開發(fā)者廣泛地使用，但它其實(shí)最初是專門設(shè)計用于 C/S模式的應(yīng)用程序的。由于這個自身原因，就出現(xiàn)了一些限制：一個套接字只能綁定一個TCP或者UDP端口；應(yīng)用程序不允許多個套接字綁定同一個端口（TCP或UDP）用于同時與多個外部節(jié)點(diǎn)建立會話；也不允許使用一個套接字來監(jiān)聽這個端口的同時，其他套接字通過這個端口發(fā)出向外的初始化會話連接。
上面所說的“單一套接字對應(yīng)單一端口”綁定約束對于UDP來說并不算一個障礙，因?yàn)閁DP是一個基于數(shù)據(jù)報的協(xié)議。UDP P2P應(yīng)用程序設(shè)計者可以用recvfrom()和sendto()函數(shù)來讓一個SOCKET不僅發(fā)送而且可以從多個主機(jī)上接受數(shù)據(jù)報文。
但是 TCP就不一樣了。TCP中，每個進(jìn)入和外出的連接都和一個單獨(dú)的套接字保持關(guān)聯(lián)。Linux 套接字API中使用 SO_REUSEADDR 選項標(biāo)記了這個問題。在FreeBSD和NetBSD上，這個選項一般來說是無法正常工作的，但是，可以將其改為使用BSD-specific SetReuseAddress call(Linux中并沒有這個命令，純Unix標(biāo)準(zhǔn)中亦不存在），就可以使用了。Win32 API提供了一個等效的SetReuseAddress 命令。使用以上所提到的選項，應(yīng)用程序就能使用多個套接字用來重用TCP端口。那就是說，打開兩個TCP套接字流綁定使用同一個端口，只要使用 listen()在一邊并在另外一邊使用connect()在另外一端。
4.5. 使用 MidCom 協(xié)議
如果應(yīng)用程序知道它們需要穿越的代理并且這些代理實(shí)現(xiàn)Midcom協(xié)議，應(yīng)用程序能使用Midcom協(xié)議更容易的穿越代理。
例如：P2P 應(yīng)用程序需要NAT代理保持終端端口的綁定狀態(tài)。假如代理可以支持Midcom，P2P應(yīng)用程序可以控制修改綁定端口(或者綁定地址)的參數(shù)，例如生存時間，最大空閑時間，因此應(yīng)用程序不僅可以直接的連接外部主機(jī)而且也可以從外部主機(jī)接受連接；這樣就不需要定期保持端口綁定的狀態(tài)。當(dāng)應(yīng)用程序不再需要綁定，也可以使用Midcom協(xié)議簡單的取消綁定。
參考：MidCom方案
MidCom（Middlebox Communications）方案是通過在第三方實(shí)體和FW/NAT之間建立中間盒來通信，使FW/NAT設(shè)備變?yōu)榭煽氐囊环N新的概念。如圖所示，MidCom包括MidCom Agent和Middlebox，Agent通過MidCom協(xié)議通知Middlebox建立相應(yīng)的NAT映射表項。
一般情況下，Middlebox集成在NAT或FW設(shè)備中，Agent可在軟交換、代理服務(wù)器或終端上實(shí)現(xiàn)。
由 于應(yīng)用業(yè)務(wù)識別的智能從Middlebox移到外部的MidCom Agent上，因此，根據(jù)MidCom的架構(gòu)，在不需要更改Middlebox基本特性的基礎(chǔ)上，通過對MidCom Agent的升級就可以支持更多的新業(yè)務(wù)。這是相對于NAT/ALG方式的一個很大的優(yōu)勢。
從安全性考慮，MidCom方式支持控制報文和媒體流的加密，因此安全性比較高。
這個方法的優(yōu)勢是：當(dāng)兩個客戶端都與服務(wù)端保持連接的時候，它將始終如一的正常工作。
但是它的劣勢也很明顯:它將全面依賴并消耗服務(wù)器的資源和性能和網(wǎng)絡(luò)帶寬。兩個客戶端的通信反應(yīng)時間將明顯增加，即使他們與服務(wù)器始終保持著連接。名為 TURN 的協(xié)議[TURN]定義了一個利用轉(zhuǎn)發(fā)技術(shù)進(jìn)行可靠通信的模型。
3.2 反向連接
這里介紹第二種技術(shù)，但是它只能在通信的兩端只有一端處于NAT之后的情況下。舉例來說，假設(shè)客戶端A處于NAT之后，而客戶端B有一個公網(wǎng)IP地址，如下圖所示
客戶端A的私有IP地址是10.0.0.1，并使用TCP端口1234，客戶端A初始化了一個與服務(wù)器S（IP=18.181.0.31:1235）的連接。NAT A（IP=155.99.25.11）分配了一個62000的TCP端口給這個連接。因此，服務(wù)器S認(rèn)為客戶端A的IP地址是 155.99.25.11:62000。而因?yàn)榭蛻舳薆擁有固定IP地址138.76.29.7，所以在這個端對端的連接中，客戶端B使用TCP端口 1234。
現(xiàn)在我們假設(shè)客戶端B將會與客戶端A初始化一個端對端連接會話。B將首先試圖
連 接A的任何一個地址——客戶端A認(rèn)為是它自己所有的地址，即10.0.0.1:1234。或者是從服務(wù)器S觀察到的地址,即 155.99.25.11:62000。然而不論是連接上敘地址中的哪一個，都不可能成功。第一種情況：試圖直接連到10.0.0.1肯定會失敗，因?yàn)?10.0.0.1根本就不是一個可以在公網(wǎng)上路由的IP地址；第二種情況，從B傳來的TCP SYN請求將能夠到達(dá)端口NAT A的端口62000，但NAT A卻會拒絕這個連接請求，因?yàn)橹挥型獬龅倪B接才允許（進(jìn)入）。
在所有的嘗試都失敗之后，客戶端B就只能借用服務(wù)器S來傳遞一個到客戶端A的請求，請求一個“翻轉(zhuǎn)”的連接到客戶端B，而客戶端A，在接受了這個通過服務(wù)器S轉(zhuǎn)發(fā)的請求之后，將打開一個與客戶端B通訊的TCP連接（在B的公網(wǎng)IP地址和端口號上）。NAT A允許這個連接通過，因?yàn)檫@個連接起源于NAT A的內(nèi)部，并且同時客戶端B能夠受這個連接因?yàn)锽并不位于NAT之后。
當(dāng)前很多p2p系統(tǒng)都使用了這種技術(shù)。它的主要限制在于：只能有一端位于NAT之后這個技術(shù)才能生效。然而當(dāng)今真實(shí)的情況是，越來越多的客戶端兩端都處于 NAT之后，那么這個方法就是不可行的。因?yàn)槟嫦蜻B接不是一個通用的解決方案，所以在這里就不推薦使用了。應(yīng)用程序可以選擇嘗試做逆向連接，但是有可能消息會被自動退回——如果另外一端的消息傳遞機(jī)制既不是“正向”也不是“逆向”連接的話。
Trackback:
http://tb.blog.csdn.net/TrackBack.aspx?PostId=3312893.3. UDP hole punching UDP打洞技術(shù)
第三種技術(shù)，也是這篇文章主要要研究的，就 是非常有名的“UDP打洞技術(shù)”，UDP打洞技術(shù)依賴于由公共防火墻和cone NAT，允許適當(dāng)?shù)挠杏媱澋亩藢Χ藨?yīng)用程序通過NAT“打洞”，即使當(dāng)雙方的主機(jī)都處于NAT之后。這種技術(shù)在 RFC3027的5.1節(jié)[NAT PROT] 中進(jìn)行了重點(diǎn)介紹，并且在Internet[KEGEL]中進(jìn)行了非正式的描敘，還應(yīng)用到了最新的一些協(xié)議，例如[TEREDO,ICE]協(xié)議中。不過，我們要注意的是，“術(shù)”如其名，UDP打洞技術(shù)的可靠性全都要依賴于UDP。
這里將考慮兩種典型場景，來介紹連接的雙方應(yīng)用程序如何按照計劃的進(jìn)行通信的，第一種場景，我們假設(shè)兩個客戶端都處于不同的NAT之后；第二種場景，我們假設(shè)兩個客戶端都處于同一個NAT之后，但是它們彼此都不知道(他們在同一個NAT中)。
3.3.1. Peers behind different NATs 處于不同NAT之后的客戶端通信
我們假設(shè) Client A 和 Client B 都擁有自己的私有IP地址，并且都處在不同的NAT之后，端對端的程序運(yùn)行于 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的會話。如下圖所示：
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
假如這個時候 CLIENT A 想與 CLIENT B建立一條UDP通信直連，如果 CLIENT A只是簡單的發(fā)送一個UDP信息到CLIENT B的公網(wǎng)地址138.76.29.7:31000的話，NAT B會不加考慮的將這個信息丟棄（除非NAT B是一個 full cone NAT），因?yàn)檫@個UDP信息中所包含的地址信息，與CLIENT B和服務(wù)器S建立連接時存儲在NAT B中的服務(wù)器S的地址信息不符。同樣的，CLIENT B如果做同樣的事情，發(fā)送的UDP信息也會被 NAT A 丟棄。
假如 CLIENT A 開始發(fā)送一個 UDP 信息到 CLIENT B 的公網(wǎng)地址上，與此同時，他又通過S中轉(zhuǎn)發(fā)送了一個邀請信息給CLIENT B，請求CLIENT B也給CLIENT A發(fā)送一個UDP信息到 CLIENT A的公網(wǎng)地址上。這時CLIENT A向CLIENT B的公網(wǎng)IP(138.76.29.7:31000)發(fā)送的信息導(dǎo)致 NAT A 打開一個處于 CLIENT A的私有地址和CLIENT B的公網(wǎng)地址之間的新的通信會話，與此同時，NAT B 也打開了一個處于CLIENT B的私有地址和CLIENT A的公網(wǎng)地址(155.99.25.11:62000)之間的新的通信會話。一旦這個新的UDP會話各自向?qū)Ψ酱蜷_了，CLIENT A和CLIENT B之間就可以直接通信，而無需S來牽線搭橋了。(這就是所謂的打洞技術(shù))！
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
UDP打洞技術(shù)有很多實(shí)用的地方：第一，一旦這種處于NAT之后的端對端的直連建立之后，連接的雙方可以輪流擔(dān) 任對方的“媒人”，把對方介紹給其他的客戶端，這樣就極大的降低了服務(wù)器S的工作量；第二，應(yīng)用程序不用關(guān)心這個NAT是屬于cone還是 symmetric，即便要，如果連接的雙方有一方或者雙方都恰好不處于NAT之后，基于上敘的步驟，他們之間還是可以建立很好的通信通道；第三，打洞技術(shù)能夠自動運(yùn)作在多重NAT之后，不論連接的雙方經(jīng)過多少層NAT才到達(dá)Internet，都可以進(jìn)行通信。
譯后小記：本來已經(jīng)翻譯好了，是在網(wǎng)文快捕中翻譯的，結(jié)果，一個全選把所有翻譯的內(nèi)容全部刪除了(網(wǎng)文快捕的Bug?：)，不得不痛苦的再翻一遍。不過，有失必有得，第二次翻譯流暢多了，希望大家讀來還順口。
3.3.2. Peers behind the same NAT 客戶端都處于相同的NAT之后
現(xiàn)在讓我們來考慮一下兩個客戶端(很有可能不知不覺的就會)同時位于相同的NAT之后，而且是在同一個子網(wǎng)內(nèi)部的情況， Client A與S之間的會話使用了NAT的62000端口，Client B與S之間的會話使用了62001端口，如下圖所示：
Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
我們假設(shè)，Client A 和 Client B 要使用上一節(jié)我們所描述的 “UDP打洞技術(shù)”，并通過服務(wù)器S這個“媒人”來認(rèn)識，這樣Client A 和Client B首先從服務(wù)端S得到了彼此的公網(wǎng)IP地址和端口，然后就往對方的公網(wǎng)IP地址和端口上發(fā)送消息。在這種情況下，如果NAT 僅僅允許在內(nèi)部網(wǎng)主機(jī)與其他內(nèi)部網(wǎng)主機(jī)（處于同一個NAT之后的網(wǎng)絡(luò)主機(jī)）之間打開UDP會話通信通道，而內(nèi)部網(wǎng)主機(jī)與其他外部網(wǎng)主機(jī)就不允許的話，那么 Client A 和Client B就可以通話了。我們把這種情形叫做“loopback translation”(“回環(huán)轉(zhuǎn)換”)，因?yàn)閿?shù)據(jù)包首先從局域網(wǎng)的私有IP發(fā)送到NAT轉(zhuǎn)換，然后“繞一圈”，再回到局域網(wǎng)中來，但是這樣總比這些數(shù)據(jù)通過公網(wǎng)傳送好。舉例來說，當(dāng) Client A發(fā)送了一個UDP數(shù)據(jù)包到 Client B的公網(wǎng)IP地址，這個數(shù)據(jù)包的報頭中就會有一個源地址10.0.0.1:124和一個目標(biāo)地址155.99.25.11:62001。NAT接收到這個包以后，就會(進(jìn)行地址轉(zhuǎn)換)解析出這個包中有一個公網(wǎng)地址源地址155.99.25.11:62000和一個目標(biāo)地址10.1.1.3:1234，然后再發(fā)送給B，雖說NAT支持“loopback translation”，我們也發(fā)現(xiàn)，在這種情形下,這個解析和發(fā)送的過程有些多余，并且這個Client A 和Client B 之間的對話可能潛在性地給NAT增加了負(fù)擔(dān)。
其 實(shí)，解決這個問題的方案是顯而易見的。當(dāng) Client A和ClientB 最初通過服務(wù)器S交換彼此的地址信息時，它們應(yīng)該發(fā)現(xiàn)了自己的IP地址和端口，也就是自己的 Local IP，同時，加上Server S發(fā)現(xiàn)的它們的公網(wǎng)地址和端口（即NAT分配給它們的） 。兩個客戶端同時的發(fā)送 數(shù)據(jù)包到對方的公網(wǎng)地址和私有地址上，然后選擇首先使得通信成功的那個地址就可以了。如果兩個客戶端都位于同一個NAT之后，那么發(fā)往私有地址的數(shù)據(jù)包應(yīng)該先于發(fā)往公網(wǎng)地址的數(shù)據(jù)包到達(dá)，這樣就建立了一個不包括NAT的直連通信通道。如果兩個客戶端位于不同NAT之后，雖然發(fā)送到對方私有地址的數(shù)據(jù)包會毫無疑問的發(fā)送失敗，但還是很有可能使用他們各自的公網(wǎng)IP地址來建立一條通信通道的。所以檢測這些數(shù)據(jù)包的方法和工作就變得非常重要，不論如何，只要雙方都處于不同NAT之后，就完全有可能 Client A 想發(fā)送到 Client B 的信息會被發(fā)到別的無關(guān)的地方去，反之亦然（Client B 想發(fā)送到 Client A的消息也會被發(fā)到別的無關(guān)的地方去）。
(最后一句“unrelated node on A's private network”沒有完全理解是什么意思，總之，放到整個語境中，應(yīng)該就是說，Client A 瞄準(zhǔn) Client B的私有地址端口的信息會被NAT轉(zhuǎn)發(fā)到別的地方去，因?yàn)閮烧咛幱诓煌腘AT之后，NAT A 如果在 內(nèi)部網(wǎng)絡(luò)找到了一個擁有與Client B相同的私有地址的電腦，就會把信息發(fā)送過去，這樣，就根本不會發(fā)送到 Client B 上去)
3.3.3. Peers separated by multiple NATs 客戶端分別處于多層NAT之后
在有些網(wǎng)絡(luò)拓?fù)渲芯痛嬖诙鄬覰AT設(shè)備，如果不熟悉網(wǎng)絡(luò)拓?fù)涞闹R，要想建立一條“理想的”端對端連接基本上是不可能的。讓我們來看看下圖這種情況：
Server S
18.181.0.31:1234
|
|
NAT X
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
|
+----------------------+----------------------+
| |
NAT A NAT B
192.168.1.1:30000 192.168.1.2:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
假如 NAT X 是由 Internet服務(wù)供應(yīng)商（ISP） 配置的一個 大型工業(yè) NAT，它使用少量的公網(wǎng)IP地址來為一些客戶群提供服務(wù)；NAT A 和 NAT B 則是為ISP的兩個客戶群所配置的小一點(diǎn)的獨(dú)立NAT網(wǎng)關(guān)，它們?yōu)楦髯钥蛻羧旱乃饺思彝ゾW(wǎng)絡(luò)提供IP地址。只有 Server S 和NAT X 擁有 公網(wǎng)固定IP地址，而NAT A 和 NAT B所擁有的“公網(wǎng)”IP地址對于ISP的尋址域來說則實(shí)際上“私有”的，這時 Client A的地址對于NAT A的尋址領(lǐng)域來說是“私有”的，Client B的地址對于NAT B的尋址域來說同樣是“私有”的。
還是跟以前一樣，每個客戶端都建立了一個“外出”的連接到服務(wù)器S，導(dǎo)致NATA 和 NAT B 分別進(jìn)行一次 公有/私有 轉(zhuǎn)換，并導(dǎo)致 NAT X 為 每個 會話都建立了一個 公有/私有 的轉(zhuǎn)換。（也就是把私有地址轉(zhuǎn)換成為公網(wǎng)地址的過程，NAT的本質(zhì)工作）
現(xiàn)在讓我們假設(shè) Client A 和 Client B 想要建立一條 端對端 的UDP 直連。理想的方法應(yīng)該是 Client A 發(fā)送一條 信息到 Client B 在NAT B的公網(wǎng)地址192.168.1.2:31000上,這個地址在ISP的尋址域內(nèi)；同時 Client B也發(fā)送一條消息到Client A 在 NAT B的公網(wǎng)地址上，也就是192.168.1.1:30000；如果能這樣發(fā)的話，問題就解決了?？上lient A和 Client B根本就不可能知道對方的這個地址，因?yàn)镾erver S只記錄了他們真正的公網(wǎng)地址155.99.25.11:62000和155.99.25.11:62001。即使 Client A 和 Client B 通過某種途徑得知了這些地址，還是不能夠保證這樣就能進(jìn)行通話了，因?yàn)檫@些地址是由ISP的私有尋址域分配的，可能會與私有域所分配的其他無關(guān)客戶端地址相沖突因此，如果客戶端之間想要進(jìn)行端對端的通信的話，別無選擇，只能通過他們真正的公網(wǎng)地址來進(jìn)行；并且 NAT X必須還得支持 “loopback translation”才行。
3.3.4. Consistent port bindings 保持端口綁定
在使用“UDP打洞技術(shù)”時有一點(diǎn)必須要注意：它只能在雙方的NAT都是cone NAT（或者干脆沒有NAT）時才能正常工作；這些NAT在自己的公網(wǎng)UDP端口被使用時保持著端口的綁定——[私有IP，私有UDP端口]對和[公網(wǎng) IP，公網(wǎng)UDP端口]對的一一對應(yīng)。如果像 symmetricNAT那樣給每個新的會話都分配一個新的公網(wǎng)端口，那么UDP應(yīng)用程序想要與其他外部客戶端進(jìn)行通話，就無法重復(fù)使用已經(jīng)建立好的通信轉(zhuǎn)換。
伴隨著 cone NAT 的推廣，“UDP打洞技術(shù)”也被越來越廣泛的應(yīng)用。然而，仍存在一小部分使用 symmetric NAT 的網(wǎng)絡(luò)，那么在這小部分網(wǎng)絡(luò)環(huán)境中，就不能使用“UDP打洞技術(shù)”。
（注：因?yàn)槲覈膰椋W(wǎng)絡(luò)技術(shù)應(yīng)用得比較晚，所以可以說絕大部分的網(wǎng)絡(luò)都是cone NAT，所以 UDP打洞技術(shù)基本上可以暢通無阻的使用，只是還要注意對NAT是否支持“loopback translation”的測試）
3.4. UDP port number prediction UPD端口號預(yù)言
讓我們來考慮這樣一種情況，有兩個客戶端 A 和 B，他們都藏在不同的NAT后面，他們都開放了一個UDP連接給具有固定IP的Server S：如下圖
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
Symmetric NAT A Symmetric NAT B
NAT A 分配了它自己的UDP端口62000，用來保持 客戶端A 與 服務(wù)器S 的通信會話， NAT B 也分配了31000端口，用來保持 客戶端B 與 服務(wù)器S 的通信會話。通過與 服務(wù)器S的對話，客戶端A 和 客戶端B 都相互知道了對方所映射的真實(shí)IP和端口。
客戶端A發(fā)送一條UDP消息到 138.76.29.7:31001(請注意到端口號的增加)，同時 客戶端B發(fā)送一條UDP消息到 155.99.25.11:62001。如果NAT A 和NAT B繼續(xù)分配端口給新的會話，并且從A-S和B-S的會話時間消耗得并不多的話，那么一條處于客戶端A和客戶端B之間的雙向會話通道就建立了。
客戶 端A發(fā)出的消息送達(dá)B導(dǎo)致了NAT A打開了一個新的會話，并且我們希望 NAT A將會指派62001端口給這個新的會話，因?yàn)?2001是繼62000后，NAT會自動指派給從服務(wù)器S到客戶端A之間的新會話的端口號；類似的，客戶端B發(fā)出的消息送達(dá)A導(dǎo)致了 NAT B打開了一個新的會話，并且我們希望 NAT B 將會指派31001這個端口給新的會話；如果兩個客戶端都正確的猜測到了對方新會話被指派的端口號，那么這個客戶端A－客戶端B的雙向連接就被打通了。其結(jié)果如下圖所示：
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
明顯的，有許多因素會導(dǎo)致這個方法失?。喝绻@個預(yù)言的新端口（62001和31001）恰好已經(jīng)被一個不相關(guān)的會話所使用，那么NAT就會跳過這個端口號，這個連接就會宣告失??；如果兩個NAT有時或者總是不按照順序來生成新的端口號，那么這個方法也是行不通的。
如 果隱藏在NAT A后的一個不同的客戶端X（或者在NAT B后）打開了一個新的“外出”UDP 連接，并且無論這個連接的目的如何；只要這個動作發(fā)生在 客戶端A 建立了與服務(wù)器S 的連接之后，客戶端A 與 客戶端B 建立連接之前；那么這個無關(guān)的客戶端X 就會趁人不備地“偷” 到這個我們渴望分配的端口。所以，這個方法變得如此脆弱而且不堪一擊，只要任何一個NAT方包含以上碰到的問題，這個方法都不會奏效。
