客户端服务器架构

Question

我正在为我的应用程序的服务器客户端方面选择什么技术而苦恼。

定义设计

• .net 2 上的 Windows、C#
• 在许多机器上都有 .net 2 服务。我称之为客户。
• 机器可以位于 NAT 后面（或未连接到 Internet）的不同网络中。
• 服务器服务是公开的。

要求

• 按需与客户沟通。
• 客户端必须监听传入的连接。
• 服务器可以在线也可以不在线。
• 无法进行端口转发。

我有哪些选择来做这样的事情？ 现在我正在研究 UDP 打孔技术。 UDP 打孔技术设置和我的设置之间的区别在于，我没有在 NAT 和中介服务器后面有 2 个客户端，而是在 NAT 后面只有一个必须与服务器通信的客户端。那一定更容易，但我很难理解和实施。 我在这种 NAT 遍历方面走在正确的道路上，或者可能是其他一些更容易实现的方法？

我考虑过的其他方法：

• 当服务看到服务器在线时，使用 TCP 创建到服务器的连接。问题是我有大约 200 个客户，而且这个数字还在上升，我担心这是一个资源杀手。

• 当服务看到服务器在线时，检查数据库表中的命令，然后每 30 秒再次检查一次。这也是我服务器的资源杀手。

最重要的是，如果 UDP Hole Punching 技术是这种情况下的正确方法，请提供一些代码想法，用于将在 NAT 后面的服务上运行的 de UDPServer。

谢谢。

Answer 1

打孔和 p2p

您可能对high level discussion of UDP hole punching 感兴趣。如果您希望客户端（可能都位于防火墙后面）无需中继服务器直接通信，则需要打孔。这是对等 2 对等 (p2p) 通信工作的次数。

对于 p2p，通常经过 NAT 的客户端必须使用某些外部服务器来确定彼此的“服务器反射地址”。当发生 NAT 转换时，防火墙后面的端口可以映射到某个任意端口以供公众使用。客户端可以使用STUN server 来确定其“服务器反身地址”。然后，客户端将通过中间服务器交换服务器自反地址，并可以发起通信（通过打孔来发起会话）。

通常，NAT 的行为方式不允许如上所述的直接通信。将数据包发送到不同的目的地将导致 NAT 将端口映射到完全不同的值，具体取决于目的地。在这种情况下，需要TURN server。

链接

• Nat traversal and different types of NAT behaviors
• STUN RFC
• TURN RFC

服务器-客户端通信

如果您的客户端只需要与服务器通信，则不需要打孔。只要客户端可以与公共 Internet 通信，那么您就可以使用任何 C# 套接字 API（我对 C# 不熟悉）来连接到服务器的公共 IP/端口组合。通常，进行套接字连接的客户端不会指定源端口，而是让底层套接字 API 做出决定，因为这并不重要。

你的服务器应该监听一个特定的端口（你做出这个决定），当它接收到来自客户端的数据包时，数据包的源地址将是某个经过 NAT 的地址。换句话说，源地址将是您的客户端所在的任何防火墙的公共 IP。如果 NAT 改变了客户端数据包的源端口，服务器会将这个 NAT 的端口视为源端口。这真的没关系，因为当服务器发回响应数据包时，客户端机器上的 NAT 将转换目标端口（它在内部存储转换）并正确地将数据包发送回正确的私有主机（客户端）。