內容概述：在p2p通信領域中，由NAT(Network Address Translation,，網絡地址轉換)引起的問題已經眾所周知了,它會導致在NAT內部的p2p客戶端在無論以何種有效的公網ip都無法訪問的問題,。雖 然目前已經發(fā)展出多種穿越NAT的技術,但相關的技術文檔卻很少，用來證明這些技術的穩(wěn)定性和優(yōu)點的實際數(shù)據更少,。本文的目的在于描述和分析在實際中運用 得最廣泛,、最可靠同時也是最簡單的一種NAT穿越技術，該技術通常被稱為“打洞”技術,。目前,，“打洞”技術已經在UDP通信領域中得到了廣泛的理解和應 用,，在此，也將討論如何利用它實現(xiàn)可靠的p2p的TCP流通信,。在收集了大量的“打洞”技術可以穿越的NAT設備和網絡的數(shù)據以后,，我們發(fā)現(xiàn)82%的已測 NAT設備支持UDP形式的“打洞”穿越，64%的已測NAT設備支持TCP流形式的“打洞”穿越,。由于重量級p2p應用程序(如,，VOIP、BT,、在線 游戲等)的用戶需求量持續(xù)上升,，并且該事實也已經引起了NAT設備生產廠商的廣泛關注，因此,，我們認為未來會有越來越多的NAT設備提供對“打洞”穿越技 術的支持,。

1、介紹

用戶量高速增長以及大量安全問題的巨大壓力迫使Internet技術不斷向前發(fā)展,，但是這些新興的技術很大程度地增加了應用程序開發(fā)的成本和復雜 性,。Internet最初的地址體系是每個節(jié)點有一個唯一不變的全局地址，可以通過該地址直接與任何其它的節(jié)點進行通信,，而現(xiàn)如今,，該地址體系已經被新的 實際上廣泛使用的地址體系所替換，新的地址體系是由全局地址域和通過NAT接入全局地址域的大量私有地址域組成,。在新的地址體系中（如圖1所示）,，只有在 “main”全局地址域中的節(jié)點可以在網絡中很容易地與任何其它的擁有全局地址的節(jié)點通信，因為該節(jié)點擁有全局的,、唯一的,、可路由的地址。在私有網絡中的 節(jié)點可以與在同一個私有網絡中的其它節(jié)點進行通信,，并且在通常情況下可以向全局地址中的某個“著名”的節(jié)點發(fā)起TCP連接或發(fā)送UDP數(shù)據包,。NAT設備 在此扮演的角色就是為從內網向公網發(fā)起的連接的節(jié)點分配臨時的轉發(fā)session，將來自內網的數(shù)據包的地址和端口轉換為公網的地址和端口,，將來自公網的 數(shù)據包的地址和端口轉換為內網的端口和地址,，同時NAT將屏蔽所有未經授權的來自公網的數(shù)據包。

一些p2p的應用程序采用了直接但是有所限制的技術來實現(xiàn)NAT穿越,，該技術叫做“反向連接”，這是用于當兩個節(jié)點聯(lián)入服務器S的時候,，只有一 個一個節(jié)點在NAT設備的后面（如圖3所示）,。如果A希望建立與B的連接，那么A可以直接聯(lián)入B，因為B是在公網中存在的,，沒有經過NAT轉換,，而且A的 NAT設備也允許A直接由內網發(fā)起向外網的連接。如果B希望建立與A的連接,，很不幸,，A的NAT設備會阻止該操作，此時,，B可以借助于轉發(fā)服務器S,，向A 發(fā)送“反向連接”請求，由A“主動”連接B,，從而達到A與B的p2p通信的目的,。

4 關于TCP打洞技術建立穿越NAT設備的p2p的TCP連接只比UDP復雜一點點,，TCP協(xié)議的“打洞”從協(xié)議層來看是與UDP的“打洞”過程非常相似 的,。盡管如此，基于TCP協(xié)議的打洞至今為止還沒有被很好的理解,，這也造成了對其提供支持的NAT設備不是很多,。在NAT設備支持的前提下，基于TCP的 “打洞”技術實際上與基于UDP的“打洞”技術一樣快捷,、可靠,。實際上，只要NAT設備支持的話,，基于TCP的p2p技術的健壯性將比基于UDP的技術的 更強一些,，因為TCP協(xié)議的狀態(tài)機給出了一種標準的方法來精確的獲取某個TCP session的生命期，而UDP協(xié)議則無法做到這一點,。

