UDP、NAT 和建立“连接”
我知道在谈论 UDP 时“连接”这个词并不合适，但是...
服务器（具有已知 IP 的服务器）如何通过 Internet 将其 UDP 数据包发送到 NAT 后面的客户端？
例如：假设客户端使用 TCP 上的某些消息传递连接并向服务器进行身份验证。 此时，服务器已准备好开始通过 UDP 将数据流式传输到客户端，但服务器如何知道在何处寻址 UDP 数据包，以便它们能够通过任何 NAT 路由器找到到达客户端的路径？
如果客户端首先通过 UDP 发送“我已准备好进行流式传输”消息，NAT 路由器是否会保持端口打开，以便服务器可以用其 UDP 数据流进行响应？
或者我在这里偏离了轨道？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
忽略路由器中已知端口转换的规定（即此端口上的数据转到此地址）（提供NAT），您可以使用UDP 打洞。
我假设您不是在谈论多播，其中每个对等点加入一个组并宣布发送给感兴趣的各方（在本例中为路由器），然后路由器可以执行适当的路由。 尽管这通常用于将流量有效地路由到多个主机，但按组路由机制将适用于您上面描述的情况。
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.
通常，TCP 级别的客户端前面的 NAT 将能够确定 UDP 的连接已创建。 尽管如此，客户端的 NAT 必须配置为接受来自 SRC 服务器端口的 UDP 数据包，然后将它们转发到内部目标 IP（客户端）。 需要记住的重要一点是 NAT 是否是调用者和被调用者。 NAT 在实施和功能方面有所不同，因此您可能想要实施一个通用的易于实施的解决方案，具体取决于您的需求。
我认为，您的假设是正确的，在您的情况下，客户端将无法接收信息中的 UDP 流。 在您的情况下，您的客户端必须将其 WAN IP 发送到您的服务器才能启动 UDP 连接。 查找您的客户端 WAN IP 可能很棘手，但有些网站可以通过在文本页面中返回 WAN IP 来帮助您确定您的 WAN IP。
如果服务器在 TCP 连接之后创建了 UDP 连接，通过服务器向客户端打开一个已知 UDP 端口的套接字，那么 UPnP 可能值得研究一下，它将允许您在 NAT 上自动设置端口转发，这只是如果您的 NAT 支持 UPnP，就像 DSL 路由器一样。
解决方法是客户端打开到服务器的 TCP 和 UDP 套接字。 由于 NAT 后面的客户端发起了连接，因此 TCP 和 UDP 连接的状态都将添加到 NAT 的连接表中。
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.
如果您谈论的是 SIP 或 RTSP 等流媒体协议，那么它的工作方式是在呼叫建立请求中指定客户端希望服务器发送到的 UDP 端口。
服务器将发送到该端口，并且流量可能会也可能不会到达客户端，具体取决于 NAT 是否已将客户端选择的端口转换为不同的数字。
当服务器从客户端接收到第一个 UDP 流数据包时，如果它位于与发送的端口不同的端口上，那么它将切换到该端口。 这使得来自服务器的 UDP 通过 NAT，因为客户端已经通过发送到服务器来创建 NAT 映射。
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.