0

据我所知，推送通知适用于应用程序，因为客户端注册了他们的设备并具有唯一 ID，然后通知通过持久连接（持续打开的连接）转发到该唯一 ID。换句话说，在 facebook 中，一个用户想要向另一个用户发送消息，然后该消息被发送到 facebook 上的中央服务器，然后从那里转发到 Apple 或 Google（或两者，我不知道） ，然后 Apple 或 Google 的服务器将消息转发给 ID 与发件人的 ID 匹配的收件人。美好的。过程是：

发件人 > facebook 服务器 > Apple / Google > 收件人

如果应用程序本身为它的客户组织了一个 VPN，比如说 facebook 有自己的 VPN。那么，这样的消息是否可以通过以下形式的 VPN 上的路由立即从发送者发送到接收者：

发送者 > 接收者

此外，通过这种方法，客户端不必打开连接。例如，他们可以让服务器监听 VPN 上的端口，然后必须通过 facebook 服务器和底层电信基础设施处理 VPN 中的消息路由，从而省略与 Apple 或 Google 服务器的通信。因此，与推送通知相比，这种方法似乎有两个优点：

  • 客户端没有持久连接，并且
  • 无需与 Apple 或 Google 服务器通信。

这种方法的缺点是什么，它没有被使用，但是我们有推送通知，它们都具有持久连接，并且需要与 Apple 或 Google 服务器通信，以便通知可以到达目的地？

4

1 回答 1

3

VPN 不是为此而设计的，但无论如何它们仍然是（客户端-> VPNServer-> 客户端），因此是客户端-服务器架构。

您想要的是 P2P，但今天的大多数用户（桌面和移动）都在 NAT 后面，因此如果没有适当和特定的 NAT 配置，就无法接收网络请求。

无论如何，我可以考虑一些替代方案，但它们不会广泛使用。一个可以是：

基于某个服务器的客户端，通过 uPNP 在与该服务器约定的端口中为其自己的 LAN 地址创建一个 NAT 条目。将打开与服务器通信的连接的客户端现在知道它可以直接打开到该地址和端口的连接。（问题：并不是所有的 NAT 都支持 uPNP 配置，一小部分用户甚至无法配置他们的 NAT，因为他们无权访问它）

其他

NAT 在公共 IP 中的某些 TCP/IP 端口上侦听新协议。TCP/IP 之上的这个协议将隧道通信，通知 LAN 地址或稍后聚合的某些会话，NAT 应该重定向数据包。（问题：新协议，需要在NAT中实现，存在一些安全隐患）

注意： NAT 是好的。想象一个局域网中有 15 台计算机的地方。现在如果不存在 NAT，局域网中的所有计算机都需要不同的真实 Internet IP。互联网IP并不便宜，所以成本会高很多，互联网IP饥饿会更快。

于 2013-09-18T13:21:47.060 回答