Original copyright: Copyright (c) The Internet Society (2003).? All rights address: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt translation copyright statement: please Quote the author or website of this article indicate: http://blog.9cbs.net/hxhblueestar to respect the translator's labor results!
3.3. UDP HOLE PUNCHING UDP Cole Technology
The third technique, and the one of primary interest in this document, is widely known as "UDP Hole Punching." UDP hole punching relies on the properties of common firewalls and cone NATs to allow appropriately designed peer-to-peer applications to "punch holes "through the middlebox and establish direct connectivity with each other, even when both communicating hosts may lie behind middleboxes. This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet [ Kegel] and used in some recent protocolls [teredo, ICE]. As the name Implies, unfortunately, this Technique Works Reliably Only with udp.
The third technology is also the main study, which is a very famous "UDP Covered Technology". UDP hole technology depends on the public firewall and CONE NAT, allowing appropriate planned end-to-end applications. NAT "Cave", even when both the hosts are in NAT. This technique has focused on the RFC3027 5.1 [Nat Prot], and informal descriptions were carried out in Internet [Kegel], and there were also some protocols, such as the [TEREDO, ICE] protocol. However, we have to pay attention to the "technique", the reliability of UDP hole technology is dependent on UDP.
We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to- peer communication reside behind two different NATs. In the second, The Two Clients Actually Reside Behind The Same Nat, But Do Not Necessarily Know That They Do.
Here, two typical scenes will be considering how the two parties of the connection communicate in accordance with the planned, the first scene, we assume that two clients are in different NATs; the second scene, we assume two After the client is in the same NAT, they don't know each other (they are in the same NAT). 3.3.1. Peers BEHIND DIFFERENT NATS is in different NAT client communication
Suppose clients A and B both have private IP addresses and lie behind different network address translators. The peer-to-peer application running on clients A and B and on server S each use UDP port 1234.? A and B have each initiated UDP communication Sessions with Server S, Causeing Nat A to Assign ITS OWN PUBLIC UDP Port 62000 for a's session with s, and causing NAT B To Assign ITS Port 31000 To B 'Sense With s, respective.
We assume that both Client A and Client B have its own private IP address, and all after different NATs, the end-to-end program is run between Client A, Client B, S, and they all open UDP port 1234. Client A and Client B first establish a communication session with S, at this time, Nat A assigns its own UDP port 62000 to Client A and S session, NAT B also assigns its own UDP port 31000 to Client B and S session . As shown below:
Now suppose that client A wants to establish a UDP communication session directly with client B.? If A simply starts sending UDP messages to B's public address, 138.76.29.7:31000, then NAT B will typically discard these incoming messages (unless it is a full cone NAT), because the source address and port number does not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A's public address, then NAT A will typically discard these messages .
If this time client A wants to establish a UDP communication directly, if Client A is just a simple sending a UDP message to Client B, Nat B will not consider this information. Discard (unless NAT B is a FULL CONE NAT), because the address information included in this UDP information is not in accordance with the address information of the server S in NAT B, which is connected to the Client B and Server S. Similarly, if CLIENT B is doing the same thing, the transmitted UDP information will also be discarded by NAT A.
Suppose A starts sending UDP messages to B's public address, however, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A's public address A's outgoing messages directed to B's public address (138.76.29.7.?: 31000) cause NAT A to open up a new communication session between A's private address and B's public address. At the same time, B's messages to A's public address (155.99.25.11:62000) cause NAT B to open up a new communication session between B's private address and a's public address. Once the new UDP sessions have been opened up in each direction, client a and B can communicate with each other directly without further burden on the "introduction" server S. If CLIENT a starts sending UDP messages On the public address of Client B, at the same time, he sent an invitation information to Client B through the S transferring, requested whether Client B sent a UDP information to Client a on the public address. At this time, the information sent to Client B's public IP (138.76.7: 7:31000) causes Nat a to open a new communication session between the private address of Client a and the public address of Client B, while at the same time NAT B also opened a new communication session between the private address of Client B and the public address of Client A (155.99.25.11:62000). Once this new UDP session is opened to the other party, the Client A and Client B can communicate directly without the need for S to take a bridge. (This is the so-called hole technology)!
The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of "introducer" and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect explicitly what kind of middlebox it is behind, if any [STUN], since the procedure above will establish peer- to-peer communication channels equally well if either or both clients do not happen to be behind a middlebox.? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public Internet via two or More Levels of Address Translation.udp Cole Technology has a lot of practical places: First, once this is in the NAT, the connected part of the connection can take the other party "media" and introduce each other. Other clients, which greatly reduces the workload of the server S; second, the application does not care about this NAT is conference or symmetric, even if the connection, the two sides of the connection, or both parties are not in NAT. ,based on The steps in the upper surface, they can also build a good communication channel; third, the hole technology can be automatically operated after multiple NAT, whether the connection of the two sides can only reach the Internet, can communicate.
Post-translation: Originally translated, it is translated in the web. Turn over. However, there is a lot to have, the second translation is too smooth, I hope everyone will read it.
