我有一个想法,udp 不是无需建立连接就能发送数据包吗,有如下一个场景
1 、有一个 tracker 服务器
2 、用户 a
3 、用户 b
1 、用户 a 向 tracker 服务器发送 udp 数据包
2 、tracker 服务器接收到 udp 数据包后通知用户 b (由于 b 处于内网环境,用户 b 向 tracker 服务器主动获取通知)
3 、然后用户 b 获取从 tracker 服务器获取用户 a 的 ip 信息, 然后用户 b 向 a 发送数据包,这样数据就不用通过 tracker 服务器中转,节省 tracker 服务器带宽
有没有计算机网络的大佬能不能说一下这个方案的可行性怎么样
1
titanium98118 2023-10-10 11:47:09 +08:00
我印象中 BT tracker 只交换 peer 信息,不做数据中转?
|
2
smilekung 2023-10-10 11:48:01 +08:00
这不就是 udp 打洞么,如果双方都没有公网是很难成功的,因为 tracker 拿到的是 nat 地址,直连是不一定能打通的
|
3
AoEiuV020JP 2023-10-10 12:12:09 +08:00 13
思而不学则殆
|
4
NoOneNoBody 2023-10-10 12:17:43 +08:00
tracker 只是个“临时通讯录”
tracker 的压力是请求数量巨大,不是传送数量 |
5
luny 2023-10-10 12:22:53 +08:00
1. 内网用户可以通过 trakcer 获取 peer 节点信息,主动连接,外网用户可以被动连接,速度会更好
2. 有个 DHT 的技术,现在客户端都支持,可以不需要 tracker 服务器,实现 peer 获取 |
6
nothingistrue 2023-10-10 12:30:25 +08:00
首先纠正一点,UDP 是不需要回复确认,不是不需要建立连接,可以认为它是单向连接。UDP 因为是单向连接,如果双方要相互沟通数据那么双方都得在公网上,这点反而不如 TCP 。
补上 2 点,就是 BT 下载的方式。 1 ,a 、b 跟 tracker 之间,只会沟通用户 a 、用户 b 的信息,不会传递真正的数据文件。跟 traker 之间的沟通,UDP 、TCP 皆可,不过如果是正常网络那么 TCP 就很浪费。 2 ,a 、b 各自从 traker 获取到对方的信息之后,a 、b 之间就抛开 tracker 直接建立 TCP 连接,然后相互传递文件数据了。a 、b 之间,最少有一个要有公网端口( NAT 出来的端口也行),否则是无法建立 TCP 连接的。 |
7
Maboroshii 2023-10-10 12:50:06 +08:00
复制于 google, 可以了解下就知道了。
NAT 转换类型一般有 4 种: NAT1:Full Cone NAT (完全圆锥型,一对一) NAT2:Restricted Cone NAT (地址限制圆锥型) NAT3:Port Restricted Cone NAT (端口限制圆锥型) NAT4:Symmetric NAT (对称型) |
8
iOCZ 2023-10-10 12:57:51 +08:00
存在无法连上其他 peer 的可能性的
|
9
bler OP @nothingistrue 我知道 udp 不需要回复确认,但是 a,b 都处于内网之中,b 向 a 无法直接发送数据啊。还有 a,b 用户通过公网建立 tcp 连接,b 向 a 发送数据不一样要占公网服务器的带宽吗。
|
10
bler OP @titanium98118 那我们下载的数据从哪来的,总得要有一个公网做 a 和 b 数据转发吧, 那同样要占用这个公网服务器的带宽了,这个公网服务器是由谁提供的呢
|
11
bler OP 能哪位大佬能出个 a,b 两个内网用户交互种子资源的网络拓扑图吗,主要是数据的流向,怎样流动的,我想知道各方的带宽占用情况,这个 p2p 到底是怎么个数据流向,尤其是国内这种都处于内网的情况下
|
12
xiaozecn 2023-10-10 13:27:49 +08:00 via Android 2
一个被封杀的账号几年前做的科普视频,?si=7hmgM0WEhavAwVr9
|
13
titanium98118 2023-10-10 13:33:37 +08:00
@bler #10 那我们下载的数据从哪来的:1 、由下载完成的用户上传,即种子。2 、正在下载中的用户上传已有的部分
|
14
expy 2023-10-10 13:37:33 +08:00
两个内网用户基本连不上,不过现在 ipv6 基本普及了,大家都是公网。
|
15
bler OP @xiaozecn 谢谢,我的主要目的还是想知道,在 a,b 两个用户处于内网( nat )网络环境下,有没有方案实现不依托于公网服务器交换数据,公网服务器只交换两者的地址,然后两者自己进行数据交互,这样能不占用公网的带宽流量。所以我才有上面的一个设想场景,a 内网发送请求,tracker(或者是其他中转服务器)完成对 b 的网络交互通知,然后 b 发送数据给 a ,而不是 b 把数据给 tracker(或者是其他中转服务器),然后再发送给 a
|
16
wy315700 2023-10-10 13:39:58 +08:00
a,b 两个内网用户基本上是连不上的
这个时候就需要一个公网用户 c ,a 和 b 从 c 下载东西。 OP 以前没玩过电驴吧,电驴会根据其他用户能否连上你的端口给你分 high ID 还是 low ID 的。 |
17
asdgsdg98 2023-10-10 13:44:35 +08:00
你是全锥形,就可以随意下载和上传,理论上能访问任何资源
你是对称型的话,基本告别 bt 了 |
18
TNOK 2023-10-10 13:45:30 +08:00
@bler BT 现在就是这么实现的呀,没有中转的,tracker 就是为了让 a 和 b 建立连接不干别的,就算是内网,如果打洞成功也是可以将 a 和 b 连接起来的,你说的那种纯大内网右下角会显示不通并且没有速度的
|
19
bler OP 找个一个讲的比较好的文章,感兴趣的可以看看: https://www.h3c.com/cn/d_201206/922130_30005_0.htm
|
20
MeteorVIP 2023-10-10 14:09:02 +08:00
tracker 服务器是通讯录.存有 A 和 B 的 ip,上传和下载不通过 tracker 服务器.是 A 和 B 之间相互传文件.
|
21
Gawainnnn 2023-10-10 14:50:23 +08:00
BT 数据从来都不过 tracker ,tracker 只是存的用户信息,让互联网瞎子用户 A 用户 B 知道对方的存在,建立连接是用户自己的事
|
22
nothingistrue 2023-10-10 14:53:36 +08:00
@bler #9 a 、b 两个是直连的,他们不经过公网上其他地方的中转。
通过端口转发等措施,即使是内网机器,也可以在公网上开放端口。这个开放的不是完整 IP ,而是一个 IP 加特定端口,但 TCP 连接有端口就够了。NAT 网络中,不管是 BT 下载,还是电驴下载,还是点对点聊天,开启 UPnP 是必要条件。 不过 UPnP 或者其他端口转发措施,是网关/路由器提供的,家里的路由器可以自己开,运营商那里的网关是铁定不会开的,所以一旦运营商给的就是内网 IP 那就直接歇菜了。但是,TCP 连接只需要被叫端在公网就可以连得起来,故 a 、b 两个只要有一个在公网有端口,就可以连得上。这在 BT 下载的表现上是:如果你在内网,那么能看到很多主机,但是只能连接其中在公网上的;如果你在公网,那么你看到多少主机就能连接到多少主机。这个在非服务器建主的对战游戏中也有表现:如果你在内网,那么你只能进别人的主机,你建的主机别人进不了。 |
23
bler OP @nothingistrue 谢谢老哥了,已经有点搞明白这个了, @smilekung 这个老哥说的对,我描述的场景其实就是 udp 打洞的场景,这篇文章 https://www.h3c.com/cn/d_201206/922130_30005_0.htm 还介绍了 tcp 打洞的场景,还有很多关于 nat 方面的东西
|
24
jsq2627 2023-10-10 15:53:15 +08:00 via iPhone
BT 下载并没有引入复杂的 NAT 穿透技术,如果两个 peer 之间不能直通,就放弃传输了,也不会有服务器中转
作为对比,在同为 P2P 的 WebRTC 等音视频应用里,就会各种尝试 UDP 打洞,如果最终还是不能直连,还有服务器能中转流量保证正常通话。 |
25
bler OP 参考一下各位老哥的回复以及看的一些文章总结一下:
1 、打洞相关的原理 https://www.h3c.com/cn/d_201206/922130_30005_0.htm 2 、nat 不同模式的一些区别(会影响打洞的情况): https://myth.cx/p/qbittorrent-nat-tcp-hole-punching/ 3 、我在其他论坛里发现 比特彗星 已经实现了 udp 打洞的场景,据说开发组里有国人, qBittorrent 不行,毕竟美国佬人手好几个 ip ,不太理解 nat 套好几层这种神奇场景。 4 、tracker 是提供 peer 信息的,并不作为服务器做数据转发, 之前想当然了,美国佬人手几个 ip ,直接就能通过 ip+port 下载数据了,没有这种复杂数据中转场景。 |
26
KorenKrita 2023-10-10 16:53:30 +08:00
LZ 看来对 BT 不是很了解 有一些想当然的设想导致前面沟通不畅
我简单把实际的 BT 和 LZ 设想的 BT 做一下区别介绍 希望 LZ 能理解 1.Q:peer 的双方都既没有公网 ip 也都没有可直达的 FC NAT 能否互相传输文件 A:不可以,双方都会在 tracker 处获取到对方 ip 端口后因为 NAT 限制无法建联而放弃连接 2.Q:tracker 是否传输种子内的文件数据?无 tracker 是否可以获取种子内容? A:不传输,可以获取。tracker 只是一个通讯录,任何 peer 访问 tracker 拿到的都是此种子的其他 peer 的 List,并不做数据的转发。至于通讯录里的电话你能拨通几个就看你本事了。无 tracker 可以通过手动建联或 DHT 及本地发现等方式进行传输,其中用的最多的是 DHT ,具体可以搜索 DHT 实现方式,本质可以理解为每个客户端存了一部分的通讯录副本。 3.Q:都没有公网或都不是 FC 的 NAT 的话,国内用户怎么办? A:首先目前大部分的种子资源依然是依托于放流者及分流者进行传播的,大部分下载者并不会长时间的留存并做种。种子的完整内容在放流者及分流者处,而这两个角色通常来说是极大概率有公网 ip 的。这意味着通常情况下,下载只需要你连接到了这两个角色就可以,无论你处于什么样的网络环境,对外建连应该都不存在太大问题 |
27
lcy630409 2023-10-10 17:24:18 +08:00
op 估计想错了一件事
几千用户并不多,他的重复资源不多 当然 校园网是 有可能的,不过校园 pt 在目前大宽带的发展下 下载速度这一优势变得不存在了,文件稀有性成为了 pt 存活的意义 |
28
lcy630409 2023-10-10 17:27:19 +08:00
3 、然后用户 b 获取从 tracker 服务器获取用户 a 的 ip 信息, 然后用户 b 向 a 发送数据包,这样数据就不用通过 tracker 服务器中转,节省 tracker 服务器带宽
本来就是这样的,bt 下载的难点一直都是节点之间能否互相联系上,tracker 服务器就只是一个通讯录的作用 |
29
opengg 2023-10-10 19:34:06 +08:00 via Android
bt 不解决 nat 穿透问题,所以人们才发明了 natmap
|
30
qingshengwen 2023-10-11 16:35:31 +08:00
@AoEiuV020JP #3 好特么精辟
|
31
qbqbqbqb 2023-10-11 23:25:28 +08:00
@bler qbittorrent 很早就支持打洞了,而且对打洞的支持相当完善,不仅支持 ipv4 NAT 打洞,也支持 ipv6 防火墙打洞(路由器上不必设置允许 ipv6 传入连接)。
反而是比特彗星非常晚才支持,比特彗星 2021 年的某个版本才开始支持打洞。 不支持打洞的是 transmission 这个客户端,虽然和 qb 一样用的是 libutp 后端,但是它就是没有实现打洞功能。 |
32
qbqbqbqb 2023-10-11 23:29:29 +08:00
@opengg BT 不解决 NAT 穿透是什么猴年马月的事情了。现在的基于 UDP 的 BT 协议 uTP 是带有一个用于打洞的扩展特性 ut_holepunch ,都已经写入 BT 官方标准了。
https://www.bittorrent.org/beps/bep_0055.html |
33
yoghurtguy 2023-10-16 01:51:55 +08:00
@qbqbqbqb 大佬,我一直没搞懂,教育 pt 之间是咋传输,学校明明有防火墙,不是同一学校的怎么传输的啊?也是靠的打洞吗?
|