运维123 - 拥塞控制
type: channel
link: https://www.sddts.cn/index.php/tag/%E6%8B%A5%E5%A1%9E%E6%8E%A7%E5%88%B6/
items: BBR 与 CUBIC 拥塞控制算法深度分析
items: 使用 K 线图分析 BBR 拥塞控制算法
items: 流媒体拥塞控制与流控技术分析

BBR 与 CUBIC 拥塞控制算法深度分析
type: item
date: 2026-01-18T00:30:42+00:00
description: BBR 与 CUBIC 拥塞控制算法深度分析一、概述1. 背景介绍自 2017 年底 BBR（Bottleneck Bandwidth and Round-trip propagation time）发布以来，随着媒体的宣讲，各大站点陆续部署 BBR。很多网友不禁问，BBR 这么好，为什么不替代 CUBIC 成为 Linux 的缺省算法。仅仅因为它尚未标准化，这么好的算法又为什么没被标准化？2. 核心问题本文将从技术原理、系统稳定性、公平性、适用场景等多个维度，深入分析 BBR 为什么没有替代 CUBIC 成为 Linux 内核缺省算法。二、算法对比分析1. 性能度量的误区A. 错误的测试方法包括作者在内的几乎所有人都用过一种错误方法度量 BBR 的"好"：搭建一跳转发的模拟环境，用 tc 配置丢包、时延，用 iperf 对比 BBR 和 CUBIC，得到结论：BBR 的吞吐比 CUBIC 大好多倍，所以 BBR 好。B. 测试的局限性这种测试方法存在严重问题：测试环境过于理想化未考虑真实网络环境的复杂性忽略了统计复用网络的基本特性C. 正确的评价标准根据 Dropbox 的实际部署经验，一个拥塞控制算法在部署之前，至少要自证两件事：不会引发拥塞崩溃网络流量公平收敛2. 算法设计哲学差异A. CUBIC 的设计理念graph LR A[CUBIC 算法] --> B[基于丢包反馈] B --> C[线性系统] C --> D[可叠加性] D --> E[稳定收敛] style A fill:#e1f5ff style E fill:#c8e6c9CUBIC 的核心特点：最小依赖：仅依赖丢包事件丢包不会撒谎：任何行为都无法做到 buffer 溢出而不丢包宁可错杀，但绝不遗漏：对拥塞的反应属反向激励线性系统：具备可叠加性，系统问题可控B. BBR 的设计理念graph LR A[BBR 算法] --> B[主动测量带宽] B --> C[测量 RTT] C --> D[模型估算] D --> E[调整发送速率] A --> F[非线性系统] F --> G[复杂行为] G --> H[不可预测性] style A fill:#fff3e0 style H fill:#ffcdd2BBR 的核心特点：主动探测带宽和 RTT依赖高精度的准确测量非线性系统，行为复杂对测量误差敏感三、深入分析1. 测量精度的陷阱A. 统计律的本质统计复用网络本身不可精确测量。这不仅仅是网络异构性的问题，更深层的原因来自于统计律本身。正如你无法把握某个空气分子的动量，但却能测量一坨空气的温度一样。B. 测量的滞后性统计方法都有滞后性，对反馈响应之前的这段时间可能就是灾难酝酿的时间。而随后的响应并不覆盖灾难，系统可能滑向不稳定状态，包括拥塞崩溃。C. BBR 的依赖性BBR 的正确性依赖高精度的准确的对 bandwidth 和 rtt 的测量，而：高精度取决于实现准确性则依赖网络本身2. 系统稳定性分析A. 线性 vs 非线性graph TB subgraph 线性系统_CUBIC A1[流 1] --> C[共享瓶颈] A2[流 2] --> C A3[流 N] --> C C --> D[稳定收敛] D --> E[公平分配] end subgraph 非线性系统_BBR B1[流 1] --> F[复杂交互] B2[流 2] --> F B3[流 N] --> F F --> G{不确定状态} G --> H[可能发散] G --> I[可能收敛] end style D fill:#c8e6c9 style G fill:#ffcdd2CUBIC 源自 Reno，是线性的，线性可叠加性让系统问题变得和单体问题一样可控。不管是同步流还是异步流，系统行为可预测。BBR 本身是个非线性系统，不能用线性的思维去简单表达。换句话说，这件事本身就凌乱复杂，没有简单到能让人快速画线获得直感的方法。B. 双流相图分析文章中的 BBR 双流相图显示，系统状态空间的边界难以确定。某个状态的可达性取决于你对系统的测量结果，而误估导致的行为不可控。3. 公平性问题A. CUBIC 的公平性与自身共存：公平收敛与异构流量共存：表现可预期收敛速度：可预期B. BBR 的公平性挑战BBR 一个也证明不了：无法自证不会引发拥塞崩溃无法自证网络流量公平收敛在某些场景下可能过度抢占带宽在某些场景下可能被 CUBIC 压制四、缺省算法的选择标准1. 设计原则大道至简，最小依赖，少即是多，这是 CUBIC 作为缺省算法的理由。A. 普适性缺省算法不一定甚至一定不是性能最高的，但一定是普适不挑环境的。B. 公平性缺省算法的公平性一定是可自证的，无论与自身还是与异构流量共存。C. 可预期性缺省…

