有一个双边加速软件，可参考提升frp的工作性能 about frp

[fatedier]

kcp 协议将会在 0.12 版本作为可选方案支持。

[test01wrk]

@w12928293
不用加那层ss，直接加层kcptun就可以，主要是frpc到frps间用kcp连起来。
我这里scp速度从100K/s提高到600K/s，其他丢包、延迟什么的没测过。
公网：

1. frps监听tcp7000
2. kcptun server监听udp7000 转发给本地frps的127.0.0.1:7000

内网：

1. kcptun client监听tcp7000，连公网udp7000
2. frpc连kcptun client的127.0.0.1:7000

数据流向：
访问公网映射端口->公网frps->kcptun server->kcptun client->内网frpc->内网端口

[fatedier]

感谢提醒，这个项目我也一直关注着。

[chmis8000]

看介绍牺牲带宽，提升速度，不明白什么原理，是类似每个包之间间隔时间短了么？

[JimLee1996]

单位时间发包数变多了，但并不意味着单位时间内有效信息的发送等幅增长。准确来说，对于质量不好的线路，由于丢包率较高，可能导致延迟较高、传输速率较慢（比如跨洋线路等）。这种影响可以通过双倍甚至多倍发包来纠正和弥补。因此链接质量可以很有效果的提升，即从宏观看，“速度提升了”。诚然，多倍发包占用更多的流量和带宽。

[fatedier]

推荐可以看下 tcp 的拥塞控制。

我的理解是，总的来说这些控制算法的目的都是在于尽量可能的跑满带宽，降低丢包的影响。因为 tcp 的拥塞避免算法会导致产生丢包时传输速率的大幅下降。而其实当时的带宽并没有跑满。kcp是基于udp的封装的一个可靠传输的协议，可以理解为另外一种 tcp，在发包的策略方面可能更激进一些。

[yi-ge]

这是个伟大的想法！

[fcying]

这个要是能加上就好了 内网ssh 经常丢包...带宽资源是够的..

[bxwllzz]

搭配一个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]

很是期待

[w12928293]

@bxwllzz

我用Windows客户端测试了下，好像不行，版本0.10

D:\frp>frpc.exe
Proxy URL scheme must be http, not [socks5]

可以确定kcptun及shadowsocks的配置是正确的。

[chmis8000]

@fatedier 这kcp 有一堆参数，似乎合理配置参数才能最大化 它的优势，能否智能化？

[hilookas]

Google bbr可以参考一下
文档看这里https://www.wudew.com/posts/62

[liudf0716]

如果不考虑墙的因素，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]

另外根据我自己的实测和网友的测试，xkcptun的加速效果跟kcptun的加速效果大致相当，这样可以排除是因为xkcptun实现不当而导致对比测试结果的有效性。

[fatedier]

@liudf0716

1. 没有增加程序的复杂性，底层协议替换起来很方便，应用层面几乎不感知，完全不影响上层功能的开发。
2. 考虑到移动网络等使用场景，直接支持简单易用，bbr 目前还不是默认算法。
3. 对于不需要的同学当这个不存在就可以了，配置文件依然使用以前的。需要用的同学加两个参数，也很简单。
4. 如果有一天网络环境已经可以完全忽略丢包，或者内核默认的tcp拥塞控制算法已经可以达到同等的效果时就不再考虑这个了。

[fatedier]

@chmis8000 暂时不考虑，不是这个项目的重点，目前使用默认参数配置。如果有更好的能够动态调整的基于 udp 的其他算法再考虑另外支持。

[hilookas]

@fatedier
额，据说新的ubuntu server（Linux kernel）已经集成了bbr了。
一个命令激活。
（还是已经默认启用了？不清楚）
其实我个人感觉这种东西没有必要让frp集成，这不是应用层需要考虑的东西。。

[hilookas]

写个文档讲一下如何一起使用就好了
没有必要集成到程序里。。

[fatedier]

@lookas2001

1. 目前很难说有一种 tcp 拥塞控制算法可以在任何场景下都做到快速，公平的数据传输。内核默认的算法是经过验证的，保证了在大多数场景下的稳定性，我觉得短期内这个是不会变化的。启用 bbr 意味着替换内核 tcp 协议栈，对所有应用都有影响。这部分可以不做深入讨论了，不在本项目的研究范围内。
2. 一切从需求出发，综合考虑，例如我在 https://www.v2ex.com/t/362833 中看到的讨论。
3. 如果增加一个功能或特性，会影响到现有服务的稳定性或功能，会慎重考虑。如果是有部分用户的合理需求，并且对其他用户添加后可以无感知，我觉得完全可以支持。

[liudf0716]

@fatedier
bbr的启用非常简单，只要内核版本在4.9以上，就可以非常简单的启用，应用层完全无感知。在国内的网络环境下，单边提速的效果要大大优于kcp（不考虑fq的场景），这是我认为frp没必要兼容kcp的原因，当然，frp有别的特殊应用场景就另当别论了。

[fatedier]

@liudf0716
你没有完全理解这里面潜在的问题（修改内核模块涉及到的稳定性问题，权限问题等等），并且考虑问题的角度不同。

作为使用者，考虑的更多的应该是一个应用能否满足自己的需求，使用是否方便。
作为开发者，考虑的是满足大多数用户的使用场景和需求，综合考虑。（不要用我很轻松就可以做到 xxx 来衡量每一个使用者，仍然有部分使用者配置使用 frp 都有困难）

你觉得既然有其他方法可以实现 xxx，我们为什么要做？

如果按照你的理解，frp 这个项目本身可以不存在。你可以选择用 ssh 来实现端口转发的功能(ssh 为什么要有端口转发的功能，明明有其他替代方案啊 😄)，配合 nginx 可以做到根据域名路由的功能，再配合 iptables，你甚至可以做到 frp 目前都无法实现的功能。

然而我自己都不愿意这么用，费时费力。我多花一些时间，就可以让更多的人节省一部分时间。希望多站在其他人的角度考虑问题，不仅仅是满足自己的需求。

再强调一个问题，这是一个可选功能，你忽略它，它就不存在，不影响到你的任何使用。如果你仍然坚持你的看法，建议你先邮件 kcptun 的作者，让他直接关闭项目吧，一个有替代方案的项目，怎么可能有人用呢 😜

[liudf0716]

@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]

@liudf0716 谢谢，我对 BBR 的功能和应用很了解，包括 dpdk 也研究过。web服务，音视频服务，个人用户领域，服务器领域，面对的问题是不一样的，早在 BBR 之前，类似的算法就已经非常多了，但是这些都不够通用，很难解决所有的问题。这个方面比较出名的一直是 ZetaTCP，支持智能学习，国内很多公司的服务器上应该都在用，但是依然不够通用。

我不知道你有没有做过后端网络服务的研发，你的一些态度和看问题的方式比较让我怀疑，缺乏一些基本常识，很容易以偏概全。 比如认为 BBR 是新技术，比其他的加速算法都要好。比如认为 kcp(这里泛指基于 udp 的双边加速技术) 在其他方面不具有任何优势。你所谓的技术选型更像是把一个技术用到其他所有场景下。并且你考虑问题的角度始终站在你自己的立场上，没有考虑到各种各样的场景和需求。

如果你有兴趣，应该多研究研究在大数据量传输，大量小包传输，长连接，短连接环境下，这些算法的效果和面临的问题。

如果还有此类问题请移步 kcp 或者 kcptun 的社区讨论。另外，可以发邮件给 google QUIC 社区，让他们取消这个协议的规划和实现吧。

这个话题终止，不需要再在这个上面浪费时间了，我没有兴趣继续。