建议添加内置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层数提供支持 调用系统的路由追踪命令应该就足够了