目前网页访问和APP访问的开关是平行关系。如果把网页访问的开关提到上面，那就感觉变成从属关系了。要么就把两个设置项合并？不再单独控制网页访问和APP访问
其实分组框和灰化条件已经可以做出区分了
之所以要把开关提到上面是因为 默认情况下
网页访问时没有启用的 这导致webUI监听端口是灰化的
而其又是第一行的选项 想要解锁监听端口就必须往下找
先经过手机APP选项才能看到启用网页访问的选项
我的建议是逐层解锁 上级开关解锁下级内容
和其他的选项的逻辑相同 而现在是下级开关解锁上级内容
逻辑显得有些不一致
刚刚重新拉取更新docker镜像后，statistics和统计里面能正常显示出来了
对，，本地依旧复现有问题，是不是Windows的也打包错版本了
多次测试，看起来是第二个线程跳转到download4才能正常多线程，如果第二个线程是download1，那么就会只有2个线程工作，第三个线程就空白没有发起了
新的考古发现
BC早在0.56版本就开始尝试使用UDP穿透NAT以进行传输 即2004.8.21
其在更新日志中被描述为 “内网互联模块”
在比特彗星的英文wiki中有详细的描述：链接
但这以功能在v1.03被移除 即2008.7.17
在更新日志上显示为 “删除内网互连模块，提高TCP传输效率”
在不到一年后的2009 年 6 月 22 日 utp传输协议开始起草（BEP29）
用于记录BEP协议的 bittorrent org 网站好像无法访问了？
不知道 是什么情况 目前只能看网页时光机的快照了
或者github上的这个存储库： 链接
然而直到现在 也只有比特彗星成功nat1，其他bt软件的utp都需要公网ip 无法穿过nat收到远程连入
楼上那人内存看起来是很正常的，如果觉得占用过高可以看一下统计里是什么占用内存
下一版有望支持系统缓存给用户选项是否开启，当然更推荐进程缓存，敏感需求用户就打开系统缓存
可以按照此教程中的方法进行排查：链接
然而由于传输效率问题其在实际依然是不可用的
就像当年被移除时那样 传输效率始终是个问题
就看之后能不能修好CPU占用的问题了
@rbowy75e UDP缓冲区过大
按照小白使用软件的体验，逻辑是根据自身硬件条件设置允许的缓冲区最大值，其他数值自动根据缓冲区自动调整。
你说的很有道理，但是我没看懂。 
通配符的实现进展如何了？
IP过滤列表中的灰化条件似乎还存在一些问题
当禁用IP过滤总开关时 除清除过滤器按钮外其他组件应全部灰化
但目前仅手动过滤器和导入导出按钮灰化
除此之外 当禁用IP规则订阅时 与之有关的选项应灰化
但目前还不会
建议添加内置STUN穿透功能
添加内置STUN功能的必要性
在过去我们已经实现了多种外置的STUN穿透方法
使得在全锥型NAT后面的设备可以通过STUN穿透开放一个TCP端口
其与“公网”基本等效
尽管使用UTP和UDP打孔可以实现类似的效果 但其使用UDP进行传输
从实际观察来看UDP传输在复杂的网络环境下其实并没有TCP的效果好
而且BC目前的UTP功能尚不完善
除此之外还有兼容性问题 尽管现在libtorrent系客户端占主导地位 其都支持UTP
但并非所有客户端都支持UTP协议 不过TCP协议是无论什么客户端都是支持的
在内置STUN情况下 若条件合适其完全有可能实现自动穿透 无需人为干预
若实现内置则 BC能成为第一个支持TCP穿透的客户端
现有的外置STUN穿透方案和存在的问题
由于使用的是外置STUN穿透 即STUN程序和BT客户端不是一个程序
只能使用不同端口 从进入穿透隧道的流量会指向STU穿透程序而非BT客户端
故需要将从穿透隧道内的流量重新引导到BT客户端的端口上
而且BT下载具有特殊性 其在向tracker汇报端口的时候汇报的是本地监听端口
在一般情况下本地监听端口和实际可被访问的对外端口是相同的
但在stun穿透的情况下不是这样的了 获取到的穿透的端口是随机的
即在向tracker汇报时应汇报获取到的这个穿透端口而非 本地监听端口
目前采用的方案基本都是 需要使用额外的转发
以及修改BT客户端的本地监听端口
使其和获取到的穿透端口号相同
初代方案：
在初代方案中使用的是lucky内置的转发功能或其他具有流量转发功能的软件
使用软件转发虽然设置起来较为方便 但是软件转发效率低 大流量时CPU占用高
BT客户端无法看到对端的原始IP
二代方案：
在二代方案中使用路由设备上的端口转发功能替代 设备上的软件进行转发
解决了效率低和 客户端无法看见原始IP的问题 但是当穿透端口发生变化后需要手动修改映射规则 无法实现自动化
三代方案：
而在三代方案中使用UPNP工具向路由设备请求和修改映射 替代静态的端口映射规则
基本实现了全自动化但部分设备路由的UPNP功能存在兼容性问题
但修改客户端监听端口仍是一个问题并非所有BT客户端都提供了修改监听端口的方法
四代方案：
（此方案在一定程度上受此功能启发：链接）
与之前的方案不同的是其不需要BT客户端修改监听端口 而是通过修改
BT客户端向tracker发出的通告中的端口号 来实现的
可适用于那些未提供修改监听端口功能的客户端
但此方案实现较为复杂 需要有Linux环境并安装nftables
不适用于HTTPS tracker （载荷被加密）
目前外置方案的主要问题：
便捷性和稳定性问题
目前这些外置方案都需要一个或多个程序或脚本相互配合才能实现
设置其他非常繁琐 需要联动的程序多可靠性差
若内置STUN则可解决这些问题
由于穿透程序和BT客户端是一体的 穿透隧道指向的直接是BT客户端
无需重新引导流量
且由于内置穿透 客户端可以直接获到穿透端口即实际可被访问到的外部端口
在汇报时可以直接汇报这个穿透端口而不是本地监听端口
内置STUN实现方法的建议
具体的穿透实现方法可以参考natmap和lucky
前者为开源软件后者早期版本为开源后续版本闭源均使用MIT许可证
在可调参数方面可以主要参考lucky
包括可订阅的STUN服务器列表和图中的这些参数
除此之外建议升级现有的NAT检查工具 以支持RFC5780 现在使用的是 RFC3489
较旧的RFC3489 方法仅能探测NAT无法探测防火墙
实现方法可参考NatTypeTester其也使用MIT许可证
还建议添加路由追踪功能以方便探测NAT层数 现在大部分家庭网络都有多层NAT
可用户优化NAT层数提供支持 调用系统的路由追踪命令应该就足够了
2個讚
内置穿透的主要问题是如果进行用户空间转发，很容易丢失源 IP 地址。但是如果 BitComet 能自己完成这一点，那就可以避免源 IP 地址丢失的问题了，是个好主意。
先把UTP占用CPU和速率慢的问题修了吧，其次在考虑tcp，毕竟全球独家支持BT打洞的UTP，不修好CPU和速度慢问题说不过去。。。虽然能用但是不太好用，双方局域网传输都跑不起来速度
小草莓NatTypeTester至少目前和软件内置的NAT检测都是准确的，NAT4不会错误检测成NAT1
github上的那个NatTypeTester反而有问题，检测出来的NAT结果可能是错误的
uTP 打洞其实都是规范了：bep_0055.rst_post
libtorrent（也就是 qBittorrent 使用的）也是支持通过 PEX 启动 uTP 打洞：libtorrent打洞分析 | k1988
包括 BiglyBT 不但可以 PEX 打洞，甚至支持依靠 DHT 打洞，这样就不需要中介人了（但只有两边都是 BiglyBT 才行）。
1個讚
你实测一下，可以发现bep55基本上完全没作用，刚才也测试了BiglyBT无法建立上连接
只有比特彗星能成功，我也有发过qBittorrent无法打洞的视频演示，甚至为了结果严谨，使用了A、B、C三台设备测试
比特彗星打洞能实现A、B双方打洞，无需第三者
比特彗星的bep55反而是实测有效果的
高级设置bittorrent.utp_after_holepunch
UTP直接发起请求连接失败后，则对自身客户端已经建立TCP和UTP传输连接的所有peer发起BEP55协议请求，随后响应可用于打洞的peer
是的 如果由客户端自身完成穿透 上文中所提到的所有问题都讲不是问题
尽管有人认为在PCDN肆虐 大地区NAT类型被改为对称型 甚至IPv6被关闭的情况下
使用STUN穿透全锥型的方案已经没有用武之地了 更不用说随着IPv6的推广IPv4会逐渐退场
但这些其实都不是问题 随着时间的推移 运营商大概率被迫使用更先进的手段和方法检查和干扰PCDN
因为一刀切的负面影响非常的大 而且有些PCDN业务似乎在NAT4和无IPv6的情况下也能运行
至于IPv6的推广也不用担心 出于兼容性的考虑 IPv4网络还将存在很长时间
在v6过渡技术下NAT依然存在只不过从v4到v4地址之间的转换变成了v6和v4之间的转换
STUN 穿透仍有存在的必要
这当然是最核心的问题 但是在修复CPU占用问题之前 还是要控制DHT网络发包量
而且不能使用压制全局UDP发包的方法 这会影响到UTP的传输速率
正如前文所说的虽然libtorrent系客户端分布广泛也支持UTP但不意味着所有客户端都支持UTP
若TCP端口能开放则可以接受任意客户端的连接
不幸的是RFC5780完全没有考虑到防火墙的问题 其只适用于有NAT而无防火墙的情况
其完全无法探测防火墙及其过滤情况 且其只使用UDP进行探测不能确定TCP的处理状况
在有可能的情况下应使用全名而非NAT1-4来进行称呼 其在不同的环境下可能指代的NAT类型
比如 PlayStation 5使用 Type 1-3 进行表示
检查结果的准确性和网络状况和检测服务器有很大的关系
RFC5780 中将过滤行为与映射行为分开 同时支持TCP 甚至TLS
这样一来就可以探测出 NAT和防火墙同时存在的情况
支持TCP测试 以防止运营商对TCP和UDP采用不同的处理方法
BEP55 其实主要是针对的防火墙穿透 没有考虑端口转换的问题
尽管文件中提到了 filtering NAT 但其指的应是不进行端口转换的NAT 而非我们常说的NAT-PT
BEP55本不处理端口发现问题 需要通过PEX或者DHT来发现经过NAT-PT处理后的外部端口
用的是Azureus DHT 而非主线DHT?
如果我没记错的话 在之前的实验中 BC其实是可以通过 DHT网络发现NAT-PT处理后端口的
而libtorrent 系好像也有一些专用字段来帮助穿透
其实在穿透本身上面 BC没有什么问题 可以说是搞得不错
但是不解决DHT发包量和CPU占用问题的 UTP根本就不敢开
我们不能再用压制全局发包量和关闭DHT的方法来控制UDP发起
DHT的发包量必须要得到控制