谷歌出品TCP网络拥塞算法BBR效果测试
发布网友
发布时间：2024-10-06 19:41
共1个回答
热心网友
时间：2024-11-17 22:28
以下是谷歌公开的一些关于网络拥塞与控制的资料。
在网络中，数据通信设备（如交换机和路由器）通常会在入方向设置一个缓存队列，以应对短时间内涌入的大量数据包。然而，如果入方向的流量持续超过缓存队列的容量，后续的数据包就会被丢弃，发送端因此会感知到数据包丢失。
我们可以将网络链路想象成一根水管，路径上的数据通信设备就像自带了一个蓄水池，通常情况下不会使用。当水流增大时，蓄水池开始蓄水，如果超过蓄水极限，水流就会溢出（数据包丢失）。
当发送端检测到数据包丢失时，传统的TCP拥塞控制算法会减小发送端的拥塞窗口Cwnd，以*数据包的发送。这类拥塞控制算法被称为基于丢包（Loss-based）的拥塞控制算法。
这显然不是最佳的处理时机！因为使用缓存队列并不能提升整个链路的带宽，反而还会增加每个数据包的RTT（每个数据包的排队时间变长）。缓存队列只是应急区域，平时是不应该被使用的。
BBR的设计思路是控制时机提前，不再等到数据包丢失时再进行*，而是控制稳定的发送速度，尽量利用带宽，同时又不让数据包在中间设备的缓存队列上堆积。
为了实现稳定的发送速度，BBR使用TCP Pacing进行发送控制，因此BBR的实现也需要底层支持TCP Pacing；为了利用带宽，BBR会周期性地探测链路条件是否改善，如果是，则增加发送速率；为了防止数据包在中间设备的缓存队列上堆积，BBR会周期性地探测链路的最小RTT，并使用该最小RTT计算发送速率。
测试结果如下：
可以看到
建议开启BBR
测试步骤和环境准备：
/dev/null类似一个黑洞，写入任何东西都会返回成功，但实际上写入数据会立即被丢弃。/dev/null的IO只是软件层面的，实际没有存储的IO动作。但是，既然是软件层面的，就会有userspace到kernel的system call，这会消耗相当多的CPU和内存。因为传入/dev/null的数据几乎在其从软件传出的同时被丢弃，所以传输速度几乎没有延迟，CPU占用率会迅速上升。
无BBR不丢包丢包1%使用tc命令模拟丢包1%
Linux操作系统中的流量控制器TC（Traffic Control）用于Linux内核的流量控制，主要是通过在输出端口处建立一个队列来实现流量控制。
丢包10%有BBR下载安装下载安装可使用秋水大佬一键脚本，期间需要重启
不丢包丢包1%丢包10%
