TCP穿洞，p2p技術的一些原理

標籤：blog   http   io   使用   sp   on   資料   問題   log   

上回提到udp的穿洞，這回提一下tcp的穿洞，資料來源於網路，供大家學習參考。

 

建立穿越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系統都會按照第二種結果來處理。

 

 

對於tcp打洞這回事，我感覺就是有點像忽悠，忽悠來忽悠去，忽悠著忽悠著就忽悠上了，呵呵，人生何嘗不是？

TCP穿洞，p2p技術的一些原理