话说这里怎么没人讨论 BBR？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2934 天前的主题，其中的信息可能已经有所发展或是发生改变。

昨天隔壁都被屠版了，居然这里没有…
转发一下吧

首先先知道一下什么是 BBR

概括一下就是和锐速差不多的东西

CentOS 安装方式
http://www.hostloc.com/thread-342471-1-1.html

http://www.hostloc.com/thread-342505-1-1.html

http://www.hostloc.com/thread-342551-1-3.html

Ubuntu 系列 4.9 内核自带了

锐速 PK BBR

http://www.hostloc.com/thread-342500-1-1.html

http://www.hostloc.com/thread-342627-1-3.html

http://www.hostloc.com/thread-342562-1-5.html

bbr

锐速

centos

Ubuntu

33 条回复 • 2016-12-12 13:53:54 +08:00

debiann

2016-12-09 09:52:08 +08:00 via iPhone

很久之前这里就发过贴了

cocochan

2016-12-09 09:53:35 +08:00 via iPhone

顺带一提如果是拿来 cross wall 的话，你会发现还是我司锐速比较厉害， BBR 会断流

cocochan

2016-12-09 09:54:40 +08:00 via iPhone

BBR 的 Github 地址:https://github.com/google/bbr

terrancesiu

2016-12-09 09:59:43 +08:00

我用的 fedora ，内核在这里： https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/

d7101120120

2016-12-09 10:01:00 +08:00

现在用锐速的本身就比较少了吧，除了流量敏感的 vps 或者 ISP 封锁 UDP ，否则基本上还是上 kcp 速度比较有保障。

cocochan

2016-12-09 10:01:49 +08:00 via iPhone

@d7101120120 KCP 是真的暴力… 对邻居极其不友好比 FS 还差

DesignerSkyline

2016-12-09 10:03:57 +08:00 via iPad

用了两个月左右了吧。。。现在才发现吗。。。这消息有点过时了

cocochan

2016-12-09 10:04:52 +08:00 via iPhone

@DesignerSkyline 这几天貌似发布了不需要编译的（稳定版）吧

introom

2016-12-09 10:05:47 +08:00

你想怎么讨论 BBR ？

通过 RTT 和发送量来估计交换机 queue 的长度，减少 delay 。我就知道这些。

不知道和 cubic 共存， fairness 怎么样，据说是能把 cubic 给干了。

BBR 更多适用于非 DC 环境。

DC 环境的话，还是直接 DCTCP 。

DesignerSkyline

2016-12-09 10:06:18 +08:00 via iPad

@cocochan 。。。。想多了， 9 月就合并到 net-next 去了，自己不信可以去看 patch 合并记录。

d7101120120

2016-12-09 10:07:52 +08:00

@cocochan 之前看介绍是说 kcp 比起 FS 友好一些，而且 SS 的 andorid 客户端也集成了 kcp

cocochan

2016-12-09 10:09:00 +08:00 via iPhone

@DesignerSkyline 貌似是的，这方面我的确没怎么关注都是跟着节奏走的。不过知道 BBR 的还是少数，就当推广一下 BBR 吧（

cocochan

2016-12-09 10:09:39 +08:00 via iPhone

@d7101120120 瞎扯… KCP 有效带宽奇低友好只是对硬件占用比较小吧

raysonx

2016-12-09 12:05:36 +08:00 via Android

等有时间测试一下

iCyMind

2016-12-09 12:30:21 +08:00

有没有和 kcptun 的速度测试

Alain1995

2016-12-09 12:49:27 +08:00

我就想问下隔壁是哪里 ![]([

)

raysonx

2016-12-09 13:01:10 +08:00

@iCyMind TCP 流控算法要考虑公平性，我觉得肯定不如这种暴力算法哈哈

iCyMind

2016-12-09 13:17:51 +08:00

@raysonx 你说的有道理.
不过这 bbr 效果的确不错, ss + bbr 居然能看 1080p

iCyMind

2016-12-09 13:18:14 +08:00

@Alain1995 估计是说 hostloc

20015jjw

2016-12-09 13:22:24 +08:00

我想问隔壁是哪里...

redsonic

2016-12-09 13:23:56 +08:00

我想知道用了这些加速方案机房里的 dashboard 有什么变化。 BBR 进了 mainline 大家都用上了，最后还是挤华容道？

raysonx

2016-12-09 15:15:30 +08:00

@redsonic 稍稍看了下 Google 那篇 BBR 論文（草稿）的前几頁，大致是對傳統 TCP 流控算法以丢包作為擁塞控制的方法批判了一番，然後提出以傳播時延和瓶頸帶寬作為基礎的算法。
等晚上回去有時間把它看完。不知道當它和 Linux 預設的 Cubit 之類的算法一起跑的時候公平性表現如何（估計對傳統算法做不到公平吧）。

ovear

2016-12-09 15:23:49 +08:00

http://blog.csdn.net/dog250/article/details/52830576

贴一篇百度到的分析文章，博主好像写了不少关于 bbr 的文章，有兴趣的人可以开看。

raysonx

2016-12-09 15:27:04 +08:00

@ovear 感謝分享，到時候結合在一起看看。

redsonic

2016-12-09 15:37:39 +08:00

@raysonx 我之前也看了论文，代码大致看了看，反思一下 BBR 改变的地方确实有道理，意思是之前那些算法都是在计较重传的次数，重传的 rtt 之类的，这都是在瞎猜，不如测一个实际带宽然后根据一般的 rtt 去打折。我的意思是既然 BBR 进了内核主线，应该会很快部署，用不了多久大家又处在同一起跑线了。蛋糕太小，改进叉子也没用。

redsonic

2016-12-09 15:39:59 +08:00

@ovear 博主是网络方面的专家，很多东西都是自己先写出来的。

raysonx

2016-12-09 15:46:03 +08:00

@redsonic 直覺上，對存在丢包但帶寬有剩餘的網絡（比如無線網絡）提升會比較大，能夠充分利用帶寬。
但對於天朝的國際出口來講，應該是打滿的吧，除非顯著降低重傳的量（這個還沒看到，不確定），否則物理帶寬就那麼點，還是沒甚麼用。

ovear

2016-12-09 15:56:27 +08:00

@raysonx 我觉得这个跟拥塞算法的竞争性有关。
也就是所谓的公平性，挤占使用其他算法宽带的能力。。。比如说现在流行的某速，就很有竞争性。

不过 htpc 听说也很有竞争性，但是实测效果还没有 hybla 好，不知道为什么，层主网络小白。

raysonx

2016-12-09 16:00:49 +08:00

@ovear 我是在講當所有人都用上 BBR 之後的情況。
我目前還不瞭解它對其他算法的公平性如何，網上應該有一些測試了吧。

redsonic

2016-12-09 16:16:52 +08:00

@raysonx
@ovear
我认为只要不是靠冗余数据来提高可用带宽的算法应该是比较公平的。再加上运营商卡上行和流量整形。总的说我觉得 google 的初衷是让用户个人能体验比原来好而已（纵向比较而不是横向），除此之外不带来其他问题。

raysonx

2016-12-09 16:56:07 +08:00

@redsonic 同意。

trythebest

2016-12-10 17:21:47 +08:00

评测来的更直接

aru

2016-12-12 13:53:54 +08:00

丢包在 10%以下效果还是不错的