mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 16:15:49 -06:00
[GH-ISSUE #99] 有一个双边加速软件，可参考提升frp的工作性能 #48
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#48
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @JimLee1996 on GitHub (Aug 27, 2016).
Original GitHub issue: https://github.com/fatedier/frp/issues/99
fatedier大哥，最近我发现了一个非常好的东西kcptun。
https://github.com/xtaci/kcptun
经过我简单测试之后，发现效果提升非常明显！不仅能降低延迟，而且传输速率等指标有显著地提升！
希望您能在以后的开发过程中融入此功能选择，集成在项目当中，最大优化本软件！
@fatedier commented on GitHub (Aug 28, 2016):
感谢提醒，这个项目我也一直关注着。
@chmis8000 commented on GitHub (Sep 1, 2016):
看介绍牺牲带宽，提升速度，不明白什么原理，是类似每个包之间间隔时间短了么？
@JimLee1996 commented on GitHub (Sep 1, 2016):
单位时间发包数变多了，但并不意味着单位时间内有效信息的发送等幅增长。准确来说，对于质量不好的线路，由于丢包率较高，可能导致延迟较高、传输速率较慢（比如跨洋线路等）。这种影响可以通过双倍甚至多倍发包来纠正和弥补。因此链接质量可以很有效果的提升，即从宏观看，“速度提升了”。诚然，多倍发包占用更多的流量和带宽。
@fatedier commented on GitHub (Sep 1, 2016):
推荐可以看下 tcp 的拥塞控制。
我的理解是，总的来说这些控制算法的目的都是在于尽量可能的跑满带宽，降低丢包的影响。因为 tcp 的拥塞避免算法会导致产生丢包时传输速率的大幅下降。而其实当时的带宽并没有跑满。kcp是基于udp的封装的一个可靠传输的协议，可以理解为另外一种 tcp，在发包的策略方面可能更激进一些。
@yi-ge commented on GitHub (Sep 11, 2016):
这是个伟大的想法！
@fcying commented on GitHub (Oct 5, 2016):
这个要是能加上就好了 内网ssh 经常丢包...带宽资源是够的..
@bxwllzz commented on GitHub (Jan 22, 2017):
搭配一个socks5代理，可以自行组合使用frp和kcptun。
我的配置是：
公网服务器配置
1、shadowsocks服务端(监听8989端口)
2、kcptun服务端(监听18989并转发到localhost:8989)
3、frp服务端
内网机器配置
1、shadowsocks客户端(连接到localhost:8989)
2、kcptun客户端(监听8989并连接到[公网服务器]:18989)
3、frp客户端(配置文件中使用http_proxy=socks5://127.0.0.1:8989，其余配置无需更改，让所有frp连接走socks5代理)
总的数据流向大概这样：
外部访问-[TCP]->公网机器frp服务端-[SOCKS5]->ss服务端-[SS]->kcptun服务端-[UDP]->kcptun客户端-[SS]->ss客户端-[SOCKS5]->内网机器frp客户端-[TCP]->内网对应服务器
@engineerlzk commented on GitHub (Jan 30, 2017):
很是期待
@w12928293 commented on GitHub (Jun 2, 2017):
@bxwllzz
我用Windows客户端测试了下，好像不行，版本0.10
D:\frp>frpc.exe
Proxy URL scheme must be http, not [socks5]
可以确定kcptun及shadowsocks的配置是正确的。
@rdtoy commented on GitHub (Jun 6, 2017):
@w12928293
不用加那层ss，直接加层kcptun就可以，主要是frpc到frps间用kcp连起来。
我这里scp速度从100K/s提高到600K/s，其他丢包、延迟什么的没测过。
公网：
内网：
数据流向：
访问公网映射端口->公网frps->kcptun server->kcptun client->内网frpc->内网端口
@fatedier commented on GitHub (Jun 6, 2017):
kcp 协议将会在 0.12 版本作为可选方案支持。
@chmis8000 commented on GitHub (Jun 7, 2017):
@fatedier 这kcp 有一堆参数，似乎合理配置参数才能最大化 它的优势，能否智能化？
@hilookas commented on GitHub (Jun 10, 2017):
Google bbr可以参考一下
文档看这里https://www.wudew.com/posts/62
@liudf0716 commented on GitHub (Jun 14, 2017):
如果不考虑墙的因素，frp没有必要加入kcp来提速， bbr完全够了，引入kcp会加大程序的复杂性。
有关kcp与bbr提速的效果，我做了个测试，kcp采用的是我的xkcptun实现，文档如下，供大家参考：
https://github.com/liudf0716/xkcptun/wiki/bbr-vs-kcp-%E4%BC%98%E5%8C%96http%E4%B8%8B%E8%BD%BD%E6%80%A7%E8%83%BD%E5%AF%B9%E6%AF%94%E6%8A%A5%E5%91%8A
@liudf0716 commented on GitHub (Jun 14, 2017):
另外根据我自己的实测和网友的测试，xkcptun的加速效果跟kcptun的加速效果大致相当，这样可以排除是因为xkcptun实现不当而导致对比测试结果的有效性。
@fatedier commented on GitHub (Jun 14, 2017):
@liudf0716
@fatedier commented on GitHub (Jun 14, 2017):
@chmis8000 暂时不考虑，不是这个项目的重点，目前使用默认参数配置。如果有更好的能够动态调整的基于 udp 的其他算法再考虑另外支持。
@hilookas commented on GitHub (Jun 14, 2017):
@fatedier
额，据说新的ubuntu server（Linux kernel）已经集成了bbr了。
一个命令激活。
（还是已经默认启用了？不清楚）
其实我个人感觉这种东西没有必要让frp集成，这不是应用层需要考虑的东西。。
@hilookas commented on GitHub (Jun 14, 2017):
写个文档讲一下如何一起使用就好了
没有必要集成到程序里。。
@fatedier commented on GitHub (Jun 14, 2017):
@lookas2001
@liudf0716 commented on GitHub (Jun 14, 2017):
@fatedier
bbr的启用非常简单，只要内核版本在4.9以上，就可以非常简单的启用，应用层完全无感知。在国内的网络环境下，单边提速的效果要大大优于kcp（不考虑fq的场景），这是我认为frp没必要兼容kcp的原因，当然，frp有别的特殊应用场景就另当别论了。
@fatedier commented on GitHub (Jun 14, 2017):
@liudf0716
你没有完全理解这里面潜在的问题（修改内核模块涉及到的稳定性问题，权限问题等等），并且考虑问题的角度不同。
作为使用者，考虑的更多的应该是一个应用能否满足自己的需求，使用是否方便。
作为开发者，考虑的是满足大多数用户的使用场景和需求，综合考虑。（不要用我很轻松就可以做到 xxx 来衡量每一个使用者，仍然有部分使用者配置使用 frp 都有困难）
你觉得既然有其他方法可以实现 xxx，我们为什么要做？
如果按照你的理解，frp 这个项目本身可以不存在。你可以选择用 ssh 来实现端口转发的功能(ssh 为什么要有端口转发的功能，明明有其他替代方案啊 😄)，配合 nginx 可以做到根据域名路由的功能，再配合 iptables，你甚至可以做到 frp 目前都无法实现的功能。
然而我自己都不愿意这么用，费时费力。我多花一些时间，就可以让更多的人节省一部分时间。希望多站在其他人的角度考虑问题，不仅仅是满足自己的需求。
再强调一个问题，这是一个可选功能，你忽略它，它就不存在，不影响到你的任何使用。如果你仍然坚持你的看法，建议你先邮件 kcptun 的作者，让他直接关闭项目吧，一个有替代方案的项目，怎么可能有人用呢 😜
@liudf0716 commented on GitHub (Jun 14, 2017):
@fatedier
你可能对bbr不太了解，bbr后面的维护者是google，google已经在他自己的服务器上广泛使用这项技术，而且内核也已经接受了，所以你说的稳定性问题我个人觉得几乎可以不用考虑。
至于他的易用性，做为kcptun的使用者及xkcptun的作者，我肯定非常清楚这2者的配置难度谁门槛更低。
另外有关kcp的使用的问题，我在kcp官方群里也把我的测试结果和我自己的观点给公布出来，实际上kcp官群里一样在对比bbr和kcp的优略，我个人觉得提bbr要优于kcp好像没有人提出有力的反对意见。
以上只是我的个人看法而已，技术之间是有竞争的，不要低估他的影响力，android出来，如果还死抱着其他手机操作系统的结果大家都很清楚，用你提到的netfilter为例，netfiler没出来的时候，有不少安全厂商都有自己的防火墙架构，但现在基本都被淘汰了（很早以前，大概2006年左右，我所在的一家安全公司的防火墙就使用的是IBM的内部研发的技术，当时在市面上还是非常有竞争力，但后面就是被netfitler给淘汰了），这个事实给我非常大的触动，他活生生的告诉我们，技术选型的重要性。对kcp的看法，我个人还是这个观点，在fq方面有优势，其他方面不具有任何优势，kcptun以及我的xkcptun主要用来干啥，其实大家都非常清楚，他的生命力主要还是在特殊场景上。
以上扯了那么多，只是我的个人看法，不构成任何建议。
@fatedier commented on GitHub (Jun 14, 2017):
@liudf0716 谢谢，我对 BBR 的功能和应用很了解，包括 dpdk 也研究过。web服务，音视频服务，个人用户领域，服务器领域，面对的问题是不一样的，早在 BBR 之前，类似的算法就已经非常多了，但是这些都不够通用，很难解决所有的问题。这个方面比较出名的一直是 ZetaTCP，支持智能学习，国内很多公司的服务器上应该都在用，但是依然不够通用。
我不知道你有没有做过后端网络服务的研发，你的一些态度和看问题的方式比较让我怀疑，缺乏一些基本常识，很容易以偏概全。 比如认为 BBR 是新技术，比其他的加速算法都要好。比如认为 kcp(这里泛指基于 udp 的双边加速技术) 在其他方面不具有任何优势。你所谓的技术选型更像是把一个技术用到其他所有场景下。并且你考虑问题的角度始终站在你自己的立场上，没有考虑到各种各样的场景和需求。
如果你有兴趣，应该多研究研究在大数据量传输，大量小包传输，长连接，短连接环境下，这些算法的效果和面临的问题。
如果还有此类问题请移步 kcp 或者 kcptun 的社区讨论。另外，可以发邮件给 google QUIC 社区，让他们取消这个协议的规划和实现吧。
这个话题终止，不需要再在这个上面浪费时间了，我没有兴趣继续。