1.78测试版

hz6615997184904 · 2021年07月23日12:15

电信级NAT基本上不可能，但很多路由器会尽量映射相同端口。前提是连接数较少不会造成冲突，且路由器出去后不会被运营商再NAT一次。
符合这种情况的是路由器有公网但用户没有配置权限，同时无法使用UPnP。比如出租屋，小公司，甚至是使用隧道协议的情况。
还有就是IPv6不使用NAT，但用户无法修改防火墙的情况。这时候BEP 55就能实现“防火墙打洞”。
这类用户不多，但也存在一定数。比如小米路由器修改IPv6防火墙的门槛很高，而光猫拨号则可能需要超管账号。

zhuxiaoying85309 · 2021年07月23日13:54

等官方看看怎么改代码能不能做出来吧。。

hz6615997184904 · 2021年07月24日07:52

个人认为，在去中心化的前提下，BEP 55已经没有改进的余地。
而目前阻碍我们期待的NAT打洞的，在于PEX不交换NAPT后的外部端口。结果只能实现上述的“防火墙打洞”和不转换端口的“非NAPT打洞”。

针对这一点，我建议对PEX机制作出以下更改：

替换PEX节点信息中的端口
仅对uTP连接，在其实际连接的端口与声称的监听端口不一致的情况下，把节点信息替换为NAPT后的外部端口

首先排除TCP连接，因其无法提供打洞所需的信息，也无法保证UDP的可连接性。这时，内网节点想打洞，就必须在客户端中设置优先发起uTP连接。
可选忽略IPv6，因使用NAPT6的情况极少。但如果会增加额外的处理，应跳过此判断。
替换方法可以是1.先判断端口差异再替换，或2.直接参照远程端口。直觉上2.的处理负荷较低，但如果需要判断节点是否存在NAPT，应选择1.

更改PEX候选节点的逻辑
优先选择uTP连接的节点作为交换的候选

目前PEX的作用不大，因其交换的节点多与Tracker或DHT重复而被抛弃，且TCP节点无法保证可连接性。PEX优先选择uTP节点，并不会降低其有用性，但能提高打洞的效率。当uTP连接的节点数低于阈值时，TCP连接的节点仍可以加入到候选列表。
可选判断是否是需要打洞。这与上面提及的替换方法有关，当使用方法1.并记录节点存在NAPT后，可将其优先级提高。但前面回复也提到，“防火墙及非NAPT打洞”也存在一定的需要，调整优先级可能不公平。另外，可在PEX报文中为这一属性新增标志位，但需求可能不大，而且要对BEP 11提出修订。

更改PEX来源与Tracker、DHT来源重复时的优先级

BEP 11的安全注意事项中提到以下内容

Data exchanged via PEX messages should be considered untrusted and potentially malicious.
通过 PEX 消息交换的数据应被视为不受信任且可能是恶意的

Duplicate IP addresses (e.g. with different ports) should be ignored.
应忽略重复的 IP 地址（例如，具有不同端口）

这显然对NAPT打洞不友好，甚至上述的“防火墙及非NAPT打洞”也会受到影响。为此，应提高PEX来源节点在IP重复时的优先级，如有新增的标志位，也可以在此作为判断依据。
对于潜在的安全问题，可能需要其他机制来解决。但至少优先级要高于DHT，因其已经被严重污染。

以下方案通过手动获取外部端口、手动发起uTP连接来验证BEP 55的uTP打洞的可行性
** 碍于设备条件，我未能独自完成测试

所需设备：
公网节点S，需要监听且开放UDP端口，并启用uTP
内网节点A、B：需要启用uTP连接，由于手动发起，是否优先不重要
内网节点的NAT类型如下表
只要是可穿透的组合，均可完成测试

测试方法：
1.先制作测试种子，勾选私有种子并使用不存在的Tracker，确保连接只能通过手动发起
2.[内网节点A]和[内网节点B]向[公网节点S]直接发起uTP连接
3.建立连接后，在[公网节点S]的客户端上能看到[内网节点A]和[内网节点B]的NAPT后的[IP:PORT]
4.[内网节点A]和[内网节点B]同时用NAPT后的[IP:PORT]互相发起直接的uTP连接
** “同时”一般指25秒内；在这时间内大多数防火墙不会回收端口
** 所有连接均为uTP且直接发起（不经过“UDP 打孔”，此测试不依赖PEX）

如无意外，结果应该是下列这样
NAT1:NAT1 ：
双方无论先后，均可一次发起便建立连接
NAT1:NAT2 / NAT1:NAT3 / NAT1:NAT4 ：
当先发连接的目标端点是NAT1时，可直接建立连接
当先发连接的目标端点是NAT2/NAT3/NAT4时，先发连接会被防火墙阻挡；但后发连接的目标端点为NAT1，连接可建立

NAT2:NAT2 / NAT2:NAT3 / NAT3:NAT3 ：
所有先发连接均会被目标端点的防火墙阻挡，但会在自己的防火墙上留下与目标端点的通信记录
在后发连接发起时，防火墙会根据这条通信记录放行，连接可建立

NAT2:NAT4 ：
先发连接必须是由NAT2向NAT4发起，此时NAT2的防火墙会为NAT4的IP留下通信记录
后发连接由NAT4使用新的外部端口发起，由于IP一致，NAT2的防火墙会为其放行，连接可建立

NAT3:NAT4 ：
由于NAT4会使用新的外部端口发起连接，而NAT3的防火墙需要通信记录中的[IP:PORT]都一致才允许放行，连接无法建立

NAT4:NAT4 ：
由于NAT4非Cone NAT，即使同一内部端口的连接也会被映射为不同的外部端口，因此无法找到互相的主机，更别说通过防火墙；连接无法建立

zhuxiaoying85309 · 2021年07月24日10:53

楼上说的这些官方开发应该都知道，，，就是不知道代码要如何写来支持吧。。。大概是这种情况，需要时间来进行开发
不知道楼上会不会英文，，，会的话来这里让libtorrent试着更进一下支持？然后开发者就可以cory代码来支持了？

github.com/arvidn/libtorrent

libtorrent有无考虑开发一下基于UTP的UDP NAT1打洞

opened 11:06AM - 23 Jul 21 UTC

1265578519

libtorrent有无考虑开发一下基于UTP的UDP NAT1打洞比特彗星那边也在做了，不过开发进度有点慢，，而且做出来的效果不尽人意，还在等待后续更…新 https://www.cometbbs.com/t/178%E6%B5%8B%E8%AF%95%E7%89%88/59260 以前我也测过utorrent，是根本无法NAT打洞的。。。包括 qBittorrent 也不行，可能开发者都搞错了，现在市面上所有的BT软件，，基本都是需要对方为外部网络，TCP端口开放，然后通过升级到UTP传输而已，而不是打洞这就是我上面说的，其实目前市面上没有任何一款软件做了打洞，单纯的只是升级为同端口的udp传输而已。比特彗星那边正在实行的就是基于BEP55来实现PEX报文传递的是客户端的监听端口，这种打洞是没有意义的测试NAT1打洞需要至少3台设备，测试环境如下做种服务器A 防火墙开放TCP端口，做种客户端设置为UTP启用下载服务器B B服务器在路由器中封堵TCP端口，NAT值为1 一样设置为UTP启用，执行下载，此时服务器A可以看到一个来源为被动的服务器B请求。下载服务器C C服务器在路由器中封堵TCP端口，NAT值为4 设置UTP启用，执行下载，测试是否与服务器B连接成功服务器A和服务器B可为公网IP的云VPS，服务器B在系统防火墙高级设置封堵TCP入站即可，服务器C可为家中电脑设备顺便吐槽一下，，qBittorrent 这么多年了，单线程传输速率还是这么烂，5MB/S极限了，比特彗星可以跑到80MB/S https://www.youtube.com/watch?v=pO_nIMSKWd8 **translate** Is libtorrent considering developing UTP-based UDP NAT1 hole punching? Bit Comet is also doing it there, but the development progress is a bit slow, and the results are not satisfactory, and we are still waiting for follow-up updates. https://www.cometbbs.com/t/178%E6%B5%8B%E8%AF%95%E7%89%88/59260 I have tested utorrent before, and it is impossible to make NAT holes at all. . . Including qBittorrent also does not work, maybe the developers are mistaken, all BT software on the market now basically requires the other party to be an external network, open the TCP port, and then upgrade to UTP for transmission, instead of making holes This is what I said above. Actually, there is not any software on the market that does hole punching. It is simply upgraded to udp transmission on the same port. What Bit Comet is implementing is based on BEP55 to realize the PEX message transmission is the listening port of the client. This kind of hole punching is meaningless. At least 3 devices are required to test NAT1 hole punching. The test environment is as follows Seed server A The firewall opens the TCP port, and the client is set to UTP to enable Download server B Server B blocks the TCP port in the router, and the NAT value is 1 The same is set to enable UTP, and download is performed. At this time, server A can see a request from server B whose source is passive. Download server C Server C blocks the TCP port in the router, and the NAT value is 4 Set UTP to enable, execute download, and test whether the connection with server B is successful Server A and Server B can be cloud VPS with public IP, server B can block TCP inbound in the advanced settings of the system firewall, and server C can be a home computer device By the way, qBittorrent has been around for so many years, the single-threaded transmission rate is still so bad, 5MB/S is the limit, BitComet can run to 80MB/S https://www.youtube.com/watch?v=pO_nIMSKWd8

