通过服务器在 2 个客户端之间建立 p2p 连接答案

【问题标题】：p2p connection between 2 clients through server通过服务器在 2 个客户端之间建立 p2p 连接
【发布时间】：2015-08-21 15:34:30
【问题描述】：

如何通过服务器连接两个客户端，并在他们的连接服务器停用后？这意味着服务器无法获取任何用户数据，它只能连接它们。它可能是由 java se 制作的，还是完全可以制作？此外，客户端可能位于不同的本地网络中，因此仅获取客户端的地址可能无法正常工作。如果该方法不真实，您可以推荐其他类型的安全连接

【问题讨论】：

到目前为止，您尝试了哪些方法来使其正常工作？我的意思是did you ask google? 在那里你可以找到很多答案。即使在堆栈溢出时。
@Xean 我已经在另一个论坛上问过这个问题，我的答案是不可能的。我曾尝试通过互联网搜索答案，但大多数情况下我会收到有关简单本地客户端-服务器连接的问题
你能链接这个答案吗？这可能是一个有趣的背景。但是Jxta 呢？
@Xean 在阅读了几个小时的 p2p 网络示例后，我明白几乎不可能实现我的想法。我想为 android 制作 p2p messenger 应用程序，但现在似乎不可能使该应用程序可移植。用户必须设置他的路由器才能使用本地设备（端口和 ip）
安卓。很高兴知道。请下次在您的问题中提供此类信息。为了能够轻松更改网络（WiFi 和蜂窝网络），更改了上下文。你是对的，这很难做到（也许 Abhi 的回答有效？）。但我有另一个想法。给我一秒钟。

标签： java networking network-programming p2p

【解决方案1】：

我能想到三种可能的方法

:1: - 基于服务器 IP 的解决方案 - 客户端知道服务器的 IP 地址。服务器侦听服务器套接字，然后客户端（例如 A 和 B）通过此服务器套接字连接并注册自己。现在，当客户端 B 使用客户端 A 的众所周知的名称向服务器询问客户端 A 的 IP 地址时，服务器提供了客户端 A 的 IP 地址。客户端 A 将在服务器套接字上侦听 - 客户端 B 在此套接字上连接。需要注意确保使用可寻址的 IP 地址，即公共地址、相同的子网掩码、NAT 遍历......

:2: - 基于广播/多播 IP 的解决方案 - 所有客户端广播或多播（基于组） - 广播的一部分是众所周知的名称，因此客户端 B 会知道客户端 A 的 IP 地址是什么。客户端A 将在服务器 Socket 上侦听 - 客户端 B 在此套接字上连接。

:3: - 考虑现有库 JXTA 或 TomP2P 或 Hive2Hive 或 jnmp2p

也可以看看这个 - http://tutorials.jenkov.com/p2p/index.html

你的问题

如何通过服务器和他们的连接服务器停用后连接两个客户端？

:1 有效——一旦客户端 B 知道客户端 A 的 IP 地址——服务器就可以停用。服务器看不到客户端 A 和客户端 B 之间交换的任何数据。

它可能是由 java se 制作的，还是完全有可能？

是的，这是非常可行的——几年前我在 Java 中做过类似的事情——它是一个数码相机（客户端 A）远程连接到家里的存储设备（客户端 B）。（我实现了：1）

客户端也可以在不同的本地网络中

是的，它们可以位于不同的本地网络中，但它们应该是可寻址的。以我所做的为例，存储设备基本上位于家庭网络中，而数码相机则位于公共网络中。您可以使用 IPv6，也可以使用 NAT 穿越技术或端口转发 - 使不同网络中的客户端彼此可见。而且这种方法非常安全。

为了确保安全和高效，您将生成一个会话密钥（使用 Diffie Hellman），两个客户端将使用对称加密/解密来交换数据（使用 AES）。（您使用 RSA 生成会话密钥 - Diffie Hellman 的替代方案。一般来说，如果您可以使用数字证书，请使用 RSA - 如果您可以使用共享密钥，请使用 Diffie-Hellman）

如果不清楚 - 更详细地解释您的用例 - 我可以为您的用例解释。

【讨论】：

【解决方案2】：

这是一个 android Messenger 应用程序。您希望通过点对点连接来获得安全连接。也许Abhi's answer (first idea) 是可能的，但您还必须确保安全地连接两个设备。

p2p Messenger 的另一个缺点：两者都必须在线。如果其中一个连接不良，您可能会丢失消息，或者很难发送消息。

即使您有 p2p 连接，您也必须对通信进行加密，以获得良好的安全性。如果你有一个非常好的加密，你可能不需要 p2p 连接 [1]。

您需要的是一个好的加密协议。这是基本思想：

每个人都向您的服务器发布了 RSA 公钥。
A 想与 B 通话，因此 A 使用 B 的 RSA 公钥加密 A 的 AES 密钥。
B 使用 B 的 RSA 私钥解密 A 的 AES 密钥。
（也许 B 向 A 发送另一个 AES 密钥，但我认为两者都可以使用 A 的 AES 密钥）。
B 通过发送使用 A 的 AES 密钥加密的“Hello A”消息进行确认。
现在他们可以交流了。
也许在给定时间或多条聊天消息后替换 AES 密钥是个好主意。

您可能可以在 Stack Overflow 上find answers how to do this（如果您使用他的代码，请给他一个支持）。

为什么要使用这种复杂的协议，而不是使用 RSA 轻松加密所有内容？ RSA 和 AES 都是非常强大的加密协议，但 RSA 的计算速度不如 AES。您需要一个大的 RSA 密钥，例如 2048 位而不是 256 位 AES 密钥。这对手机来说是一个很大的缺点。更多的计算意味着更多的功耗。所以 AES 更快，但你不能公开密钥。他们在一起是一个非常强大的团队（尽管 RSA 将来可能会被量子计算机打破）！

[1] 如果一个坏人可以劫持正常的客户端-服务器-客户端连接，他可能会通过设置代理（中间人攻击）劫持连接两个设备的任务。这是您的信使协议的关键点，因为每次有人更改 IP（在 WiFi 和蜂窝网络之间切换）时，您都必须重新连接。

【讨论】：

很抱歉，您的回答不正确。虽然，我计划在我的应用程序中添加强大的密码学，感谢有用的提示，但客户端-服务器模型存在某种问题。服务器不能被用户完全信任，即使它是开源的。用户不知道服务器上设置了哪些程序，可能有不同的嗅探器或其他流量收集应用程序（我知道，这有点偏执；））。因此，使我的服务更可信的唯一方法是建立 p2p 连接。它不会解决所有问题。我认为该服务器只能包含 DHC 或类似
加密是下一步。现在我必须建立 p2p 连接
我认为系统必须像 BitTorrent 网络。 BT 在不同的平台上工作，似乎它在向其他对等方发送数据（上传）方面没有任何问题。返回收集信息
如果您不信任服务器，那么您无法使用服务器启动 p2p 连接，您必须输入 IP 地址和端口，如您所说。您可以嗅探任何加密数据，但您唯一知道的是，何时发送和接收此数据，但对内容一无所知。