有人能说说种子下载的原理吗,尤其是国内这种好几千个用户共用一个公网 ip 的情况,用户都处于私有网络,互相不能直接连通这种复杂网络背景下 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
bler
V2EX    宽带症候群

有人能说说种子下载的原理吗,尤其是国内这种好几千个用户共用一个公网 ip 的情况,用户都处于私有网络,互相不能直接连通这种复杂网络背景下

  •  1
     
  •   bler 2023-10-10 11:40:07 +08:00 5005 次点击
    这是一个创建于 735 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我有一个想法,udp 不是无需建立连接就能发送数据包吗,有如下一个场景

    1 、有一个 tracker 服务器

    2 、用户 a

    3 、用户 b

    1 、用户 向 tracker 服务器发送 udp 数据包

    2 、tracker 服务器接收到 udp 数据包后通知用户 b (由于 b 处于内网环境,用户 b 向 tracker 服务器主动获取通知)

    3 、然后用户 b 获取从 tracker 服务器获取用户 a 的 ip 信息, 然后用户 b 向 a 发送数据包,这样数据就不用通过 tracker 服务器中转,节省 tracker 服务器带宽

    有没有计算机网络的大佬能不能说一下这个方案的可行性怎么样

    33 条回复    2023-10-16 01:51:55 +08:00
    titanium98118
        1
    titanium98118  
       2023-10-10 11:47:09 +08:00
    我印象中 BT tracker 只交换 peer 信息,不做数据中转?
    smilekung
        2
    smilekung  
       2023-10-10 11:48:01 +08:00
    这不就是 udp 打洞么,如果双方都没有公网是很难成功的,因为 tracker 拿到的是 nat 地址,直连是不一定能打通的
    AoEiuV020JP
        3
    AoEiuV020JP  
       2023-10-10 12:12:09 +08:00   13
    思而不学则殆
    NoOneNoBody
        4
    NoOneNoBody  
       2023-10-10 12:17:43 +08:00
    tracker 只是个“临时通讯录”
    tracker 的压力是请求数量巨大,不是传送数量
    luny
        5
    luny  
       2023-10-10 12:22:53 +08:00
    1. 内网用户可以通过 trakcer 获取 peer 节点信息,主动连接,外网用户可以被动连接,速度会更好
    2. 有个 DHT 的技术,现在客户端都支持,可以不需要 tracker 服务器,实现 peer 获取
    nothingistrue
        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 连接的。
    Maboroshii
        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 (对称型)
    iOCZ
        8
    iOCZ  
       2023-10-10 12:57:51 +08:00
    存在无法连上其他 peer 的可能性的
    bler
        9
    bler  
    OP
       2023-10-10 13:10:06 +08:00
    @nothingistrue 我知道 udp 不需要回复确认,但是 a,b 都处于内网之中,b 向 a 无法直接发送数据啊。还有 a,b 用户通过公网建立 tcp 连接,b 向 a 发送数据不一样要占公网服务器的带宽吗。
    bler
        10
    bler  
    OP
       2023-10-10 13:13:59 +08:00
    @titanium98118 那我们下载的数据从哪来的,总得要有一个公网做 a 和 b 数据转发吧, 那同样要占用这个公网服务器的带宽了,这个公网服务器是由谁提供的呢
    bler
        11
    bler  
    OP
       2023-10-10 13:25:59 +08:00
    能哪位大佬能出个 a,b 两个内网用户交互种子资源的网络拓扑图吗,主要是数据的流向,怎样流动的,我想知道各方的带宽占用情况,这个 p2p 到底是怎么个数据流向,尤其是国内这种都处于内网的情况下
    MacTavish123
        12
    MacTavish123  
       2023-10-10 13:27:49 +08:00 via Android   2
    一个被封杀的账号几年前做的科普视频,
    ?si=7hmgM0WEhavAwVr9
    titanium98118
        13
    titanium98118  
       2023-10-10 13:33:37 +08:00
    @bler #10 那我们下载的数据从哪来的:1 、由下载完成的用户上传,即种子。2 、正在下载中的用户上传已有的部分
    expy
        14
    expy  
       2023-10-10 13:37:33 +08:00
    两个内网用户基本连不上,不过现在 ipv6 基本普及了,大家都是公网。
    bler
        15
    bler  
    OP
       2023-10-10 13:39:17 +08:00
    @xiaozecn 谢谢,我的主要目的还是想知道,在 a,b 两个用户处于内网( nat )网络环境下,有没有方案实现不依托于公网服务器交换数据,公网服务器只交换两者的地址,然后两者自己进行数据交互,这样能不占用公网的带宽流量。所以我才有上面的一个设想场景,a 内网发送请求,tracker(或者是其他中转服务器)完成对 b 的网络交互通知,然后 b 发送数据给 a ,而不是 b 把数据给 tracker(或者是其他中转服务器),然后再发送给 a
    wy315700
        16
    wy315700  
       2023-10-10 13:39:58 +08:00
    a,b 两个内网用户基本上是连不上的

    这个时候就需要一个公网用户 c ,a 和 b 从 c 下载东西。


    OP 以前没玩过电驴吧,电驴会根据其他用户能否连上你的端口给你分 high ID 还是 low ID 的。
    asdgsdg98
        17
    asdgsdg98  
       2023-10-10 13:44:35 +08:00
    你是全锥形,就可以随意下载和上传,理论上能访问任何资源
    你是对称型的话,基本告别 bt 了
    TNOK
        18
    TNOK  
       2023-10-10 13:45:30 +08:00
    @bler BT 现在就是这么实现的呀,没有中转的,tracker 就是为了让 a 和 b 建立连接不干别的,就算是内网,如果打洞成功也是可以将 a 和 b 连接起来的,你说的那种纯大内网右下角会显示不通并且没有速度的
    bler
        19
    bler  
    OP
       2023-10-10 13:50:03 +08:00
    找个一个讲的比较好的文章,感兴趣的可以看看: https://www.h3c.com/cn/d_201206/922130_30005_0.htm
    UXha45veSNpWCwZR
        20
    UXha45veSNpWCwZR  
       2023-10-10 14:09:02 +08:00
    tracker 服务器是通讯录.存有 A 和 B 的 ip,上传和下载不通过 tracker 服务器.是 A 和 B 之间相互传文件.
    Gawainnnn
        21
    Gawainnnn  
       2023-10-10 14:50:23 +08:00
    BT 数据从来都不过 tracker ,tracker 只是存的用户信息,让互联网瞎子用户 A 用户 B 知道对方的存在,建立连接是用户自己的事
    nothingistrue
        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 下载的表现上是:如果你在内网,那么能看到很多主机,但是只能连接其中在公网上的;如果你在公网,那么你看到多少主机就能连接到多少主机。这个在非服务器建主的对战游戏中也有表现:如果你在内网,那么你只能进别人的主机,你建的主机别人进不了。
    bler
        23
    bler  
    OP
       2023-10-10 15:14:56 +08:00
    @nothingistrue 谢谢老哥了,已经有点搞明白这个了, @smilekung 这个老哥说的对,我描述的场景其实就是 udp 打洞的场景,这篇文章 https://www.h3c.com/cn/d_201206/922130_30005_0.htm 还介绍了 tcp 打洞的场景,还有很多关于 nat 方面的东西
    jsq2627
        24
    jsq2627  
       2023-10-10 15:53:15 +08:00 via iPhone
    BT 下载并没有引入复杂的 NAT 穿透技术,如果两个 peer 之间不能直通,就放弃传输了,也不会有服务器中转

    作为对比,在同为 P2P 的 WebRTC 等音视频应用里,就会各种尝试 UDP 打洞,如果最终还是不能直连,还有服务器能中转流量保证正常通话。
    bler
        25
    bler  
    OP
       2023-10-10 16:15:49 +08:00   1
    参考一下各位老哥的回复以及看的一些文章总结一下:

    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 下载数据了,没有这种复杂数据中转场景。
    KorenKrita
        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 的。这意味着通常情况下,下载只需要你连接到了这两个角色就可以,无论你处于什么样的网络环境,对外建连应该都不存在太大问题
    lcy630409
        27
    lcy630409  
       2023-10-10 17:24:18 +08:00
    op 估计想错了一件事
    几千用户并不多,他的重复资源不多

    当然 校园网是 有可能的,不过校园 pt 在目前大宽带的发展下 下载速度这一优势变得不存在了,文件稀有性成为了 pt 存活的意义
    lcy630409
        28
    lcy630409  
       2023-10-10 17:27:19 +08:00
    3 、然后用户 b 获取从 tracker 服务器获取用户 a 的 ip 信息, 然后用户 b 向 a 发送数据包,这样数据就不用通过 tracker 服务器中转,节省 tracker 服务器带宽

    本来就是这样的,bt 下载的难点一直都是节点之间能否互相联系上,tracker 服务器就只是一个通讯录的作用
    opengg
        29
    opengg  
       2023-10-10 19:34:06 +08:00 via Android
    bt 不解决 nat 穿透问题,所以人们才发明了 natmap
    qingshengwen
        30
    qingshengwen  
       2023-10-11 16:35:31 +08:00
    @AoEiuV020JP #3 好特么精辟
    qbqbqbqb
        31
    qbqbqbqb  
       2023-10-11 23:25:28 +08:00
    @bler qbittorrent 很早就支持打洞了,而且对打洞的支持相当完善,不仅支持 ipv4 NAT 打洞,也支持 ipv6 防火墙打洞(路由器上不必设置允许 ipv6 传入连接)。

    反而是比特彗星非常晚才支持,比特彗星 2021 年的某个版本才开始支持打洞。

    不支持打洞的是 transmission 这个客户端,虽然和 qb 一样用的是 libutp 后端,但是它就是没有实现打洞功能。
    qbqbqbqb
        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
    yoghurtguy
        33
    yoghurtguy  
       2023-10-16 01:51:55 +08:00
    @qbqbqbqb 大佬,我一直没搞懂,教育 pt 之间是咋传输,学校明明有防火墙,不是同一学校的怎么传输的啊?也是靠的打洞吗?
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     3719 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 27ms UTC 10:27 PVG 18:27 LAX 03:27 JFK 06:27
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86