TCP 打孔对此是否实用？答案

【问题标题】：is TCP hole punching practical for this?TCP 打孔对此是否实用？
【发布时间】：2017-05-22 21:17:18
【问题描述】：

这个项目有点类似于家庭自动化项目，所以请记住家庭自动化。

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

我听说 P2P 的 TCP 打孔可能不可靠，但是使用S 作为所有请求的代理似乎不切实际，因为S 上的负载会很大。

我的目标：

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

我大致知道打孔的工作原理，S 必须将两个客户端的端点相互提供，以便他们都可以尝试启动连接。并且我对 NAT 也有很好的了解

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

【问题讨论】：

定义“集线器”。 “集线器”与服务器有何不同？为什么M不能发起到“H”的TCP连接？
集线器实际上是一个服务器，是的，但是它不能全局访问M 不知道H 的端点。 M 和 H 都必须启动连接，否则打孔将不起作用，您能详细说明您的意思吗？
如果我理解你的问题，尝试允许 H 与 M 建立 TCP 连接是非常罕见的，其中 H 充当 TCP 客户端（它发送 SYN 数据包）而 M 充当TCP 服务器。通常的解决方案是始终让 M 建立连接，可能使用一些轮询方案或使用移动客户端的本机推送通知服务来降低移动设备的功耗。
我认为您不了解打孔的工作原理。 H 和M 必须都发送数据包来发起连接，如果只有M 或H 发送一个数据包，它将被防火墙阻止，对方不会意识到它已经发送了一个数据包。
M 将始终通过向S 询问H 的端点并告诉H 将数据包发送到M 来启动连接。如果这就是你的意思？

【解决方案1】：

如果 M 或 H 都无法启动通过 TCP 连接？（使用 UDP？）

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

如果 TCP 打孔在这种情况下不起作用，我可以发送 UDP 而是打包？（UDP 在交付方面是不可靠的，所以会发送多个重复数据包保证交付？）

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

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

【讨论】：