案例库 · 软件与 IT · 技术决策 · 2016–2018
谷歌的BBR通过建模瓶颈而非惧怕丢包来修复TCP
BBR用瓶颈带宽和往返时延的模型替代了基于丢包的TCP拥塞控制,使YouTube全球吞吐量提升约4%,无需新增硬件。
解法
TCP的拥塞控制设计于20世纪80年代,基于一个等价关系:丢包意味着拥塞,因此应降低发送速率。到2016年,这一等价关系已被打破——网卡从Mbps提升到Gbps,内存从KB提升到GB——因此基于丢包的算法(如CUBIC)要么维持巨大缓冲(缓冲膨胀),要么误判丢包,仅交付可用带宽的一小部分。
谷歌的make-tcp-fast团队——成员包括Neal Cardwell、Yuchung Cheng、C. Stephen Gunn、Soheil Hassas Yeganeh和Van Jacobson——构建了BBR(瓶颈带宽和往返传播时间)。它测量实际观察到的最大交付速率和最小RTT,按该速率发送数据包,并将丢包仅视为队列已满的信号。
部署在Google.com和YouTube上后,BBR使YouTube的全球网络吞吐量中位数提升了约4%,在部分国家超过14%,同时降低了队列长度和延迟——无需改动硬件或协议,仅在内核中新增了一种拥塞控制算法。
生效的原因
- 按测量带宽发送可保持队列短小
- 丢包成为队列已满的信号,而非主要控制输入
- 在基于丢包的策略未充分利用高带宽时延积路径的场景中有效
- 内置于内核,无需硬件或服务器改动
取得的成效对瓶颈建模;按其速率发送,不惧怕丢包聪明
可借鉴之处
当曾经有效的规则与现实不符时,用模型取代启发式方法:BBR不再将丢包视为拥塞,而是测量实际瓶颈。
后续进展
BBR于2016年合并入Linux内核,成为许多CDN和云提供商的推荐拥塞控制,并催生了BBRv2。谷歌随后将其部署到Google Cloud TCP,提升了云客户跨洲际的吞吐量。
资料来源
- BBR: Congestion-Based Congestion Control
- TCP BBR congestion control comes to GCP — your Internet just got faster
发现哪里写错了?告诉我们。