TCP打洞技術

建立穿越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打洞技術

TCP打洞技術

TCP打洞技術

TCP打洞技術

相關推薦