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

一. 套接字和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引數,該引數用於區分埠重用還是地址重用，在這樣的系統裡面，上述所有的引數必須都設定才行。

二. 開啟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通訊過程不再繼續等待是否有新的連線聯入。

與UDP不同的是，使用UDP協議的每個客戶端只需要一個套接字即可完成與伺服器S通訊，並同時與多個p2p客戶端通訊的任務，而TCP客戶端必須處理多個套接字繫結到同一個本地TCP埠的問題，如圖所示。

現在來看更加實際的一種情景，A與B分別位於不同的NAT裝置後面，並且假定埠號是TCP協議的埠號，而不是UDP的埠號。客戶端向彼此公網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連線。

三. 從應用程式的角度來看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系統都會按照第二種結果來處理。

下面就是非轉載部分了,我看後的感想:(如沒有特殊宣告,一律是在windows環境下)

這個所謂的"洞"就是SOCKET,套接字.

埠複用就是在一個SOCKET上既可以listen()也可以connect().

有一點需要說明,在我看來所謂的埠有兩種形式,一種是主動連線的,一種是被動連線的.也就是說當我去連線某伺服器的某埠的時候,我自身也會開啟一個埠,這樣才能進行通訊.我們一般知道的都是被動連線的埠,而主動連線的埠是由系統隨機分配的.不信的話你可以開啟一個網頁,然後開啟CMD視窗輸入"netstat -an",你會發現有一個或者幾個資訊,意思就是本地的XXX埠連線到遠端的80埠(Web服務),我說的也就是這個意思了.但,實際情況卻更復雜,本地開的埠在外部的訪問不到的,因為從本地埠傳送的資料要經過路由,而路由經過分析包後知道是建立連線,所以路由又開了一個埠用於接收外部的包,那麼自己的埠(內網埠)和路由開的埠(外網埠)會形成一個對映,是這個樣子.

"打洞",就是說:

兩個電腦A和B與伺服器S,A和B都與S建立連線,此時有兩個SOCKET,A和S算一個(叫做S_AS),B和S算一個(叫做S_BS),這兩個都設定了埠複用

A和B分別建立新的SOCKET(設定埠複用)並呼叫listen(),就是A建立新的SOCKET繫結到S_AS的埠上監聽(內網埠),B也一樣

A和B通過伺服器分別拿到對方的外網IP和埠號(伺服器獲取,主動連線的,路由開的埠)

告訴伺服器我們(A和B)都準備好了,這時伺服器發出指令,準備P2P.

此時A和B分別去連線對方,就是,A去連線S_BS的外網埠,B去連線S_AS的外網埠,至少有一方可以連線到另一方,連線建立.

(監聽自己的內網埠,連線對方的外網埠)

至於為什麼能連線上,請看上面文章中我標註紅色字型的描述.

做過網路程式設計的人都應該知道,TCP之所以可靠是因為在建立連線的時候要經過"三次握手"(當然還有其他因素),要事先打好招呼,由於A和B都是處在內網,彼此相隔兩個路由器(自己這邊一個,對方那邊一個),建立連線的時候自己傳送的SYN包能通過自己的路由,卻不能通過對方的路由,所以包被丟棄,而此時對方也傳送一個SYN包過來,因為自己已經發送了SYN包,所以自己這邊的路由會認為對方發來的SYN包是迴應我的SYN包,所以不會丟棄包,繼續傳遞給自己,而自己也會把對方發來的包當做迴應自己的包,所以做處理(當然不是正常的三次握手,SYN和SYN),還會發送ACK給對方,然後對方給我RST包,再然後,連線建立......

想來想去怎麼都是覺得是在忽悠路由器,忽悠忽悠就建立連線了.

最後的結果只有一種:

A連線上了S_BS的埠,或者,B連線上了S_AS的埠,總之A和B通了.

據資料所知貌似沒有都連線上的情況.

查閱資料就學到這些,也不知道對不對,有空敲程式碼試試看~~~