使用 K 线图分析 BBR 拥塞控制算法
type: item
date: 2026-01-18T00:19:50+00:00
description: 使用 K 线图分析 BBR 拥塞控制算法一、概述1. 问题背景在网络性能分析中，当只有一个吞吐率散点图需要分析链路带宽走势时，传统的分析方法存在局限性。移动平均线会随时间依次平滑掉所有细节，因此它是滞后的。而蜡烛图（即 K 线图）同时保留峰谷起始，更多细节被保留，通过按阶段绘制四点包络线又同时会显示移动平均的趋势。2. 核心思想通过蜡烛图分析 BBR 带宽变化，可以识别多种网络状态：随机波动和随机噪声微突发流量持续拥塞和逐渐拥塞新流侵入和退出探测比例和公平比例3. 技术价值蜡烛图通过实体长度、上影线、下影线长度等特征，能够刻画很多细节并得到很多结论。通过大阳线、大阴线、锤头、十字星、吊颈线等固有模式及其组合分析，可以深入理解 BBR 拥塞控制算法的运行状态。二、蜡烛图基础1. 起源与定义蜡烛图（日本称为「けいせん」，Kei-sen）始于日本，早期用于统计米价走势，如今普遍用于金融领域。只有中国等少数国家叫「K 线图」，其余多称为「蜡烛图」。Kei-sen 发音也包括「线」的发音，疑似源于粤语音读。2. 基本组成一个标准的蜡烛图包含四个关键价格点：开盘价（Open）：周期开始时的价格最高价（High）：周期内的最高价格最低价（Low）：周期内的最低价格收盘价（Close）：周期结束时的价格3. 形态特征实体：收盘价与开盘价之间的部分，反映价格变动幅度上影线：实体上方的细线，代表最高价与实体顶端（开盘价或收盘价）的距离下影线：实体下方的细线，代表最低价与实体底端（开盘价或收盘价）的距离4. 常见模式大阳线：收盘价远高于开盘价，实体较长，表示强势上涨大阴线：收盘价远低于开盘价，实体较长，表示强势下跌锤头：下影线较长，实体较小，表示反转信号十字星：开盘价与收盘价接近，实体很小，表示市场犹豫吊颈线：上影线较长，实体较小，表示可能的反转三、BBR 算法简介1. 核心概念BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 推出的一种 TCP 拥塞控制算法。与传统的基于丢包的拥塞控制算法（如 CUBIC）不同，BBR 基于带宽和 RTT（往返时间）进行拥塞控制。2. 工作原理BBR 通过测量网络路径的瓶颈带宽和最小 RTT，动态调整发送速率。其主要状态包括：graph LR A[Startup] -->|探测带宽| B[Drain] B -->|排空队列| C[ProbeBW] C -->|周期探测| D[ProbeRTT] D -->|测量 RTT| C3. 关键参数BtlBw（Bottleneck Bandwidth）：瓶颈带宽RtProp（Round-trip propagation time）：最小往返时间Delivery Rate：实际交付速率Inflight：在途数据量四、BBR 模拟场景分析1. 场景设定以下是一个典型的 BBR 模拟场景：t < 100：单流正常100 < t < 200：随机突发t = 250：新流侵入300 < t < 350：随机突发t = 500：新流侵入600 < t < 650：持续拥塞750 < t < 900：逐渐拥塞t = 1050：带宽加倍1050 < t < 1250：带宽随机波动1300 < t < 1450：突发波动1450 < t < 1550：突发波动2. 带宽变化识别通过蜡烛图分析 BBR 带宽变化：A. 随机波动特征：实体较小，上下影线长度接近，表示带宽在较小范围内波动。B. 微突发特征：下影线较长或上影线较长，实体较小，表示短时间内带宽的突然变化。C. 持续拥塞特征：连续的大阴线，实体较长，表示带宽持续下降。D. 逐渐拥塞特征：实体逐渐变长且呈阴线趋势，表示带宽逐渐恶化。E. 新流侵入特征：突然的大阴线，下影线较长，表示带宽被新流抢占。F. 退出特征：突然的大阳线，上影线较长，表示流退出后带宽释放。3. 分析优势对移动平均而言，不同 alpha 的平滑细节不同，即便和算术平均放一起也看不出任何趋势，几乎无法分析。而蜡烛图能够：保留峰谷起始信息显示阶段内的最大值和最小值同时展示趋势和细节通过形态识别各种网络状态五、Python 实现蜡烛图绘制1. 环境准备A. 安装依赖pip3 install virtualenv virtualenv py3env source py3env/bin/activate pip3 install mplfinanceB. 所需库mplfinance：专门用于金融数据可视化的 Python 库numpy：数值计算库pandas：数据处理库2. 基础示例A. 数据准备import mplfinance as mpf import numpy as np import p…

