所谓拥塞控制算法,其要解决的问题是判断网络是否拥堵,从而控制发包速率以及重传等。 在 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 的原因,我猜想除了后面我会提到 LKL 虚拟网络设备的问题,还可以通过在程序前端监听多个端口,来转发到后端同一个服务,从而达到流量分散比较容易隐藏的目的。
这里讲到的 LKL 虚拟网络设备主要是指 tun/tap 中的 tap 设备。 在程序运行过程中 LKL 会去读取虚拟网卡的内容,对环境变量中指定的 IP 地址进行响应,如果多个 LKL 都去读取同一块虚拟网卡,在数据源上可能会有冲突(譬如A程序已经读取过导致B程序读取不到?未验证)。也可能会导致被劫持的 IP 地址冲突(譬如两个 LKL 程序都配置了同一个 IP 地址)。因此在这种情况下需要用多个虚拟网卡(这会导致配置复杂和维护困难)或者就用 Haproxy 作为中间人,转发请求到后端应用。我猜想这是网上帖子引入 Haproxy 的一个主要原因。
在网上的帖子中,能够ping 10.0.0.2 那是使用了 LKL 应用程序开启后才可以的。推测可能是 LKL 初始化的时候会自己开启一些线程。