关于BBR调参的说明

sonbon

前不久与MJJ分享了自定义BBR的一些经验，并作为示例给出了自己目前使用的版本；

此举本意在于面向比较重视开源与安全性的Geek，提供一个最大化压榨机器网络的可行方案，希望有抛砖引玉之效，结果却不甚理想，尝鲜者虽多，真正动手自行调参的使用者估计寥寥无几。

于是今天又试着在digitalocean lon1节点上调教了一番BBR，谨供各位参考。

由于现在do与大陆的链路基本不可用，目前还没摸索出比较graceful的“优化”策略，暂且使用了激进发包这种dirty的方式，如果有更温和高效的方案，欢迎提出 ;D

变更涉及如下：

1. tso_segs_goal:7 >> tso_segs_goal:1 //禁用tso，与lotserver策略一致
   
2. 
   
3. bbr_bw_rtts:15 >> bbr_bw_rtts:18 //延长PROBE_BW状态
   
4. 
   
5. bbr_min_rtt_win_sec:20 >> bbr_min_rtt_win_sec:30 //延长min_rtt维持时间，尽量保持较大速率
   
6. 
   
7. bbr_probe_rtt_mode_ms:200 >> bbr_probe_rtt_mode_ms:180 //缩短PROBE_RTT状态，尽快进入PROBE_BW模式
   
8. 
   
9. bbr_cwnd_min_target:4 >> bbr_cwnd_min_target:6 //增大最小发包窗口
   
10. 
    
11. bbr_high_gain  = BBR_UNIT * 2885 / 1000 + 1 >> bbr_high_gain  = BBR_UNIT * 3921 / 1000 + 1 //增大pacing速率
    
12. 
    
13. bbr_full_bw_cnt=3 >> bbr_full_bw_cnt=4 //PROBE_BW状态下进行四次增窗，再假设网络信道已经饱和

复制代码

其他改动：更激进的发包策略

(tcp_tsunami.c, original)
https://gist.github.com/anonymous/ba338038e799eafbba173215153a7f3a/raw/55ff1e45c97b46f12261e07ca07633a9922ad55d/tcp_tsunami.c

(tcp_tsunami_lon.c)
https://gist.github.com/anonymous/68b2f4d3fe3391ea0efc0613e42010d8/raw/d3be4901da3b08f35e36eddd042923dc6bd96351/tcp_tsunami_lon.c

增大fq队列上限：

1. tc qdisc delete dev eth0 root fq
   
2. tc qdisc add dev eth0 root fq maxrate 1gbit limit 20000 flow_limit 10000 pacing refill_delay 30ms
   
3. tc -s -d qdisc show
   
4. /etc/init.d/networking restart

复制代码

其余优化参照：
https://github.com/shadowsocks/shadowsocks/wiki/Optimizing-Shadowsocks
https://github.com/breakwa11/shadowsocks-rss/wiki/ulimit

此次共使用了两台机器，部署于do lon1的46.101段网路，经测试分别安装lotserver和tcp_tsunami_lon后均能较流畅的加载y2b 1080P影像，效果基本满意。

测试仅供参考，不保证普适性，还请各位针对所在网络状况自行调节适应。

参考链接：
1. http://blog.csdn.net/dog250/article/details/52939004
2. http://blog.csdn.net/dog250/article/details/52879298
3. http://blog.csdn.net/dog250/article/details/52972502
4. https://patchwork.ozlabs.org/patch/671069/

sonbon

FAQ:

1.BBR适合那些用户？

原则上所有希望“优化”网络的用户均适用，偏向开源方案、不喜黑箱者及强迫症患者尤其适用。

2.锐速大 法好，入教保平安！

请您务必继续用下去。谢谢。

3.自定义BBR不适用于哪些人群？

没有意愿动手调节适配者慎用。卫道士禁用。

4.lotserver和BBR没有卯用，有没有专治一切垃圾线路的“优化”方案？

有，而且是开源的：

https://github.com/xtaci/kcptun
https://github.com/Chion82/kcptun-raw

后者自带fake tcp header，适用于udp丢包严重的地区
以上方案配置不当会形成异常流量，可能被作为DDoS处理

5.为什么要以BBR为框架？

(1) BBR从内核层次避开了PRR的干涉，实现了对窗口的完全控制，这对传统的拥塞控制算法而言是很难做到的；
（PRR会在丢包时无条件降低发包窗口）

(2) BBR架构清晰，而cubic等传统算法使用了大量经复杂测量得到的魔术数字来调控其行为，很不直观；

(3) BBR is powered by Google,Inc!!!!