rest - TCP 打洞是否实用？

Question

此项目有点类似于家庭自动化项目，因此请牢记家庭自动化。

• 我有一个全局可访问的服务器，称为 S
• 有一个名为M的移动客户端
• 有一个名为H的集线器>

由于很多 IP 都是动态的，ISP 对静态 IP 收取额外费用，让客户为我的应用程序转发他们的端口是不切实际的。

我听说 P2P 的 TCP 打洞可能不可靠，但是使用 S 作为所有请求的代理似乎不切实际，因为 S 会承受巨大的负载>.

我的目标:

将 M 连接到 H 以便它们可以向彼此发出 RESTful HTTP 请求。

我的问题

1. 如果 M 或 H 都无法通过 TCP 发起连接，我将如何处理这种情况？ (使用 UDP？)
2. 如果 TCP 打洞在这种情况下不起作用，我可以发送 UDP 数据包吗？ (UDP 在交付方面不可靠，因此发送多个重复数据包是否可以保证交付？)

注意事项

我大致知道打洞是如何工作的，S 必须将两个客户端的端点提供给彼此，以便它们都可以尝试发起连接。并且我对 NAT 也有很好的理解

也许对于 TCP Hole Punching 无效的罕见情况，S 可以充当代理

Answer 1

1. How would I manage a situation where neither M or H can initiate a connection via TCP? (use UDP?)

是的，通过 UDP。或者通过 S 使用 TCP。

2. If TCP Hole punching doesn't work in the situation, could I send UDP packs instead? (UDP's are unreliable in terms of delivery, so would sending multiple duplicate packets guarantee delivery?)

这取决于。您必须在接收方进行检查，以确定是否收到数据包，然后向发送方发送通知。因为您可能会发送 10/20 个相同的数据包，但它们仍然可能无法到达接收方。但是如果你想要可靠的数据包传输和 UDP，那么有一个名为 RUDP 的协议(protocol)。 .

请注意无论您使用TCP还是UDP，您都无法始终成功建立P2P连接。很多时候你必须通过 S 建立连接，否则连接失败。场景是如果端点之一具有对称 NAT，而另一个端点具有 PRC/对称 NAT。如今，许多基于 LTE 的连接都使用对称 NAT。