我目前正在实施UDP服务器浏览器功能，因此玩家可以通过php页面（IP＆amp;端口）找到游戏服务器，然后从该地址请求游戏数据。 这个游戏数据包括诸如玩家/游戏模式的数量，但也包括“真实”端口，游戏本身基于TCP。
示例：1.1.1.1:1000上的游戏已在该php页面上注册
现在我希望我的服务器浏览器将UDP数据包发送到此地址和端口，然后侦听响应以获取此游戏数据。
这不是问题，至少在没有防火墙限制的情况下不在局域网中。
我只是好奇，如果这也可以通过互联网，让我们说：
服务器在路由器后面的1.1.1.1:1000（用于游戏的TCP和用于游戏数据的UDP）上运行。 此服务器的端口正确转发，因此客户端可以通过IP直接连接，并且可以接收和回答游戏数据请求。
IP 2.2.2.2的客户端在服务器浏览器上找到了这个服务器，并想获取游戏数据。他也在路由器后面，但没有转发任何端口。
现在在TCP中这很容易：ServerSocket可以接受传入连接并回答它们，客户端的Socket可以接收答案，因为客户端自己向服务器发出了请求，对吗？
UDP也是如此吗？同样，客户端通过UDP将数据包发送到1.1.1.1:1000。默认情况下，新的DatagramSocket（）绑定到“某个”可用的UDP端口，在这种情况下假设为2000。现在我可以简单地使用socket.getLocalPort（）并获取此端口，构造请求数据包并将客户端的端口放在那里。发送后，客户端使用此DatagramSocket对象来侦听响应。
服务器接收此请求数据包并且现在具有客户端的本地端口号，因此它将包含游戏数据的应答包发送到此端口。 （2000）
客户端是否能够接收此数据包？我会说是的，因为客户端使用这个UDP端口将数据包发送到它收到答复的IP，所以客户端的防火墙应该让“回答”到该端口。
并且：收到的数据包的DatagramPacket.getPort（）是否包含发送方的已使用的UDP端口？ 示例：在端口1000上接收从端口2000发送的数据包 - ＆gt; getPort（）返回1000还是2000？
感谢您的回答：）
答案 0 :(得分：0)
一般是的。 NAT通常会允许对刚刚看到的传出数据包的UDP源 - 目标对的传入响应。但是，超时会有所不同。
答案 1 :(得分：0)
这里TCP和UDP没有区别。在这两种情况下（客户端连接到服务器，路由器进行端口转发到服务器）都有NAT：网络地址转换。
如果我们以nat为背后的客户端和服务器的情况：
当服务器发回数据包时，会发生相反的情况。但原则是一样的。再次，TCP，UDP，这里没有区别。
唯一的区别是路由器跟踪这些地址/端口映射的“难度”。 TCP的 比UDP更容易（因为TCP是面向会话的）。但请注意，这也必须针对ICMP执行（这对于ping是必需的，但也是网络不可达的消息和其他; ping是echo-request out，echo-reply in。）
（作为附注，也许这属于serverfault？）