流媒体拥塞控制与流控技术分析
type: item
date: 2026-01-17T23:56:02+00:00
description: 流媒体拥塞控制与流控技术分析一、概述1. 背景介绍随着网络技术的快速发展，数据中心网络面临着前所未有的挑战。传统的拥塞控制机制基于 AIMD（加法增大、乘法减小）闭环反馈、ECN（显式拥塞通知）、QCN（量化拥塞通知）等技术，但这些机制在数据中心场景下存在局限性。数据中心网络本质上是主板的延伸，而非传统的尽力而为网络。2. 核心问题A. 主机与网络能力失衡高性能网卡吞吐量远超 TOR 交换机处理能力过多资源向端倾斜，导致网络侧成为瓶颈端到端时延中，拥塞排队占比过大B. 传统控制机制的局限带内闭环反馈效率低下丢包是昂贵的手段，而非目的依赖确认反馈的控制方式不直观3. 设计目标消除拥塞排队时延实现微秒级收敛保持网络传输的高吞吐和低时延二、传统拥塞控制机制分析1. 现有技术栈A. AIMD 闭环反馈基于 TCP 的传统机制依靠丢包发现拥塞收敛速度慢（毫秒级）B. ECN 和 QCN用标记代替丢包本质仍是前向带内反馈未突破带内控制的局限C. PFC（基于优先级的流量控制）用网络排队时延换主机时延本末倒置的设计可能导致 Head-of-Line Blocking2. 问题根源graph TD A[传统拥塞控制] --> B[带内闭环反馈] B --> C[依赖确认反馈] C --> D[丢包或标记] D --> E[发送端检测] E --> F[调整发送速率] F --> G[收敛慢 毫秒级]传统机制的瓶颈在于：信息反馈路径长控制决策在端点网络层被动响应三、集中式拥塞控制方案1. 核心思想A. 控制面与数据面分离数据面：分布式路由转发控制面：集中式拥塞调度控制信息通过带外通道传输B. 拥塞疏导原则哪里发生拥塞，哪里负责：发送源抑制信号调度拥塞流量疏导而非丢包2. 架构设计graph TB subgraph 数据面 S1[发送端 1] S2[发送端 2] S3[发送端 3] SW1[交换机 1] SW2[交换机 2 - 拥塞点] R1[接收端 1] R2[接收端 2] end subgraph 控制面 CTRL[集中控制器] end S1 --> SW1 S2 --> SW1 S3 --> SW1 SW1 --> SW2 SW2 --> R1 SW2 --> R2 SW2 -.拥塞检测.-> CTRL CTRL -.源抑制/重路由.-> S1 CTRL -.源抑制/重路由.-> S2 CTRL -.源抑制/重路由.-> S33. 工作原理A. 拥塞检测交换机检测队列 buildup立即通知控制器B. 控制决策控制器拥有全局视图快速决策（微秒级）选择最优疏导方案C. 流量疏导方案 1：重新选路绕过拥塞点方案 2：802.3ad 链路聚合重分配方案 3：发送端源抑制四、时延优化策略1. 慢就是快A. 数据面时延增加人为引入固定时延（如 20us）或拉长线缆提高传播时延B. 控制面快速传播以准光速传播控制信息在出让的时延内完成收敛C. 效果分析端到端时延增加 20us消除毫秒级拥塞排队P99 时延优化sequenceDiagram participant S as 发送端 participant SW as 交换机 participant C as 控制器 participant R as 接收端 S->>SW: 数据包（延迟 20us） SW->>C: 拥塞通知（光速） C->>S: 疏导指令（光速） Note over S,R: 总收敛时间 < 20us2. 快就是慢A. 激进发送的后果造成网络同步拥塞拥塞排队（毫秒级）端到端时延（微秒级）占比巨大B. 业务影响吞吐剧烈波动时延抖动严重业务稳定性下降重连需要更多时间五、技术对比分析1. 传统方案 vs 集中式方案特性传统带内反馈集中式控制控制路径端到端端到控制面到端收敛速度毫秒级微秒级拥塞处理丢包/标记疏导全局视图无有复杂度低（累积）中（集中）2. 协议适用性分析A. TCP/IP设计用于广域互联网工作在毫秒级匹配通用操作系统调度周期不适合数据中心微秒级需求B. 数据中心需求PU（Processing Unit）互联短肥网络场景微秒级时延要求需要专用协议六、实施建议1. 控制面设计A. 实现方式独立控制网络或带外控制通道保证控制信息优先传输B. 复杂度控制不比 PFC 实现更复杂先搭建跑通，后标准化循序渐进优化2. 数据面优化A. 路径多样性准备多条备选路径快速重路由能力链路聚合灵活配置B. 时延管理引入可控时延为控制面收敛留出时间权衡总时延与拥塞消除3. 协议演进A. 短期兼容现有 TCP/IP通过 Gateway 转换B. 长期设计数据中心专用协议参考 PCI/PCIe 总线设计摆脱 TCP/IP 影子七、经验总结1. 设计原则A. 简洁性正确的思路应一气呵成避免过度复杂化复杂累积往往意…

