WAN 上的 TCP 和 UDP 套接字服务器
我正在尝试创建一个同时使用 TCP 和 UDP 的服务器和客户端。服务器在 LAN 设置中运行良好，但通过 WAN 传输时无法接收 UDP 消息。我相信这是因为用于发送数据的 UDP 套接字在 NAT 表中保留的时间不够长，无法返回任何信息。有没有办法让 UDP 端口在路由器中保持打开状态（无需端口转发）或使用与已连接的 TCP 连接相同的 UDP 端口？提前致谢。
I am attempting to create a server and client that utilizes both TCP and UDP. The server works very well in a LAN setting but the UDP messages are not being received when transmitted over a WAN. I believe it is because the UDP socket used to send the data is not remaining in the NAT tables long enough to return any information. Is there a way to either make the UDP port stay open in the router (without port forwarding) or use the same port for UDP as the already connected TCP connection? Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您没有收到任何流量，则可能只是被防火墙阻止了。在这种情况下，它不是关于转发，而是关于打开端口。
一旦穿过 NAT，大多数（如果不是全部）NAT/防火墙设备将允许双向 UDP 流量。也就是说，如果我的笔记本电脑位于 NAT/防火墙后面，将 UDP 数据包发送到 Internet，我的 NAT/防火墙将允许将 UDP 流量返回到原始端口号。我经常使用 UDP，根据我的经验，这是规则，很少有例外。
请记住，虽然不保证 UDP 数据包一定会送达。
您的客户端位于 NAT 后面吗？客户端发送的数据包是否到达服务器？问题出在服务器到客户端的方向吗？
如果您对 UDP 和 TCP 使用相同的端口号，则情况不会改变。您不能搭载 TCP 连接，因为它是不同的协议。
单播 UDP 的网络地址转换 (NAT) 行为要求
http://en.wikipedia.org/wiki/UDP_hole_punching
If you're not getting any traffic it is probably simply blocked by the firewall. In this case it is not about forwarding, it is about opening the port.
Most (if not all) NAT/Firewall devices will allow UDP traffic in both directions once a hole is punched through the NAT. That is, if my laptop here, sitting behind a NAT/firewall, sends a UDP packet out to the Internet my NAT/firewall will allow return UDP traffic to the originating port number through. I work a lot with UDP and my experience is that this is the rule and very few exceptions.
Keep in mind though UDP packets are not guaranteed to be delivered.
Is your client behind a NAT? Do any packets the client send get to the server? Is the problem in the server to client direction?
If you use the same port number for UDP and TCP this will not change the situation. You can't piggyback on a TCP connection because it is a different protocol.
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
http://en.wikipedia.org/wiki/UDP_hole_punching