UDP, NAT and setting up “connections”

问题:

I know the word "connection" isn't really appropriate when talking about UDP, but...

How does a server (the one with the known IP) get its UDP packets through the Internet to a client that is behind NAT?

For example: say a client connects and authenticates to the server using some messaging over TCP. At this point the server is ready to start streaming data to the client over UDP, but how does the server know where to address the UDP packets so that they would find their way through any NAT routers to the client?

If the client fist sends an "I'm ready for the streaming please" message over UDP, would the NAT routers keep the port open so that the server can respond with its stream of UDP data?

Or am I waay off track here?

回答1:

Generally the NAT in front of the client at the TCP level will be able to determine that the connection at the UDP was create. Having said that, the NAT on the client side will have to be configured to accept UDP packets from the SRC server port, and then forward them to the internal destination IP (client). Important thing to remember if NAT is who is the caller and who is the callee. NATs differ in implementation and capablity so a generic easy to implement solution is probably what you might want to implement, depending on your needs.

You are correct in assuming, i think, that in your case client will not be able to receive the UDP stream in information. In your case your client will have to send its WAN IP to your server to initiate the UDP connection. Finding your clients WAN IP can be tricky but there are websites that will aid your determing your WAN IP by returning it in a text page.

If the UDP connection is created after the TCP connection by the server opening a socket to the client to a known UDP port then, UPnP might be worth looking into it will allow you to automatically set up your port forwards on your NAT, that is only if your NAT supports UPnP as is the case of DSL routers.

A work-a-round would be to client to open both TCP and UDP sockets to the server. Since the client behind the NAT initiated the connection the states of both TCP and UDP connections will be added to the NAT's connection table.

回答2:

Ignoring the provision of known port translation (i.e. data on this port goes to this address) in your router (providing the NAT), you can use UDP Hole Punching.

I assume you're not talking about multicasting, in which each peer joins a group and announces that to interested parties (in this case the router), which can then perform the appropriate routing. Although that's normally used for routing traffic efficiently to multiple hosts, the routing-by-group mechanism would work for you're describing above.

回答3:

If you're talking about streaming protocols like SIP or RTSP then the way it works is that the UDP port the client wants the server to send to is specified in the call set up request.

The server will send to that port and the traffic may or may not get through to the client depending on whether the NAT has translated the clien't choice of port to a different number or not.

When the server receives it's first UDP streamed packet from the client and if it is on a different port to the one it was sending on then it will switch to it. This lets the UDP from the server get through the NAT since the client has already created the NAT mapping by sending to the server.