hz6615997184904 · 2021年07月24日14:12

我在您发的libtorrent源码中，发现其PEX源码中有进行端口替换的操作。
在未连接的情况下使用其声称的端口，若已连接则使用实际端口。

github.com

arvidn/libtorrent/blob/95afba30e9acfd8411076a0b05f7ca69bf33b9bb/src/ut_pex.cpp#L154

    
      
          				{
          					// don't write too big of a package
          					if (num_added >= max_peer_entries) break;
          
          
					// only send proper bittorrent peers
          					if (peer->type() != connection_type::bittorrent)
          						continue;
          
          
					auto const* const p = static_cast<bt_peer_connection const*>(peer);
          
          
					// if the peer has told us which port its listening on,
          					// use that port. But only if we didn't connect to the peer.
          					// if we connected to it, use the port we know works
          					if (!p->is_outgoing())
          					{
          						torrent_peer const* const pi = peer->peer_info_struct();
          						if (pi != nullptr && pi->port > 0)
          							remote.port(pi->port);
          					}
          
          
					// no supported flags to set yet

然后在下面有判断uTP连接，是否支持打洞的部分。
这里有涉及tcp::endpoint，但我也不太懂这段代码的意思。

github.com

arvidn/libtorrent/blob/95afba30e9acfd8411076a0b05f7ca69bf33b9bb/src/ut_pex.cpp#L547

    
      
          				//        passing 0 doesn't mean the peer doesn't
          				//        support uTP
          				// 0x08 - supports hole punching protocol. If this
          				//        flag is received from a peer, it can be
          				//        used as a rendezvous point in case direct
          				//        connections to the peer fail
          				int flags = p->is_seed() ? 2 : 0;
          #if !defined TORRENT_DISABLE_ENCRYPTION
          				flags |= p->supports_encryption() ? 1 : 0;
          #endif
          				flags |= is_utp(p->get_socket()) ? 4 :  0;
          				flags |= p->supports_holepunch() ? 8 : 0;
          
          
				tcp::endpoint remote = peer->remote();
          
          
				if (!p->is_outgoing())
          				{
          					torrent_peer const* const pi = peer->peer_info_struct();
          					if (pi != nullptr && pi->port > 0)
          						remote.port(pi->port);
          				}

通过在PEX消息生成过程中改端口并扩散，NAT1主机可被其他主机直接连接。
但除此之外并没有在libtorrent中搜到与打洞相关的代码，估计并不存在协助打洞的操作。
另外上面提到的PEX来源优先级的问题也没有解决，即使替换了端口，也很大概率由于重复而被丢弃。
因此判断libtorrent目前对打洞的支持非常有限。

我需要配合翻译器才能阅读文档，并不擅长英文写作，也不太会阅读代码。
我会继续关注，如有足够的信息，也会尝试跟进。

zhuxiaoying85309 · 2021年07月24日15:36

嗯，那估计libtorrent的代码有BUG，，至少我在qbittorrent上测试也不能打洞

gaol7325 · 2021年07月25日07:54

谢谢楼主和开发者

etxxx3985 · 2021年07月27日12:38

uTP 是否還有優化可能, 怎感覺沒有速度…?

yugf6690274 · 2021年07月27日12:41

能否介意将数据库压缩分享出来呢，我这边网路不会，链接效率很低。如果能分享，无疑是令人兴奋的。

zhuxiaoying85309 · 2021年07月27日12:50

把UTP改成自动检测，不要用优先或者强制，有BUG，我上面反映过，要等下个版本更新，开了优先或者强制，则永远无法连接PEER

etxxx3985 · 2021年07月27日13:00

已開自動… 用戶也顯示 uTP 已啟用, 代表已跟 peer 連接, 且透過 uTP 協議, 但是沒有速度…

zhuxiaoying85309 · 2021年07月27日13:01

现在版本还做不到NAT1打洞，等下一个测试版完善吧。。

etxxx3985 · 2021年07月27日13:03

嗯, 另外請教一下, 窒息是什意思?

zhuxiaoying85309 · 2021年07月27日13:15

比特彗星用户列表的状态是什么意思，标志符号，分辨标识
D-现在从同行下载数据
U-现在从同行上传数据
d-我从对等方请求数据，想从对等方下载（对等方有我需要的数据）
u-peer请求我的数据，要求我上传（我有同行需要的数据）

在后面的版本中，替换为符号：{I，i，C，c，_}。请参阅此处对这些符号的不同组合的所有状态含义的完整描述。

http://wiki.bitcomet.com/connection_status

状态：连接的状态。【I–本地需要下载对方数据；c–对方不给本地上传数据；i–对方需要本地上传数据； C–本地不给对方下载数据】

Capital案例意味着您向对等方发送状态消息。小写表示对等方向您发送状态消息。C或c表示已CHOKED … CHOKED的发件人暂时未对请求开放。相反的状态是UNCHOKED。我或我的意思是有趣的…有兴趣的发送者注意到它的同伴有一个它目前需要的部分。相反的状态是UNINTERESTED。
Capital case means you sending a status message to the peer. Lower case means peer sending a status message to you. C or c means CHOKED … the sender of CHOKED is temporarily not open for requests. The opposite status is UNCHOKED. I or i means INTERESTED … the sender of INTERESTED has noticed that its peer has a piece that it currently needs. The opposite status is UNINTERESTED.

你图中窒息应该是阻塞的意思

wxhere15 · 2021年07月27日13:29

1.78正式版打包了。下一版会继续优化UDP打洞功能及uTP传输能力。

zhuxiaoying85309 · 2021年07月27日13:31

不知道UTP选项的BUG修了没。。能不能连上PEER了，晚上测一下

wxhere15 · 2021年07月27日13:46

目前打洞算法还不完善，您可以试一试端口开放的情况下把 bittorrent.utp_after_holepunch 关闭，不打洞直接尝试uTP连接。

zhuxiaoying85309 · 2021年07月27日16:57

ui.copy_magnet_with_tracker 选项对RSS种子市场不起效果

zhuxiaoying85309 · 2021年07月27日20:27

测试了关闭bittorrent.utp_after_holepunch 的情况下，UTP选项设置为优先和强制可以正常连接上PEER了，NAT1打洞看来要以后的版本在完善了，，

zhuxiaoying85309 · 2021年07月27日20:33

运营商干扰UDP传输了吧，要加密才行。我试了下移动宽带会被QOS