mieru
mieru copied to clipboard
enfein
关于udp模式引入bbr提升速度？
目前tcp速度比udp快主要是因为有bbr的加持，不知能否在udp模式中也引入bbr以提升网速？
目前测试下来同样使用udp的tuic，用了bbr，速度比纯udp快很多。
相关参考： https://github.com/EAimTY/tuic/issues/82 https://github.com/XTLS/Xray-core/issues/975#issuecomment-1182579967
BBR 肯定会做的，现在 UDP 代理协议的速度太慢了。
我对 clash meta 不熟。VPN 软件如果可以直接连 socks5 代理，就不需要什么额外的支持了，例如 netch 就可以直接配合 mieru 使用。如果 VPN 软件没有办法接 socks5 后端，才需要通过插件等方式支持其他的翻墙协议吧。关于这方面，能否提供更多关于 clash meta 的信息？
今天部署了一下，速度和稳定性应该没问题。就是不支持full cone NAT吗。打不了游戏呀
看udp数据包的结构没有包含地址信息，应该不支持full cone
@longxx mieru 不支持 full cone NAT
当初设计协议的时候，着重考虑了安全性和防探测。个人认为支持 full cone NAT 会损害代理服务器的隐匿性。
@moranno 根据现在 CPU profile 数据来看，基于 KCP 协议的 UDP ARQ 实现，即便使用 BBR 拥堵算法，在理论速度上也不太可能超过 TCP，但是当丢包比较多的时候，BBR 可能会有优势。我的想法是，先做一个 benchmark 合理评估当前 TCP 和 UDP 在各种丢包场景下的速度，然后再实现 BBR，看看 BBR 对速度的提升有多大。这个项目如果不出意外会在 1.10 版本完成。
经过一番实验，最终选取了 CUBIC 协议作为 UDP 传输的拥塞控制算法。没有选择 BBR 的主要原因是，BBR 使用 RTT 作为主要的输入参数，而 mieru 中 UDP 的数据包是通过间歇性轮询来处理的，这个间歇性轮询的时间间隔对 RTT 有显著的影响，导致 BBR 始终无法处于稳态。相比之下，使用系统中断来处理的 TCP 包有比较稳定的 RTT，因此 BBR 算法可以优化得出 RTT 乘以带宽的最大值。
在现代拥塞控制算法中，CUBIC 是实现极为简单，且不依赖 RTT 的算法。在实验环境中，使用 CUBIC 的 UDP 传输极限速率可以做到 TCP 的一半（瓶颈是 CPU 不是带宽），在移动网络等丢包严重的恶劣工况下，UDP 可以通过较多的重发获得比 TCP 更快的速度。
不懂代码，看本项目是go语言，meta也是go，应该好移植吧？ https://t.me/MetaKernel 这是meta群的链接，挺活跃的，进群问问，看其他人有没有想法，之前刚添加了tuic。