流媒体拥塞控制与流控技术分析
type: item
date: 2026-01-17T23:40:14+00:00
description: 流媒体拥塞控制与流控技术分析一、概述1. 文章背景音视频流传输的核心挑战在于如何在网络动态变化的环境中保持稳定的用户体验。与传统块数据传输不同，流媒体传输对时延和抖动极为敏感，需要在毫秒级别进行速率调节，而非传统 TCP 的秒级调节。2. 核心观点工程方案是权衡的结果，而非最优解流媒体传输优先级：低时延 > 低抖动 > 吞吐量过度复杂的算法往往弄巧成拙，简单的 buffer 水位控制方案反而被忽视3. 文章来源dog250 博客 - 流媒体拥塞控制与流控二、流媒体传输的核心需求1. 优先级排序流媒体传输的质量指标按重要性排序：graph TD A[流媒体传输质量] --> B[低时延] A --> C[低抖动] A --> D[高吞吐] B --> E[网络质量好 高清晰度] C --> F[网络质量稍差 Buffer 吸收抖动] D --> G[网络质量差 降低码率]2. 不同网络场景的策略网络质量策略目标网络质量好保证低时延下的高清晰度最大化用户体验网络质量稍差使用少量 buffer 吸收抖动平衡时延与稳定性网络质量差降低码率，少发数据确保基本可用性3. 码率与网络的适配原则码率必须适应网络，而不是反过来。这一点与传统块数据传输的"尽可能多发一点"认知形成鲜明对比。三、拥塞控制的困境1. 时间尺度错配问题传统 TCP 拥塞控制设计用于块数据传输，在相对较大的时间尺度（秒级）上调速。这种设计在《TCP/IP 详解》卷 1 中有详细描述。然而，流媒体传输需要在毫秒级别甚至更小的时间尺度上调速。这种时间尺度的错配导致：传统拥塞控制响应太慢各种"错配算法"铺天盖地，试图弥补这一缺陷越复杂的算法，往往越容易弄巧成拙2. 发送端拥塞控制的演进现代 sender 端拥塞控制逐渐向上"紧贴"业务，强调与编解码结合。这种趋势的原因在于：流媒体传输逻辑和传输层拥塞控制难以解耦希望通过跨层优化获得更好的性能然而，作者指出这是一个值得反思的方向。如果关联编解码，事情会变得更复杂。更合理的做法是将时延的职责更多往下层压。3. 传输层与应用层的协同正确的协同方式应该是：sequenceDiagram participant 传输层 as 传输层拥塞控制 participant 应用层 as 应用层编解码 传输层->>应用层: 网络拥塞，建议降低码率 应用层->>应用层: 降低编码码率 应用层->>传输层: 已调整，发送速率降低 传输层->>应用层: 网络空闲，可以增加码率 应用层->>应用层: 提高编码码率 应用层->>传输层: 已调整，发送速率增加如果应用层不能及时响应传输层的信号，就会造成应用层时延抖动。这也是为什么流媒体拥塞控制如此困难的原因之一。四、被忽视的简单方案1. Buffer 水位控制方案一个简单但有效的解决方案十几年前就已经存在：在 sender 应用层和传输层之间铺垫一个固定 buffer，应用层持续观测 buffer 水位，调整编码速率，以保持 buffer 水平一直保持稳定。拥塞控制则完全交给传输层。这种方案的工作原理：graph LR A[应用层] -->|编码数据| B[固定 Buffer] B -->|数据| C[传输层拥塞控制] C -->|网络状态反馈| B B -->|水位反馈| A A -->|调整码率| B2. 为什么被唾弃这个简单有效的方案被普遍唾弃的原因令人深思：显式引入了时延与"极低时延"的宣传话术相违背简单是原罪，不够"高大上"3. 墨菲氏滴管的启示日常生活中有一个很好的例子解释持续观测 buffer 水位的原理：输液管中间的墨菲氏滴管。工作原理：不断调节滴管下游的流速滴管的水位在气压作用下保持恒定这就是典型的流控TCP 的端到端流控也采用了这种方法：Receiver 不断反馈 rcv buffer 的"水位" rwndSender 根据 rwnd 调整发送速率原理与墨菲氏滴管相同，只是依赖机制不同（TCP 依赖接收窗口反馈，而非气压）五、流控与拥塞控制的区别1. 核心差异特性流控拥塞控制作用范围逐跳行为端到端行为反馈路径链路层直接反馈端到端间接反馈适用场景数据中心网络广域网响应速度快速（微秒级）较慢（毫秒到秒级）2. 数据中心的流控优势流控的意义更多在逐跳行为，因此广域网不适合做流控，但数据中心能：数据中心网络拓扑相对可控链路距离短，反馈延迟低可以实现精细化的逐跳流控3. 递归流控网络如果把持续观测下层 buffer 水位的算法在分层网络各层间递归做下去，最终得到的就是一个 link 级的流控方案。graph TB A[源端] --> B[交换节点 1] B --> C[交换节点 2] C --> D[交换节点 3] D --> E[目的端] B -.流控.-> A C -.流控.-> B D -.流…