P2P communication across middleboxes（翻譯1）

從今天開始將陸續翻譯Peer-to-Peer (P2P) communication across middleboxes這篇文章,并沒有按照章節次序來，請讀者見諒。

原文版權：Copyright (C) The Internet Society (2003).  All Rights Reserved.

原文地址：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt



3.4. UDP port number prediction UPD端口號預言

A variant of the UDP hole punching technique discussed above exists that allows P2P UDP sessions to be created in the presence of some symmetric NATs.  This method is sometimes called the "N+1" technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. The method works by analyzing the behavior of the NAT and attempting to predict the public port numbers it will assign to future sessions.   

Consider again the situation in which two clients, A and B, each behind a separate NAT, have each established UDP connections with a permanently addressable server S:

   讓我們來考慮這樣一種情況，有兩個客戶端 A 和 B，他們都藏在不同的NAT后面，他們都開放了一個UDP連接給具有固定IP的Server S：如下圖


  NAT A has assigned its own UDP port 62000 to the communication session between A and S, and NAT B has assigned its port 31000 to the session between B and S.  By communicating through server S, A and B learn each other's public IP addresses and port numbers as observed   by S.  Client A now starts sending UDP messages to port 31001 at address 138.76.29.7 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 155.99.25.11.  If NATs A and B assign port numbers to new sessions  sequentially, and if not much time has passed since the A-S and B-S sessions were initiated, then a working bi-directional communication channel between A and B should result.



   A's messages to B cause NAT A  to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the  port number 62000 it previously assigned to the session between A and S.  Similarly, B's messages to A will cause NAT B to open a new   session, to which it will (hopefully) assign port number 31001.  If
both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bi-directional UDP communication channel will have been established as shown below.




   NAT A 分配了它自己的UDP端口62000，用來保持 客戶端A 與 服務器S 的通信會話， NAT B 也分配了31000端口，用來保持 客戶端B 與 服務器S 的通信會話。通過與 服務器S的對話，客戶端A 和 客戶端B 都相互知道了對方所映射的真實IP和端口。

   客戶端A發送一條UDP消息到 138.76.29.7:31001(請注意到端口號的增加)，同時 客戶端B發送一條UDP消息到 155.99.25.11:62001。如果NAT A 和NAT B繼續分配端口給新的會話，并且從A-S和B-S的會話時間消耗得并不多的話，那么一條處于客戶端A和客戶端B之間的雙向會話通道就建立了。

   客戶端A發出的消息送達B導致了NAT A打開了一個新的會話，并且我們希望 NAT A將會指派62001端口給這個新的會話，因為62001是繼62000后，NAT會自動指派給 從服務器S到客戶端A之間的新會話的端口號；類似的，客戶端B發出的消息送達A導致了 NAT B打開了一個新的會話，并且我們希望 NAT B 將會指派31001這個端口給新的會話；如果兩個客戶端都正確的猜測到了對方新會話被指派的端口號，那么這個 客戶端A－客戶端B的雙向連接就被打通了。其結果如下圖所示：


Obviously there are many things that can cause this trick to fail. If the predicted port number at either NAT already happens to be in use by an unrelated session, then the NAT will skip over that port number and the connection attempt will fail.  If either NAT sometimes or always chooses port numbers non-sequentially, then the trick will fail.  
   
   If a different client behind NAT A (or B respectively) opens up a new outgoing UDP connection to any external destination after A (B) establishes its connection with S but before sending its first message to B (A), then the unrelated client will inadvertently "steal" the desired port number.  This trick is therefore much less likely to work when either NAT involved is under load.

  

明顯的，有許多因素會導致這個方法失敗：如果這個預言的新端口（62001和31001） 恰好已經被一個不相關的會話所使用，那么NAT就會跳過這個端口號，這個連接就會宣告失敗；如果兩個NAT有時或者總是不按照順序來生成新的端口號，那么這個方法也是行不通的。

   

如果隱藏在NAT A后的一個不同的客戶端X（或者在NAT B后）打開了一個新的“外出”UDP 連接，并且無論這個連接的目的如何；只要這個動作發生在 客戶端A 建立了與服務器S 的連接之后，客戶端A 與 客戶端B 建立連接之前；那么這個無關的客戶端X 就會趁人不備地“偷” 到這個我們渴望分配的端口。所以，這個方法變得如此脆弱而且不堪一擊，只要任何一個NAT方包含以上碰到的問題，這個方法都不會奏效。

      
   Since in practice a P2P application implementing this trick would still need to work if the NATs are cone NATs, or if one is a cone NAT and the other is a symmetric NAT, the application would need to detect beforehand what kind of NAT is involved on either end [STUN] and modify its behavior accordingly, increasing the complexity of the algorithm and the general brittleness of the network.  



   Finally, port number prediction has no chance of working if either client is behind two or more levels of NAT and the NAT(s) closest to the client are symmetric.  For all of these reasons, it is NOT recommended that new applications implement this trick; it is mentioned here for historical and informational purposes.



   自從使用這種方法來實踐P2P的應用程序以來,在處于 cone NAT 系列的網絡環境中這個方法還是實用的；如果有一方為 cone NAT 而另外一方為 symmetric NAT，那么應用程序就應該預先發現另外一方的 NAT 是什么類型，再做出正確的行為來處理通信，這樣就增大了算法的復雜度，并且降低了在真實網絡環境中的普適性。

    最后，如果P2P的一方處在兩級或者兩級以上的NAT下面，并且這些NATs 接近這個客戶端是 symmetric的話，端口號預言 是無效的！

    因此，并不推薦使用這個方法來寫新的P2P應用程序，這也是歷史的經驗和教訓！