建立穿越nat裝置的p2p的tcp連線只比udp複雜一點點，tcp協議的「打洞」從協議層來看是與udp 的「打洞」過程非常相似的。儘管如此，基於tcp協議的打洞至今為止還沒有被很好的理解，這也 造成了對其提供支援的nat裝置不是很多。在nat裝置支援的前提下，基於tcp的「打洞」技術實際上 與基於udp的「打洞」技術一樣快捷、可靠。實際上，只要nat裝置支援的話，基於tcp的p2p技術 的健壯性將比基於udp的技術的更強一些，因為tcp協議的狀態機給出了一種標準的方法來精確的 獲取某個tcp session的生命期，而udp協議則無法做到這一點。
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引數,該引數用於區分 埠重用還是位址重用，在這樣的系統裡面，上述所有的引數必須都設定才行。
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通訊過程不再繼續 等待是否有新的連線聯入。
與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連線。
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系統都會按照第二種結果來處理。
TCP打洞技術
轉 建立穿越nat裝置的p2p的tcp連線只比udp複雜一點點，tcp協議的 打洞 從協議層來看是與udp 的 打洞 過程非常相似的。儘管如此，基於tcp協議的打洞至今為止還沒有被很好的理解，這也 造成了對其提供支援的nat裝置不是很多。在nat裝置支援的前提下，基於tcp的 打洞 技術實際上 與基...
TCP打洞技術
建立穿越nat裝置的p2p的tcp連線只比udp複雜一點點，tcp協議的 打洞 從協議層來看是與udp 的 打洞 過程非常相似的。儘管如此，基於tcp協議的打洞至今為止還沒有被很好的理解，這也 造成了對其提供支援的nat裝置不是很多。在nat裝置支援的前提下，基於tcp的 打洞 技術實際上 與基於u...
TCP打洞技術
轉 建立穿越nat裝置的p2p的tcp連線僅僅比udp複雜一點點，tcp協議的 打洞 從協議層來看是與udp 的 打洞 過程非常相似的。雖然如此，基於tcp協議的打洞至今為止還沒有被非常好的理解，這也 造成了對其提供支援的nat裝置不是非常多。在nat裝置支援的前提下，基於tcp的 打洞 技術實際上...