本文目录：
- 1、ipv6怎么开启bbr
- 2、如何查看vps是否开启了bbr
- 3、debian 开启bbr
- 4、BBR plus（bbr修正版）一键安装与使用
- 5、如何验证开启linux bbr？
- 6、OpenVZ 开启 BBR 技术说明
ipv6怎么开启bbr
ipv6开启bbr：买一个堪江出厂支持ipv4和ipv6双模式光猫，可以相互转换协议，只要Tcpip启动iptv6协议光猫路由器模式开启lenten英特尔连接就可以联网，iiptv4是32位，iptv6是128位，是iptv4的4倍。
1、 以管理员身份运行cmd命令，进入命令行模式。
2、 输入netsh。
3、 输入int ipv6 isatap，进入isatap配置模式。
4、 输入set router isatap.ahau.edu.cn en，配置isatap路由器。
报文内容：
IPv6报文的整体结构分为IPv6报头、扩展报头和上层协议数据3部分。IPv6报头是必选报文头部，长度固定为40B，包含该报文的基本信息；扩展报头是可选报头，可能存在0个、1个或多个，IPv6协议通过扩展报头实现各种丰富的功能。
上层协议数据是该IPv6报文携带的上层数据，可能是ICMPv6报文、TCP报文、UDP报文或其他可能报文。
如何查看vps是否开启了bbr
1、打开vps的控制台，使用vps的“root”账号登录vps，然后输入vps的密码，需要注意的是如果需要粘贴密码，需要用鼠标右击控制台光标处，这时面会被自动粘贴上去：
2、在控制台中输入“lsmod | grep bbr”，然后按下键盘上的回车键：
3、按下回车键后查看结果进程中是否有bbr，如果有则表示开启了bbr，否则表示没有开启bbr：
debian 开启bbr
验证是否生效（一）
若提示如下，则表明bbr生效
验证是否生效（二）
若提示如下，则表明bbr生效（注意16384这个数字各有不同）
原地址：
#加速# Debian 9开启内核BBR（无需第三方脚本） | 微魔部落
BBR plus（bbr修正版）一键安装与使用
这是loc论坛上一位网友提供的 BBR 版本，在普通BBR、魔改BBR的基础上更加的暴力。
github项目地址：
本脚本只支持KVM不支持ovz
CentOS 一键 安装脚本（ 自动安装内核 并启用）：
安装后，执行uname -r，显示4.14.90则切换内核成功
执行lsmod | grep bbr，显示有bbrplus则开启成功
如何验证开启linux bbr？
仅在Ubuntu，Arch，Manjaro 下测试过，其它发行版同理。
Arch/Manjaro
虽然 Arch/Manjaro 可以直接安装 linux49 包。但默认没有开启 BBR。需要手动编译。下载 manjaro/packages-corelinux49 包的所有文件，将 config 以及 config.x86_64 文件中的
# CONFIG_TCP_CONG_BBR is not setCONFIG_DEFAULT_CUBIC=y
改为
CONFIG_TCP_CONG_BBR=yCONFIG_DEFAULT_BBR=y
然后将 PKGBUILD 中第二三个 hash 改为 'SKIP'. 执行 makepkg -si 即可。
开启 BBR，如果/etc/sysctl.conf文件有关于net.ipv4.tcp_congestion_control配置的，请注释掉
再输入
echo "net.core.default_qdisc=fq" /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" /etc/sysctl.conf
保存生效sysctl -p
执行sysctl net.ipv4.tcp_available_congestion_control
如果结果中有 BBR，则内核开启 BBR 算法成功
执行lsmod | grep bbr，看到 tcp_bbr 则说明 BBR 启动成功
OpenVZ 开启 BBR 技术说明
首先，对 Google 公司发明的 BBR TCP 拥塞控制算法表示致敬。
网上有大量的 OpenVZ 开启 BBR 的帖子，但是基本上只有操作，没有技术说明和分析。
本文的目的是这些帖子涉及到的技术以及相关思路进行一些说明。
所谓拥塞控制算法，其要解决的问题是判断网络是否拥堵，从而控制发包速率以及重传等。
在 Google 的 BBR 出现之前，所有的拥塞控制算法都是以是否丢包来作为判断标准，一旦有丢包，就认为可能有网络拥塞，随之降低发包速度。这类算法在网络传输需要跨大洋，或者有一些外部干扰导致丢包的情况下，会误判为网络拥塞。
BBR 算法其判断是否拥塞是基于数据包传输的网络延时。这是基于这样一个事实：如果网络延时增加了，那么有可能在某个设备上数据包有排队，因此网络是已经过载了，需要降低速度。而对丢包，不进行传输速度的控制。其中后者对譬如中美之间的网络访问这样的案例速度上有质的提升。
当前大部分基于 OpenVZ 的虚拟机内核都不支持 BBR，因此需要把 TCP 协议栈运行在用户态。
要在用户态运行网络协议栈，我们使用的技术名为 LKL (Linux Kernel Library)，即将内核编译成为一个动态链接库，可以通过对指定程序设置 LD_PRELOAD 这个环境变量来使的该程序调用 LKL 中定义的函数而不是系统原生的函数。通过这种方式，我们调用的网络函数实际上使用了LKL中的网络函数，其是支持BBR的。关于 LD_PRELOAD 的更多信息，可以参考附录链接。
要使用 LKL，我们需要在外部创建一个网络设备，然后将这个网络设备作为参数传递给 LKL，那么流经该网络设备的流量就会被 LKL 处理。
出于简要起见，对于本文涉及到 OpenVZ 虚拟机，我们称呼其为 ss。
我们期望发往 ss 的流量直接被用户态程序处理而不经过 ss 的 TCP 协议栈，而直接发送到 LKL 处理的网络设备。
要在进入 TCP 协议栈前劫持流量，这可以通过 iptables 改变 IP 包目的地址，使其转变为通过 LKL 处理的网络设备来实现。至于改变成什么 IP 地址取决于哪些路由表。一般简单起见。可以改成和 LKL 处理的网络设备同一个网段。
在网上流行的帖子中，清一色用了 haproxy 放在应用程序前面，实际上这并不是必须的。完全可以在应用程序前面加上 LD_PRELOAD 来实现应用程序支持 BBR。另外，这个 Haproxy 也是一个普通的 Haproxy，没什么特殊的。
对于引入 Haproxy 的原因，我猜想除了后面我会提到 LKL 虚拟网络设备的问题，还可以通过在程序前端监听多个端口，来转发到后端同一个服务，从而达到流量分散比较容易隐藏的目的。
这里讲到的 LKL 虚拟网络设备主要是指 tun/tap 中的 tap 设备。
在程序运行过程中 LKL 会去读取虚拟网卡的内容，对环境变量中指定的 IP 地址进行响应，如果多个 LKL 都去读取同一块虚拟网卡，在数据源上可能会有冲突（譬如A程序已经读取过导致B程序读取不到？未验证）。也可能会导致被劫持的 IP 地址冲突（譬如两个 LKL 程序都配置了同一个 IP 地址）。因此在这种情况下需要用多个虚拟网卡（这会导致配置复杂和维护困难）或者就用 Haproxy 作为中间人，转发请求到后端应用。我猜想这是网上帖子引入 Haproxy 的一个主要原因。
在网上的帖子中，能够ping 10.0.0.2 那是使用了 LKL 应用程序开启后才可以的。推测可能是 LKL 初始化的时候会自己开启一些线程。
部署参考：
技术参考：
【如何开启bbr】的内容来源于互联网，如引用不当，请联系我们修改。
网友留言：