TCP打洞

在處於NAT之後的兩臺主機之間建立p2p TCP連線比建立相應的UDP要稍微複雜，但在協議層次，TCP打洞非常類似與UDP打洞。然而TCP協議本身比較複雜，因此支援的NAT比較少。然而，在NAT支援TCP打洞的情況下，TCP打洞像UPD打洞那樣快並且可靠。穿透“行為良好”的NAT的TCP p2p連線事實上比UDP連線更健壯，因為，TCP協議的狀態機給路徑上的NAT提供了一種決定特定TCP連線確切生存週期的標準方式，而維持UDP連線的時間是不確定的。

套接字和TCP埠重用

對於想實現TCP打洞的應用程式來說，實際面臨主要的挑戰不是協議問題，而是API的問題。因為標準的Berkeley sockets API是圍繞C/S程式設計而設計的。這個API通過connect()允許一個TCP流套接字初始化一個向外的連線，通過listen()和 accept()監聽一個外入的連線，一個套接字不能既用來監聽又用來初始化向外的連線。更進一步講， TCP套接字通常與本地主機上的TCP埠一一對應：一個套接字繫結到本地主機機上的某個埠後，另一個套接字就不能再繫結到該埠。

然而TCP打洞要成功，需要一個本地的TCP埠既可以監聽外入的連線，同時又可以發起多個向外的連線。幸運的是，所有主流的作業系統都支援一個特殊的socket選項，通常叫做SO_REUSEADDR，它執行應用程式繫結多個設定了該選項的套接字到同一埠。BSD系統引入了SO_REUSEPORT選項來控制埠重用，從而把埠重用和地址重用相分離。在這樣的系統中，兩個選項都需要被設定。

開啟對等TCP流

假定Client A想要同Client B建立一個TCP連線。我們假設Client A和 Client B都與一個雙方都知道的集結伺服器S保持著一個活動的TCP連線。這個伺服器記錄了每一個註冊客戶端的公有和私有地址，這類似於UDP打洞的情況。在協議層，TCP打洞幾乎和UDP一樣：

1.  Client A利用與S的連線請求S幫助它連線到B
2. S把B的公有和私有地址告訴A，同時把A的公有和私有地址告訴B。
3. A和B都通過相同的本地TCP埠向S返回給它們的地址（公有和私有地址都發）發起一個向外的連線嘗試，同時在它們各自的本地埠上監聽外入的連線。
4. A和B等待向外的連線嘗試成功，或者一個外入的連接出現。如果由於”connection reset”或”host unreachable”這樣的網路錯誤引起一個向外的連線嘗試失敗，主機就簡單的延遲一段時間（比如1秒）之後再嘗試連線，直到出現一個應用程式定義的最大超時。
5. 當一個TCP連線建立之後，主機通過驗證彼此以確定它們連線到了目的主機。如果驗證失敗，客戶端就關閉連線等待另一個連線。一旦找到一個驗證成功的TCP流連線，這一過程就終止。

不像UDP，這裡每個客戶端只需要維持一個與S的連線，而不管同時有多少個對端。TCP方案中，每一個客戶端應用程式必須管理多個繫結到同一個本地埠的sockets。如下圖所示。

每個客戶端需要一個流套接字來與S連線，一個套接字來監聽來自對端的外入連線，至少兩個另外的流套接字用來發起到對端公有地址和私有地址的向外的TCP連線。如下圖所示，考慮到通常的情況都是，A和B位於不同的NAT之後，A和B發起的到對端私有地址的連線嘗

試可能失敗或連線到錯誤的主機。類似於UDP的情況，TCP應用程式驗證它們的端到端會話也是很重要的，因為可能發生這樣的情況：連線到一個本地網路中與想要連線的遠端主機具有同一個私有地址的主機上。

