使用服务器绕过路由器发起连接

发布于 2024-11-02 06:24:57 字数 449 浏览 12 评论 0原文

我想用Java 创建简单的聊天程序,它可以在p2p 基础上工作。使用公共服务器仅发起连接。但我什至不确定这是否可能。

我成功地用 Java 实现了聊天解决方案,只要至少一台 PC 转发了正确的端口,该解决方案就可以工作。我还设法使用外部服务器,而不是必须在客户端转发端口。

因此,我什至有可能以某种方式使用公共服务器来启动连接,然后在客户端之间发送数据,从而减轻服务器的负载?

我不太熟悉路由器的工作原理,但我希望当您从内部 IP 呼叫公共服务器时,路由器会记住来自该公共 IP 的呼叫和传入响应,而不是发送到您的 PC。所以我想,也许如果第一个客户端连接到服务器,服务器将信息传递给第二个客户端,也许他们可以以某种方式直接通信?路由器中的规则是否是由服务器建立的?

我希望我解释清楚了。如果没有请原谅。我什至不知道这到底是如何做到的,我只是想知道我的概念是否正确,而且我必须更加努力地学习,才有机会让它发挥作用。谢谢。

I would like to create simple chat program in Java, which could work on p2p basis. Using public server to only initiate connection. But I am not even sure this is possible.

I succesfully implemented chat solution in Java that work if at-least one PC has forwarded the right ports. I also managed to use external server instead od having to have forwarded ports on client side.

So I though, would be even possible, to somehow use public server to initiate connection, and than send data just right between clients, taking load off the server?

I am not very familiar with how routers work, but I expect when you call public server from internal IP, router remembers that call and incoming response from that public IP than sends to your PC. So I thought, maybe if first client connected to the server, server than passed information to the second client, maybe than they could somehow communicate directly? If the rule in router was established by the server?

I hope I explained it clearly. If not please excuse me. I don´t even know how exactly this could be done, I just want to know if there is something right on my concept, and I have to study harder with chance of getting it operational. Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

乖乖哒 2024-11-09 06:24:57

我认为 TeleHash 是一个可以做这样的事情的新项目。我是最近才知道的,所以不太了解。

我制作了这个答案社区 wiki,以便其他人可以更新它以解释 TeleHash 如何用于此目的。

I think TeleHash is a new project that can do things like this. I only found out it about recently so I don't know much about it.

I made this answer community wiki so others can update it to explain how TeleHash could be used for this.

幸福还没到 2024-11-09 06:24:57

这是一个很大的主题,搜索打洞(对于 TCP:http://en.wikipedia.org/wiki/TCP_hole_punching)

It's a vast subject, search for hole punching (for TCP: http://en.wikipedia.org/wiki/TCP_hole_punching)

一曲琵琶半遮面シ 2024-11-09 06:24:57

编辑:在评论(并阅读链接页面)之后,我应该撤回我的建议。为了漂亮的图形,我没有删除它,但更改了最后一部分。


如果我理解正确的话,您有两个客户端都位于 NAT 防火墙后面,该防火墙允许传出连接,但如果没有专门配置为这样做,则不会转发传入连接(因为它们不知道它的目的地是哪一个本地主机)。

原则上,TCP 连接在其整个存在期间始终连接相同的两个 IP 地址和这些地址上的端口号(例如,我们有四个保持不变的数字)。在 NAT 情况下,您实际上有两个连接,但这从客户端计算机 A(也从服务器 S)看不到:

Client A  -------(LAN)------ NAT B      ------ (Internet) -------- Server S
  IP A                   IP B1 | IP B2                               IP S
  Port a                       | Port b                              Port s

TCP 数据包具有 [A:a / S:s](或 [S:s / A :a]) LAN 部分的地址和 Internet 部分的 [B2:b / S:s](或 [S:s / B2:b])地址。连接由这个 [IP:port / IP:port] 四元组标识,因此,如果您尝试更改这四个数字之一,则这必须是一个新连接(否则数据包将被丢弃)。

因此,如果您首先与服务器通信,则无法继续与同一连接上的其他客户端通信,除非服务器正在转发内容。

实际上 UDP 数据包的情况也是如此,不同之处在于没有连接,并且 NAT 必须很聪明,并猜测哪个数据包是另一个数据包的答案,从而将其转发到正确的方向。

正如评论和其他答案所指出的,这里是 NAT 可能被欺骗的地方:我们首先向另一个客户端发送一个 UDP 数据包,该数据包将被那里的 NAT 丢弃。但随后另一个客户端发送一个应答数据包,该应答数据包并不是对传出数据包的真正应答(因为由于其他客户端 NAT,该数据包从未收到),但 IP 地址和端口号匹配,它仍然会被允许通过。如果 NAT 还转换端口号,则情况会变得更加复杂。

对于 TCP,如果两个 NAT 并未真正保持开放连接,而只是在之前发送了 SYN 时转发(已更改)数据包,则它可以类似地工作。它甚至更复杂,因为 TCP 序列号也必须在这里匹配。

Edit: After the comments (and reading the linked pages), I should retreat my advice. I don't delete it, for the nice graphic, but changed the last part.


If I understand right, you have two clients both behind a NAT firewall, which allows outgoing connections, but does not forward ingoing connections if not specially configured to do such (since they have no idea for which of the local hosts it is destined).

In principle, a TCP connection during its whole time of existence always connects the same two IP addresses and port numbers at these addresses (e.g. we have four numbers which stay constant). In the NAT case, you in fact have two connections, but this is not visible from the client computer A (nor from server S):

Client A  -------(LAN)------ NAT B      ------ (Internet) -------- Server S
  IP A                   IP B1 | IP B2                               IP S
  Port a                       | Port b                              Port s

The TCP packets have [A:a / S:s] (or [S:s / A:a]) addresses on the LAN part and [B2:b / S:s] (or [S:s / B2:b]) addresses on the internet part. The connection is identified by this [IP:port / IP:port] quadruple, so if you try to change even one of the four numbers, this has to be a new connection (or the packet will be thrown away).

So, if you first are speaking with your server, you can't continue to speak to the other client on the same connection, unless the server is forwarding the content.

The same is in fact the case for UDP packets, with the difference that there are no connections, and the NAT has to be smart and guess which packet is an answer to which other packet, and as such forward it to the right direction.

As pointed out by the comments and other answers, here is the point where the NAT can be tricked: We first send a UDP packet to the other client, which will get thrown away by the NAT there. But then the other client sends an answer packet which is not a real answer to the outgoing packet (since this packet was never received due to the other clients NAT), but the IP addresses and port numbers match, it still will be let through. This can get more complicated if the NAT also translates the port numbers.

For TCP, it can work similar, if both the NATs not really hold an open connection but simply forward (changed) packets when there was a SYN sent before. It is even more complicated, since also the TCP sequence numbers have to match here.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文