UDP cross-NAT principle (PEER)

Reprinted from: http://blog.csdn.net/ldd909/article/details/5979967

Forums often have a discussion of the principle of the peer, but the discussion is discussed, and few things are actually produced (source code). Here I use my own implementation of a source code to illustrate the principle of UDP traversal nat.

First introduce some basic concepts:

NAT Network Address translators: Network address translation is the result of a growing lack of IP addresses, and its primary purpose is to enable address reuse. Nat is divided into two major classes, the basic NAT and Napt (Network address/port Translator).

The first NAT is a functional module that runs on the router.

The first proposed is the basic NAT, which is based on the fact that only a small number of nodes in a private network (domain) need to be connected to an external network (hehe, which was proposed in the middle of the 90 century). Then there are only a few nodes in this subnet that require the world's only IP address, and the IP addresses of the other nodes should be reusable.

Therefore, the basic NAT implementation of the function is very simple, in the subnet using a reserved IP subnet segment, these IP is not visible to the outside. Only a few IP addresses in the subnet can correspond to truly global unique IP addresses. If these nodes require access to an external network, then basic NAT is responsible for translating the subnet IP of the node into a globally unique IP and sending it out. (Basic NAT changes the original IP address in the IP packet, but does not change the port in the IP packet)

Refer to RFC 1631 for basic NAT

Another kind of NAT is called NAPT, and from the name we can see that napt not only changes the IP address of the IP datagram that passes through the NAT device, but also changes the TCP/UDP port of the IP datagram. Basic NAT Device Maybe we don't see much (hehe, I haven't seen it), Napt is the protagonist of our real discussion. See:

There is a private network 10.*.*.*,client A is one of the computers, the network gateway (a NAT device) of the external network IP is 155.99.25.11 (there should be an intranet IP address, such as 10.0.0.10). If a process in client a (this process creates a UDP socket, this socket bound 1234 port) wants to access the 1235 port of the extranet host 18.181.0.31, what happens when the packet passes through NAT?

First NAT will change the original IP address of this packet, instead 155.99.25.11. Nat then creates a session for the transfer (the session is an abstract concept, and if it is TCP, perhaps the session is started by a SYN packet and ended with a fin packet.) And UDP, with this IP port of the first UDP start, the end, hehe, maybe a few minutes, maybe a few hours, this depends on the specific implementation of the session and assign a port, such as 62000, and then change the packet source port is 62000. So it was (10.0.0.1:1234-〉18.181.0.31:1235) that the packet was turned into the internet (155.99.25.11:62000-〉18.181.0.31:1235).

Once Nat has created a session, Nat remembers that port 62000 corresponds to port 1234 of 10.0.0.1, and data sent from 18.181.0.31 to Port 62000 will be automatically forwarded to 10.0.0.1 by Nat. (Note: This is to say that the data sent to port 62000 will be forwarded, the data sent to this port by other IP will be 18.181.0.31 by NAT) so that client A is established with server S1 as a connection.

The basic knowledge above may be known to many people, then the following is the key part. Take a look at the following scenario:

In the example above, if the original Socket of client A (the UDP socket that is bound to port 1234) then sends a UDP packet to another server S2, what happens when the UDP packet passes through NAT?

There may be two situations where NAT creates a session again and assigns a port number to the session again (for example: 62001). The other is that NAT creates a session again, but does not assign a new port number, but instead uses the originally assigned port number 62000. The former NAT is called symmetric Nat, and the latter is called Cone Nat. We expect that our NAT is the second, hehe, if your NAT happens to be the first one, then there is likely to be a lot of peer software failure. (Fortunately, most Nat now belongs to the latter, that is, cone NAT)

Well, we've seen that through NAT, it's easy to connect a computer to a subnet (NAT is equivalent to transparent, and the subnets and extranet computers don't have to know the NAT).

But it is difficult for an external computer to access a computer in the subnet (which is what peer-to-peer needs).

So what can we do if we want to send a datagram from outside to the intranet computer? First of all, we have to play a "hole" in the NAT on the intranet (that is, we said in a NAT on a session), this hole can not be played by the outside, can only be played by the host inside the intranet. And this hole is a direction, such as from the inside of a host (such as: 192.168.0.10) to an external IP (such as: 219.237.60.1) to send a UDP packet, then in this intranet NAT device to play a direction for the 219.237.60.1 "hole", (This is called the UDP Hole punching technology) after 219.237.60.1 can through this hole and the intranet 192.168.0.10 contact. (But other IPs cannot take advantage of this hole).

Oh, now it's our turn to peer. With the above theory, the implementation of the two intranet host communication is the last step: that is the chicken eggs or eggs, the problem of chicken, both sides can not initiate the connection request, who do not know who's public address, then how can we hit this hole? We need an intermediary to contact the two intranet hosts.

Now let's take a look at the process of one-to-peer software, the following example:

First, client a logs on to the server, and NAT a assigns a port of 60000 to the session, so server s receives the address of client a 202.187.45.3:60000, which is the extranet address of client A. Similarly, Client b logon server S,nat B assigns a port of 40000 to this session, then the address of B received by Server S is 187.34.1.56:40000.

At this point, both client A and client B can communicate with server S. If client a wants to send a message directly to client B at this point, then he can get B's public address 187.34.1.56:40000 from server s, is not client A to this address send information to client B can receive it? The answer is no, because if this message is sent, Nat B discards this information (because such information is unsolicited, and for security purposes, most NAT will execute the discard action). Now what we need is a hole in the direction of 202.187.45.3 (that is, client A's extranet address) on Nat B, and client A sends the message to 187.34.1.56:40000, and client B will receive it. Who will send this hole command, hehe, of course, the server S.

Summarize this process: If client A wants to send a message to client B, then client a sends a command to server s, requesting that server S command client B to hole in the direction of client A. Oh, is not very around the mouth, but it doesn't matter, think about it is very clear, not to mention the source code (Hou teacher said: No secret in front of the source code 8)), and then client a can be through the client B's external network address and Client B communication.

Note: The above procedure is only suitable for cone NAT, and if it is symmetric NAT, client B will not know if the port that client B punched into client A has been reassigned, and if the port of symmetric NAT is assigned in order, Then we may be able to guess the port number, but we do not recommend this method of guessing the port because there are too many factors that could lead to failure.

The following is a simulation of the process of peer chat source code, the process is very simple, p2pserver run on a computer with a public IP, p2pclient run after two different NAT (note that if two clients run on a NAT, this program will probably not run properly, Depending on whether your NAT supports loopback translation, see http://midcom-p2p.sourceforge.net/ Draft-ford-midcom-p2p-01.txt, of course, this problem can be solved by both parties first try to connect the other's intranet IP, but this code just to verify the principle, and did not deal with these problems), after the computer can be logged on to the computer to get the user name, after logging on to the computer through the Send The username message is sent in the format. If sent successfully, you have made a successful connection directly with the other party.

UDP cross-NAT principle (PEER)