這些客戶端發起的到對端公網地址的連線嘗試，促使它們各自的NAT開啟一個新的“洞”，這個“洞”允許A和B可以直接進行TCP通訊。如果它們之間的NAT是“行為良好”，就會自動在它們直接形成一條p2p TCP流。如果A發到B的第一個SYN包在B發到A的第一個SYN包到底B的NAT之前到達該NAT，那麼B的NAT會把A的SYN包當做未授權的外入連線嘗試而把該SYN包丟棄。隨後B的第一個SYN包應該能順利通過，因為A的NAT把它當做A的第一個SYN包已經發起的向外連線的一部分。

應用程式觀察到的行為

客戶端應用程式在它們的sockets上觀察到的行為依賴於時機和TCP實現。假定A外發到B的公共端的第一個SYN包被B的NAT丟棄，但是隨後的B傳送到A的公共端的第一個SYN包在A重新發送SYN包之前穿過網路到達了A，依賴於涉及到的作業系統，將發生下述行為之一：

•  A的TCP實現通知會話終端，這個外入的SYN匹配A起先發起的向外會話。因此A的協議棧就把這個新會話與該socket聯絡在一起，A的本地應用程式使用connect()連線B的公共端。應用程式的非同步呼叫connect()成功，監聽socket什麼也沒有發生。
  
  然而收到的SYN包沒有包含先前A外發的SYN包的ACK，A的TCP迴應B的公共端一個SYN-ACK包，其中SYN部分只是初始外發SYN的重複，即使用同樣的SYN序列號。一旦B的TCP收到A的SYN-ACK，它用它自己的ACK迴應A的SYN，之後兩端之間的TCP會話就建立起來了。
  
• 作為另一種選擇，與上一種情況不同，A的TCP實現可能通知應用程式，在那個埠上有一個活動監聽套接字正在等待連線嘗試。因為B的SYN包看起來像一個外入的連線嘗試，所以A的TCP建立一個新的流套接字並把它和這個新的TCP會話結合在一起，並通過應用程式的在它的監聽埠的下一次accept呼叫返回給應用程式。A的TCP隨後迴應B一個上述的SYN-ACK，隨後的TCP連線建立處理就和通常的C/S一樣。 
  
  因為先前A到B的向外connect()嘗試所使用的源和目的地址結合正在被另一個socket使用，即剛剛通過accept()返回給應用程式的socket，所以A非同步呼叫的connect()在某個時間肯定會失敗，通常是返回一個“address in use”錯誤。然而已經有一個可以工作的p2p 流socket用於與B通訊，所以可以簡單的忽略該失敗。

上述的第一行為通常出現在BSD系統中，第二種行為通常出現在Linux和Windows系統中。

TCP同時開放

假定我們解決了打洞過程中的各種各樣連線嘗試的時機問題，以便來自兩個客戶端的外發SYN包穿過了它們各自的本地NAT，在到達遠端對端的NAT之前在每個NAT上打開了向外的TCP會話。在這種“幸運”的情況下，NAT沒有阻擋這兩個初始SYN包，這兩個SYN包在兩個客戶端各自的NAT之間的線路上交叉通過。在這種情況下，客戶端觀察到了被稱為同步TCP開放的事件：每一個對端在等待SYN-ACK的時候收到了一個“raw”SYN。每一個對端的TCP迴應對方一個SYN-ACK，其中的SYN部分是初始外發SYN的重複，ACK是對各自收到的SYN的確認。

在這種情況下，各自的應用程式觀察到的行為也依賴於TCP的實現，如上一部分所述。如果兩個客戶端都實現了上述的第二種行為，可能是這樣：所有由應用程式非同步呼叫的connect()最終都失敗了，但是執行在每個客戶端的應用程式通過accept()收到了一個新的、可以工作得p2p TCP 流套接字 – 好像TCP流魔術般的線上路上建立了它自身，而終端只是被動的接受這個流。應用程式不關心最終的流是通過connect()還是accept()收到的，這個過程在任何正確實現了標準TCP狀態機的TCP實現上產生了一個可以工作的流。