首先，对 Google 公司发明的 BBR TCP 拥塞控制算法表示致敬。
为什么要写这个技术说明
网上有大量的 OpenVZ 开启 BBR 的帖子，但是基本上只有操作，没有技术说明和分析。
本文的目的是这些帖子涉及到的技术以及相关思路进行一些说明。
拥塞控制算法 BBR 简介
所谓拥塞控制算法，其要解决的问题是判断网络是否拥堵，从而控制发包速率以及重传等。
在 Google 的 BBR 出现之前，所有的拥塞控制算法都是以是否丢包来作为判断标准，一旦有丢包，就认为可能有网络拥塞，随之降低发包速度。这类算法在网络传输需要跨大洋，或者有一些外部干扰导致丢包的情况下，会误判为网络拥塞。
BBR 算法其判断是否拥塞是基于数据包传输的网络延时。这是基于这样一个事实：如果网络延时增加了，那么有可能在某个设备上数据包有排队，因此网络是已经过载了，需要降低速度。而对丢包，不进行传输速度的控制。其中后者对譬如中美之间的网络访问这样的案例速度上有质的提升。
思路
难点1：支持 BBR
当前大部分基于 OpenVZ 的虚拟机内核都不支持 BBR，因此需要把 TCP 协议栈运行在用户态。
要在用户态运行网络协议栈，我们使用的技术名为 LKL (Linux Kernel Library)，即将内核编译成为一个动态链接库，可以通过对指定程序设置 LD_PRELOAD 这个环境变量来使的该程序调用 LKL 中定义的函数而不是系统原生的函数。通过这种方式，我们调用的网络函数实际上使用了LKL中的网络函数，其是支持BBR的。关于 LD_PRELOAD 的更多信息，可以参考附录链接。
要使用 LKL，我们需要在外部创建一个网络设备，然后将这个网络设备作为参数传递给 LKL，那么流经该网络设备的流量就会被 LKL 处理。
难点2：劫持网络流量
出于简要起见，对于本文涉及到 OpenVZ 虚拟机，我们称呼其为 ss。
我们期望发往 ss 的流量直接被用户态程序处理而不经过 ss 的 TCP 协议栈，而直接发送到 LKL 处理的网络设备。
要在进入 TCP 协议栈前劫持流量，这可以通过 iptables 改变 IP 包目的地址，使其转变为通过 LKL 处理的网络设备来实现。至于改变成什么 IP 地址取决于哪些路由表。一般简单起见。可以改成和 LKL 处理的网络设备同一个网段。
Haproxy 的问题
在网上流行的帖子中，清一色用了 haproxy 放在应用程序前面，实际上这并不是必须的。完全可以在应用程序前面加上 LD_PRELOAD 来实现应用程序支持 BBR。另外，这个 Haproxy 也是一个普通的 Haproxy，没什么特殊的。
对于引入 Haproxy 的原因，我猜想除了后面我会提到 LKL 虚拟网络设备的问题，还可以通过在程序前端监听多个端口，来转发到后端同一个服务，从而达到流量分散比较容易隐藏的目的。
LKL 的虚拟网络设备的问题
这里讲到的 LKL 虚拟网络设备主要是指 tun/tap 中的 tap 设备。
在程序运行过程中 LKL 会去读取虚拟网卡的内容，对环境变量中指定的 IP 地址进行响应，如果多个 LKL 都去读取同一块虚拟网卡，在数据源上可能会有冲突（譬如A程序已经读取过导致B程序读取不到？未验证）。也可能会导致被劫持的 IP 地址冲突（譬如两个 LKL 程序都配置了同一个 IP 地址）。因此在这种情况下需要用多个虚拟网卡（这会导致配置复杂和维护困难）或者就用 Haproxy 作为中间人，转发请求到后端应用。我猜想这是网上帖子引入 Haproxy 的一个主要原因。
在网上的帖子中，能够ping 10.0.0.2 那是使用了 LKL 应用程序开启后才可以的。推测可能是 LKL 初始化的时候会自己开启一些线程。
参考
部署参考：https://blog.kuoruan.com/116.html
技术参考：
- https://github.com/lkl/linux
- https://www.jianshu.com/p/5c2978d459c6
- LD_PRELOAD 有趣的例子可以参考：
https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/
文中举了一个例子来劫持 random 函数，让其总是返回一个确定的数值。
网友评论