4.1 套接字和TCP端口的重用實現(xiàn)基于TCP協(xié)議的p2p“打洞”過程中,，最主要的問題不是來自于TCP協(xié)議，而是來自于來自于應用程序的API接口,。這是由 于標準的伯克利(Berkeley)套接字的API是圍繞著構建客戶端/服務器程序而設計的,，API允許TCP流套接字通過調用connect()函數(shù)來 建立向外的連接，或者通過listen()和accept函數(shù)接受來自外部的連接,，但是,，API不提供類似UDP那樣的，同一個端口既可以向外連接,，又能 夠接受來自外部的連接,。而且更糟的是，TCP的套接字通常僅允許建立1對1的響應,，即應用程序在將一個套接字綁定到本地的一個端口以后,，任何試圖將第二個 套接字綁定到該端口的操作都會失敗。為了讓TCP“打洞”能夠順利工作,，我們需要使用一個本地的TCP端口來監(jiān)聽來自外部的TCP連接,，同時建立多個向外 的TCP連接。幸運的是,，所有的主流操作系統(tǒng)都能夠支持特殊的TCP套接字參數(shù),，通常叫做“SO_REUSEADDR”，該參數(shù)允許應用程序將多個套接字 綁定到本地的一個endpoint（只要所有要綁定的套接字都設置了SO_REUSEADDR參數(shù)即可）,。BSD系統(tǒng)引入了SO_REUSEPORT參 數(shù),該參數(shù)用于區(qū)分端口重用還是地址重用,，在這樣的系統(tǒng)里面，上述所有的參數(shù)必須都設置才行,。

4.2 打開p2p的TCP流假定客戶端A希望建立與B的TCP連接,。我們像通常一樣假定A和B已經與公網上的已知服務器S建立了TCP連接。服務器記錄下來每個 聯(lián)入的客戶端的公網和內網的endpoints,，如同為UDP服務的時候一樣,。從協(xié)議層來看，TCP“打洞”與UDP“打洞”是幾乎完全相同的過程,。1,、 客戶端A使用其與服務器S的連接向服務器發(fā)送請求，要求服務器S協(xié)助其連接客戶端B,。2,、S將B的公網和內網的TCP endpoint返回給A，同時,，S將A的公網和內網的endpoint發(fā)送給B,。3、客戶端A和B使用連接S的端口異步地發(fā)起向對方的公網,、內網 endpoint的TCP連接,，同時監(jiān)聽各自的本地TCP端口是否有外部的連接聯(lián)入,。4、A和B開始等待向外的連接是否成功,，檢查是否有新連接聯(lián)入,。如果 向外的連接由于某種網絡錯誤而失敗，如：“連接被重置”或者“節(jié)點無法訪問”,，客戶端只需要延遲一小段時間（例如延遲一秒鐘）,，然后重新發(fā)起連接即可，延 遲的時間和重復連接的次數(shù)可以由應用程序編寫者來確定,。5,、TCP連接建立起來以后，客戶端之間應該開始鑒權操作,，確保目前聯(lián)入的連接就是所希望的連接,。 如果鑒權失敗，客戶端將關閉連接,，并且繼續(xù)等待新的連接聯(lián)入,。客戶端通常采用“先入為主”的策略,，只接受第一個通過鑒權操作的客戶端，然后將進入p2p通 信過程不再繼續(xù)等待是否有新的連接聯(lián)入,。

（圖 7）

