-
-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
有一个双边加速软件,可参考提升frp的工作性能 #99
Comments
感谢提醒,这个项目我也一直关注着。 |
看介绍牺牲带宽,提升速度,不明白什么原理,是类似每个包之间间隔时间短了么? |
单位时间发包数变多了,但并不意味着单位时间内有效信息的发送等幅增长。准确来说,对于质量不好的线路,由于丢包率较高,可能导致延迟较高、传输速率较慢(比如跨洋线路等)。这种影响可以通过双倍甚至多倍发包来纠正和弥补。因此链接质量可以很有效果的提升,即从宏观看,“速度提升了”。诚然,多倍发包占用更多的流量和带宽。 |
推荐可以看下 tcp 的拥塞控制。 我的理解是,总的来说这些控制算法的目的都是在于尽量可能的跑满带宽,降低丢包的影响。因为 tcp 的拥塞避免算法会导致产生丢包时传输速率的大幅下降。而其实当时的带宽并没有跑满。kcp是基于udp的封装的一个可靠传输的协议,可以理解为另外一种 tcp,在发包的策略方面可能更激进一些。 |
这是个伟大的想法! |
这个要是能加上就好了 内网ssh 经常丢包...带宽资源是够的.. |
搭配一个socks5代理,可以自行组合使用frp和kcptun。 |
很是期待 |
我用Windows客户端测试了下,好像不行,版本0.10 D:\frp>frpc.exe 可以确定kcptun及shadowsocks的配置是正确的。 |
@w12928293
内网:
数据流向: |
kcp 协议将会在 0.12 版本作为可选方案支持。 |
@fatedier 这kcp 有一堆参数,似乎合理配置参数才能最大化 它的优势,能否智能化? |
Google bbr可以参考一下 |
如果不考虑墙的因素,frp没有必要加入kcp来提速, bbr完全够了,引入kcp会加大程序的复杂性。 |
另外根据我自己的实测和网友的测试,xkcptun的加速效果跟kcptun的加速效果大致相当,这样可以排除是因为xkcptun实现不当而导致对比测试结果的有效性。 |
|
@chmis8000 暂时不考虑,不是这个项目的重点,目前使用默认参数配置。如果有更好的能够动态调整的基于 udp 的其他算法再考虑另外支持。 |
@fatedier |
写个文档讲一下如何一起使用就好了 |
|
@fatedier |
@liudf0716 作为使用者,考虑的更多的应该是一个应用能否满足自己的需求,使用是否方便。 你觉得既然有其他方法可以实现 xxx,我们为什么要做? 如果按照你的理解,frp 这个项目本身可以不存在。你可以选择用 ssh 来实现端口转发的功能(ssh 为什么要有端口转发的功能,明明有其他替代方案啊 😄),配合 nginx 可以做到根据域名路由的功能,再配合 iptables,你甚至可以做到 frp 目前都无法实现的功能。 然而我自己都不愿意这么用,费时费力。我多花一些时间,就可以让更多的人节省一部分时间。希望多站在其他人的角度考虑问题,不仅仅是满足自己的需求。 再强调一个问题,这是一个可选功能,你忽略它,它就不存在,不影响到你的任何使用。如果你仍然坚持你的看法,建议你先邮件 kcptun 的作者,让他直接关闭项目吧,一个有替代方案的项目,怎么可能有人用呢 😜 |
@fatedier |
@liudf0716 谢谢,我对 BBR 的功能和应用很了解,包括 dpdk 也研究过。web服务,音视频服务,个人用户领域,服务器领域,面对的问题是不一样的,早在 BBR 之前,类似的算法就已经非常多了,但是这些都不够通用,很难解决所有的问题。这个方面比较出名的一直是 ZetaTCP,支持智能学习,国内很多公司的服务器上应该都在用,但是依然不够通用。 我不知道你有没有做过后端网络服务的研发,你的一些态度和看问题的方式比较让我怀疑,缺乏一些基本常识,很容易以偏概全。 比如认为 BBR 是新技术,比其他的加速算法都要好。比如认为 kcp(这里泛指基于 udp 的双边加速技术) 在其他方面不具有任何优势。你所谓的技术选型更像是把一个技术用到其他所有场景下。并且你考虑问题的角度始终站在你自己的立场上,没有考虑到各种各样的场景和需求。 如果你有兴趣,应该多研究研究在大数据量传输,大量小包传输,长连接,短连接环境下,这些算法的效果和面临的问题。 如果还有此类问题请移步 kcp 或者 kcptun 的社区讨论。另外,可以发邮件给 google QUIC 社区,让他们取消这个协议的规划和实现吧。 这个话题终止,不需要再在这个上面浪费时间了,我没有兴趣继续。 |
fatedier大哥,最近我发现了一个非常好的东西kcptun。
https://github.com/xtaci/kcptun
经过我简单测试之后,发现效果提升非常明显!不仅能降低延迟,而且传输速率等指标有显著地提升!
希望您能在以后的开发过程中融入此功能选择,集成在项目当中,最大优化本软件!
The text was updated successfully, but these errors were encountered: