bittorrent bep29协议规范中基于UDP传输的UTP协议能否对BT下载进行NAT1(Full Cone)打洞透传，bep55
bittorrent bep29协议规范中基于UDP传输的UTP协议能否对BT下载进行NAT1(Full Cone)打洞透传，bep55有utp没公网也一样，utp是为了打洞
别神话utp，utp本身就不支持透传，这个协议开发是为了突破qos
没想到现在因为utp是基于udp传输得，甚至还被qos得更严重
bt又没服务器，谁给你打洞，打洞的前提是有一台中转服务器，不如没办法打开udp端口
两个内网，可以打洞，只需要一台外网服务器作为辅助，也就是tracker udp
那是绝对无法连上的，因为不存在中间服务器，而且tracker又不负责打洞，utp就没打洞功能，自己看BT协议规范官网
两个电信内网，一个udp tracketr就可以打洞
https://www.bittorrent.org/beps/bep_0000.html
https://www.bittorrent.org/beps/bep_0029.html
bep29协议开发规范，自己看看
这就是utp的开发目的
如果是用来打洞，不需要服务器转发，但是需要服务器来打开端口，然后把打开的端口给对方
对方就可以用这个透传端口进行传输
打开端口upnp就可以，不信没办法，我内网一样做种，全是utp
BT协议就没这个打洞功能，你当是pcdn啊，是不是迅雷玩客云挖矿挖多了，以为BT内网也可以透传
你内网上传那肯定可以啊，你自己检测下你上传的对方是不是都是公网ip，扫一下端口你就知道了，tcp全开的纯公网
只是你客户端优先用了utp，主动连接到他公网ip客户端的开放udp端口上
有速度的都是utp
UTP的目的，就是为了解决TCP拥塞的问题，至于为什么有速度是utp，我上面说了，你的客户端默认优先以utp发起连接
而不是所谓的透传打洞，但是UTP在国内，基本是掐掉的，运营商特别讨厌UDP流量，因为可能涉及到DDOS攻击，大部分场景，效果不如TCP
这个，你又不懂了，udp攻击是有条件的，比如你发送10个包，对方一个没回，就屏蔽了，因为你没有形成正常的数据交互，而非你说的直接屏蔽
我用境外机器搭建v2 kcp，被服务商停机了说我玩ddos，去年的事了，我发了工单，服务商给我开机了，那是因为kcp发包比例超过正常比例范围
所以说了，，不止是中国，在世界任何一个地方，都是非常不欢迎UDP传输的
当然，有一种方式可以进行打洞，这已经不属于UTP协议规范的问题了，属于UDP传输底层二次开发
前提需要NAT1(Full Cone)，但是需要BT客户端去开发并且支持，并且两边采用一样支持打洞的客户端才可以实现打洞透传
自己为A，通过NAT环境连接到一个对方为公网IP的客户端C，此时NAT会打开一个端口，然后此时任何通过此UDP端口访问A的数据都可以到达A
例如 A:192.168.1.100 NAT:202.100.100.100 C:292.88.88.88
A(192.168.1.100:6666) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)
任何发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.1.100:6666)
并且此时必须BT客户端一定要使用了服务器数据库，进行记录了NAT(202.100.100.100:8000) 的IP地址，发送给其它下载者D,E,F，即可实现UDP打洞透传。
市面上的tracker均不负责做上述操作，当然可以对BT客户端开发，实现免服务器的本地用户列表交换，和C成功打通NAT后，C客户端会记录并且标注NAT通过PEX协议传输给D,E,F也可以实现（传输进行标识符为NAT，此时D,E,F客户端应该以UDP传输发起到A）。
这么说你理解了吗
包括bep55打洞原理，例如文中提到的中继对等方是否就是服务器来记录
https://www.bittorrent.org/beps/bep_0055.html
{:124:}
页:
[1]