與UDP 不同的是,，使用UDP協(xié)議的每個客戶端只需要一個套接字即可完成與服務器S通信，并同時與多個p2p客戶端通信的任務,，而TCP客戶端必須處理多個套接字 綁定到同一個本地TCP端口的問題,，如圖7所示。現(xiàn)在來看更加實際的一種情景,，A與B分別位于不同的NAT設備后面,，如圖5所示，并且假定圖中的端口號是 TCP協(xié)議的端口號,，而不是UDP的端口號,。圖中向外的連接代表A和B向對方的內網endpoint發(fā)起的連接，這些連接或許會失敗或者無法連接到對方,。 如同使用UDP協(xié)議進行“打洞”操作遇到的問題一樣,，TCP的“打洞”操作也會遇到內網的IP與“偽”公網IP重復造成連接失敗或者錯誤連接之類的問題。 客戶端向彼此公網endpoint發(fā)起連接的操作,，會使得各自的NAT設備打開新的“洞”允許A與B的TCP數(shù)據通過,。如果NAT設備支持TCP“打洞” 操作的話，一個在客戶端之間的基于TCP協(xié)議的流通道就會自動建立起來,。如果A向B發(fā)送的第一個SYN包發(fā)到了B的NAT設備,，而B在此前沒有向A發(fā)送 SYN包,，B的NAT設備會丟棄這個包，這會引起A的“連接失敗”或“無法連接”問題,。而此時,，由于A已經向B發(fā)送過SYN包，B發(fā)往A的SYN包將被看 作是由A發(fā)往B的包的回應的一部分,，所以B發(fā)往A的SYN包會順利地通過A的NAT設備,，到達A，從而建立起A與B的p2p連接,。

4.3 從應用程序的角度來看TCP“打洞”從應用程序的角度來看,，在進行TCP“打洞”的時候都發(fā)生了什么呢？假定A首先向B發(fā)出SYN包,，該包發(fā)往B的公網 endpoint,，并且被B的NAT設備丟棄，但是B發(fā)往A的公網endpoint的SYN包則通過A的NAT到達了A,，然后,，會發(fā)生以下的兩種結果中的 一種，具體是哪一種取決于操作系統(tǒng)對TCP協(xié)議的實現(xiàn)：（1）A的TCP實現(xiàn)會發(fā)現(xiàn)收到的SYN包就是其發(fā)起連接并希望聯(lián)入的B的SYN包,，通俗一點來說 就是“說曹操,，曹操到”的意思，本來A要去找B,，結果B自己找上門來了,。A的TCP協(xié)議棧因此會把B做為A向B發(fā)起連接connect的一部分，并認為連 接已經成功,。程序A調用的異步connect()函數(shù)將成功返回,，A的listen()等待從外部聯(lián)入的函數(shù)將沒有任何反映。此時,，B聯(lián)入A的操作在A程 序的內部被理解為A聯(lián)入B連接成功,，并且A開始使用這個連接與B開始p2p通信。由于收到的SYN包中不包含A需要的ACK數(shù)據,，因此,，A的TCP將用 SYN-ACK包回應B的公網endpoint，并且將使用先前A發(fā)向B的SYN包一樣的序列號,。一旦B的TCP收到由A發(fā)來的SYN-ACK包,，則把自 己的ACK包發(fā)給A，然后兩端建立起TCP連接,。簡單的說,，第一種，就是即使A發(fā)往B的SYN包被B的NAT丟棄了,，但是由于B發(fā)往A的包到達了A,。結果 是,，A認為自己連接成功了，B也認為自己連接成功了,，不管是誰成功了,，總之連接是已經建立起來了。（2）另外一種結果是,，A的TCP實現(xiàn)沒有像（1）中所 講的那么“智能”,，它沒有發(fā)現(xiàn)現(xiàn)在聯(lián)入的B就是自己希望聯(lián)入的。就好比在機場接人,，明明遇到了自己想要接的人卻不認識,，誤認為是其它的人，安排別人給接走 了,，后來才知道是自己錯過了機會,，但是無論如何，人已經接到了任務已經完成了,。然后,，A通過常規(guī)的listen()函數(shù)和accept()函數(shù)得到與B的 連接，而由A發(fā)起的向B的公網endpoint的連接會以失敗告終,。盡管A向B的連接失敗,，A仍然得到了B發(fā)起的向A的連接，等效于A與B之間已經聯(lián)通,， 不管中間過程如何,，A與B已經連接起來了，結果是A和B的基于TCP協(xié)議的p2p連接已經建立起來了,。第一種結果適用于基于BSD的操作系統(tǒng)對于TCP的 實現(xiàn)，而第二種結果更加普遍一些,，多數(shù)linux和windows系統(tǒng)都會按照第二種結果來處理,。