据我所知，推送通知适用于应用，因为客户注册其设备并具有唯一ID，然后通过持久连接（连续打开的连接）将通知转发到该唯一ID。换句话说，在Facebook中，用户想要向另一个发送消息，然后消息被发送到facebook上的中央服务器，它从那里转发到Apple或Google（或两者，我不知道）然后Apple或Google的服务器将邮件转发给ID与发件人的ID匹配的收件人。精细。这个过程是：
发件人＆gt; facebook服务器＆gt; Apple / Google＆gt;接收器
如果应用程序本身为其客户组织了一个VPN，那么说Facebook有自己的VPN。然后，这样的消息是否可以通过表格的VPN上的路由立即从发送方发送到接收方：
发件人＆gt;接收器
此外，通过这种方法，客户端不必打开连接。例如，他们可以让服务器监听VPN上的端口，然后VPN中的消息路由必须通过Facebook服务器和底层电信基础设施进行处理，从而省略与Apple或Google服务器的通信。因此，这种方法似乎比推送通知有两个优势：
这种方法的缺点是什么并没有使用，而是我们有推送通知，它们都有持久连接，并且需要与Apple或Google服务器通信，以便通知可以到达目的地？
答案 0 :(得分：3)
VPN不是为了这个，但无论如何它们还是（客户端 - > VPNServer-＆gt;客户端）以及客户端 - 服务器架构。
你想要的是P2P，但是今天的大多数用户（桌面和移动用户）都在NAT之后，因此如果没有适当和特定的NAT配置，就无法接收网络请求。
无论如何，我可以考虑一些替代方案，但它们不会广泛开展工作。一个可以是：
基于某个服务器的客户端，通过uPNP为与该服务器约定的端口中的自己的LAN地址创建NAT条目。将打开与服务器通信的连接的客户端现在知道它可以直接打开与该地址和端口的连接。 （问题：并非所有NAT都支持uPNP配置，一小部分用户甚至无法配置他们的NAT，因为他们无法访问它）
其他的
NAT侦听公共IP中的某些TCP / IP端口以获取新协议。 TCP / IP之上的此协议将隧道通信，通知LAN地址或稍后聚合的某些会话，NAT应该重定向数据包。 （问题：新协议，需要在NAT中实现，一些安全风险）
注意： NAT很好。想想局域网中有15台计算机的地方。现在，如果NAT不存在，LAN中的所有计算机都需要不同的真实Internet IP。互联网IP并不便宜，因此成本会高得多，互联网IP饥饿会更快。功能