This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.最终结论是：
- 从理论上来说，本笔记使用的测试方法（chrome dev tools隐私窗口打开单篇文章查看server response time）是完全测不出bbr开启/关闭的任何性能区别的，因为此时的网络根本达不到TCP拥塞状态。
- 此外，本笔记使用的测试方法可能会因为各种原因得到不稳定的数值。即使努力控制了变量（同一个链接、相同IP、一分钟内多次访问、每次都打开新的隐私窗口、ramfs缓存），得到的server response time也是不稳定的，可能前一秒你测试还是330ms，后一秒就变成了480ms.
- 对上面一条结论的评价：即使保持测试电脑的网络环境不变，也还有各种不可控的上游影响因素：家庭宽带的上游ISP、cloudflare、服务器的ISP、服务器的机房甚至服务器的母鸡网络环境...都会影响测试的结果。
- 所以这篇笔记并没有什么价值。
以下是1年以来陆续记录的测试结果：
2024-04-11
只连接cloudflare ipv4
在新服务器上测试
使用2022-03-20的经典文章测试
原先的cloudcone服务器我记得开了bbr大概是230ms（chrome新窗口第一次打开会慢一点，所以230ms只限于第一次）
现在关闭了bbr：240ms
打开了bbr：还是240ms
所以说也不影响什么东西
上面这部分是部署在CloudCone时记录的（2022-04-11），现在是2023年6月14日，早就搬到Hetzner并且更新了架构（比如tmpfs->ramfs），所以要记录一下新的结果：
使用2022-03-20的经典文章测试，除此之外我发现其他文章基本上也是差不多的响应时间，这大概是ramfs的pure RAM特性带来的性能改善结果。
开了bbr：90ms ~ 110ms
关了bbr：空缺（补不回来了）
2023-06-16，又测了一次突然就不对了：
开了bbr：240ms
关了bbr：空缺（补不回来了）
2024-07-03：
手痒又测试了一下，结果发现相同架构下，不同isp的结果不一样。也就是说之前的那些实验如果有空缺的，是不能后续补的，因为网络环境早就变了。目前只有这个方法算是可靠：在短时间内（比如几分钟内），不切换网络环境，打开/关闭BBR测试响应时间。
打开bbr：330ms
关闭bbr，顺便重启服务器更新kernel
重启后（状态为关闭bbr）：340ms
然后再打开bbr：323ms
然后再关闭bbr：很不稳定，330ms~480ms数值乱跳
然后再打开bbr：很不稳定，数值乱跳
然后关闭bbr并重启：很不稳定，数值乱跳
放弃了。回忆起以前也有类似问题，应该是这个实验方法就是错误且不稳定的，根本就没有办法得出什么稳定可靠的结果。以前的测试没有发现数值乱跳问题，大概还是测试次数不够多，多测几次可能就发现问题了。
把说明补充在本笔记的开头，然后这篇笔记就可以封档并发表了。
