首页 > 服务器 > Linux相关 > OpenVZ 平台 Google BBR 加速 TCP 之 Rinetd 方式
2017
08-01

OpenVZ 平台 Google BBR 加速 TCP 之 Rinetd 方式

简介

Rinetd 这种方式其实两三个月前就已经有了,是 v2ex 网友 @linhua 的成果,他直接将 BBR 内置到了 Rinetd 里边,比较方便的就能配置出来。也就是由于配置比较简单,我本来没想再写这个的一键配置脚本(@linhua 实现了一个 https://github.com/linhua55/lkl_study),但由于很多朋友使用 haproxy 的方式失败了,网上的脚本也只支持 Ubuntu 16 和 CentOS 7 以上的系统,我还是决定再写一个通用的 rinetd-bbr 一键脚本。

ps:正在写,过一段时间再发布。先写一下手动搭建的方法。

手动搭建

仅支持 64 位系统。

1.下载文件到 /usr/bin/rinetd-bbr

2.设置权限

3.创建配置文件

输入以下内容

其中的 443 请改为你的端口

IP 地址统一写 0.0.0.0

4.获取接口名称

看具有公网 IP 的接口名称(比如我的公网 IP 是 10.10.10.10),上面这种的接口是 venet0:0 而不是 venet0

搬瓦工的 OpenVZ 应该都是 venet0:0 接口。

5.启动

注意:将最后的接口改为你上面获取到的接口。在命令最后面加 & 以使其能后台运行。

验证

正常情况下的输出:

查看 iptables 规则:

已经有两条规则了。

最后编辑:
作者:
百度ID:“度娘程序员”,博主。
捐 赠如果您觉得这篇文章有用处,请支持作者!鼓励作者写出更好更多的文章!

OpenVZ 平台 Google BBR 加速 TCP 之 Rinetd 方式》有 11 条评论

  1. Google Chrome 59.0.3071.115Google Chrome 59.0.3071.115Windows 7 x64Windows 7 x64

    跑了一天后SS挂掉了,SSH连不上;不解;重启后又好了,奇怪

  2. Google Chrome 56.0.2924.87Google Chrome 56.0.2924.87Android 7.1.1Android 7.1.1

    请问怎样可以重启后自启动。我用下面的方法,但vps重启后不会自动运行。

    vi /etc/rc.local 加入
    /usr/bin/rinetd-bbr -f -c /etc/rinetd-bbr.conf raw eth0 &

    • Google Chrome 60.0.3112.78Google Chrome 60.0.3112.78Mac OS X 10.12.6Mac OS X 10.12.6

      你用 supervisor 吧

      • Google Chrome 60.0.3112.90Google Chrome 60.0.3112.90Windows 10 x64Windows 10 x64

        博主,问下,kcptun为什么配置了多用户后,经常会出现无法访问呢?单用户的时候几乎没这情况。。。好郁闷啊,能不能回复下思路,等的好辛苦呀

        • Google Chrome 60.0.3112.90Google Chrome 60.0.3112.90Mac OS X 10.12.6Mac OS X 10.12.6

          你在无法访问的时候上去看一看,kcptun 的进程是否正常运行着的,然后每个进程的日志看一看。

          • Google Chrome 60.0.3112.90Google Chrome 60.0.3112.90Windows 10 x64Windows 10 x64

            都正常。。。问一下,如果我一个ss的端口给好多个kcptun端口加速呢?也就是ss账号只有一个,但是kcptun建立了多个账号,不同人用,是不是因为这个冲突了???多个kcptun加速同一个ss端口

          • Google Chrome 60.0.3112.90Google Chrome 60.0.3112.90Windows 10 x64Windows 10 x64

            不用kcptun能访问,用了kcptun就不行了,重启kcptun跟ss都没用,这是为啥。。日志也没报错,就是一直open,closed,好奇怪。。。实在是找不到原因了

      • Google Chrome 56.0.2924.87Google Chrome 56.0.2924.87Android 7.1.1Android 7.1.1

        换了Ubuntu 16 正常。就是VPS的Debian 8 64有问题

  3. Google Chrome 59.0.3071.115Google Chrome 59.0.3071.115Windows 10 x64Windows 10 x64

    haproxy-lkl的方式,后端应用获取到的ip为10.0.0.2,而不是真实ip,这样就不能屏蔽有些恶意攻击
    rinetd可以获取原始ip吗?

    • Google Chrome 60.0.3112.78Google Chrome 60.0.3112.78Mac OS X 10.12.6Mac OS X 10.12.6

      我试了试,这种方式反回给后端的 IP 是 127.0.0.1,不是真实的 IP。

      • Google Chrome 60.0.3112.78Google Chrome 60.0.3112.78Windows 10 x64Windows 10 x64

        博主,问下,kcptun为什么配置了多用户后,经常会出现无法访问呢?单用户的时候几乎没这情况。。。好郁闷啊,

发表回复

你的邮箱地址不会被公开,垃圾评论将被删除。

有人回复时邮件通知我