完善utp的必要性和可能遇到的问题
通过UDP打洞可以 一定程度上解决NAT和防火墙阻挡的问题
NAT方面主要是穿透全锥形NAT 其他类型的NAT对端口号和地址有更严格的现在
我们平时所说的NAT其实是 NAT-PT 其会转换端口
也有之转换地址而不转换的端口的NAT其相对较为少见
或我们更多的称其为 防火墙
而防火墙（简单的包过滤防火墙）的穿透就比NAT-PT要容易一些
其不会转换端口 不需要在想办法确认转换后的端口了
尽管随着IPv6的推广 公网数量不足的问题得到缓解
但是防火墙的问题依然存在 而且在目前很多的网络设备对IPv6的支持依然不完善
比如缺少IPv6防火墙设置功能 有些仅有一总开关控制 不能放行单个端口
更有的完全没有办法设置
所以UDP打孔对提升客户端的连通性有很大的帮助
这使得两个未开放端口（TCP）的客户端之间的直连成为可能
不再需要通过“公网”用户间接连通 当然这需要utp
再考虑到现在的libtorrent系客户端站主导地位
其支持utp固所有使用libtorrent库的客户端应都支持utp
utp的设计应考虑对libtorrent系的兼容 或直接借鉴其实现方法
BC目前已经支持utp不过有比较严重的性能问题使得其几乎不可用
CPU占用率高而传输速度却很低
在之前的测试中即使在局域网环境先BC的utp似乎也无法正常工作
两客户端均为BC的情况下 当传输达到一达并不快速度后就会断开
过一段时间后再次连上之后再断开 重复这一过程
尽管现在utp功能默认是关闭的
但还是 建议在其完善前在其选项后面 加上“（实验性）”以防止用户意外开启
不过在修复utp性能问题前我们还面临的一个问题就是UDP发包量过多瘫痪网络问题
目前依然是靠压制全局UDP发包量来解决的
但若之后utp修复后再压制UDP发包量比必然会对utp传输造成影响
目前看来其是由 DHT网络的UDP发包过多而造成的
而我认为造成这一问题的原因是DHT节点过多
DHT节点并非越多越好 过多的节点维护开销会很大
固需要精简DHT节点数量
在和网友的研究中发现BC 的DHT的节点存在一定程度上的“重复记录”
从文档上来看 libtorrent系客户端 似乎默认会忽略跟自身CIDR相近的DHT节点
及在路由上相近的节点
出此之外 从源码上看lt似乎还会忽略同一/24网段下的节点
即一个/24段下面只记录DHT节点
而BC会对每个KID不同的节点都进行记录 即使其使用相同的地址和端口
这在远古时期不是什么问题 但在现在就显得有些不合适了
使得挂机时间越长DHT节点数越多 维护开销也越多
所以目前的建议是：
IPv4下每个地址只保留一个DHT节点 其余的将被忽略
IPv6下的情况比较复杂 个人认为每个/64 或/56 地址块下保留一个节点即可 参考：链接
当然也可以考虑实行和lt类似的忽略在路由上相近的节点以减少攻击
但不管怎么说 DHT节点的数量必须得到控制
节制DHT流量看算是修复utp的一项前置条件
除此之外我们可能呢还需要一个自动控制UTP传输量的方法
就像控制磁盘缓存那样自动调节 而不是依靠压制总发包量来实现