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. 可预期性缺省算法的收敛速度一定是可预期的，线性系统最符合这个期望。D. 稳定性缺省算法一定是稳定的，没有任何正反馈可将系统带到崩溃状态。E. 兼容性缺省算法一定经历了广泛使用和长期验证，具备设备兼容性。F. 保守性缺省算法一定是保守的。2. BBR 的定位graph LR A[BBR 算法] --> B{网络环境判断} B -->|稳定长肥管道| C[表现优异] B -->|抖动不受控| D[不如预期] B -->|无线场景| E[甚至无法预期] C --> F[特定场景优化] D --> F E --> F style C fill:#c8e6c9 style D fill:#fff9c4 style E fill:#ffcdd2 style F fill:#e1f5ffBBR 属于特定网络场景的优化算法：在稳定的长肥管道，BBR 无疑是福音在抖动不受控的网络环境比如无线场景，BBR 就不如预期，甚至无法预期五、标准化进程1. BBR 的迭代A. BBRv1用激进的方式应对 buffer 增长只是个 demo能进 Linux 内核但进不了 RFCB. BBRv2开始考虑公平性和保守性只有这样才会使 BBR 具备普遍性而被标准化C. BBRv3依然停留在 draft 阶段尚未被正式标准化2. L4S 的标准化在 L4S（Low Latency Low Loss Scalable Throughput）已被标准化的今天，BBR 可能真的只是一个引子。谁说 AIMD（Additive Increase Multiplicative Decrease）不能做高带宽低时延，配合 ECN（Explicit Congestion Notification）就行。AIMD + ECN 是多么的简单，线性可控。六、实践启示1. 测试与验证A. 避免 tc + iperf 的简单测试不要使用过于简化的测试方法来评估算法性能，这会得出误导性的结论。B. 参考实际部署经验参考如 Dropbox 等公司在实际生产环境中的部署经验，了解算法在真实网络环境中的表现。C. 多维度评估从稳定性、公平性、兼容性、适用场景等多个维度综合评估算法。2. 选择建议A. 缺省使用 CUBIC对于大多数场景，继续使用 CUBIC 作为缺省算法是明智的选择。B. 特定场景使用 BBR在以下场景可以考虑使用 BBR：稳定的长肥管道网络高带宽长延迟网络丢包率较高的网络数据中心内部网络C. 谨慎评估在以下场景需要谨慎评估 BBR 的效果：无线网络环境抖动较大的网络多种拥塞控制算法共存的环境对公平性要求较高的环境七、总结1. 核心观点虽然 BBR 在某些情况下表现优异，它没有取代 CUBIC 的原因主要包括：A. 标准化BBR 尚未完成标准化进程，仍处于 draft 阶段。B. 稳定性BBR 作为非线性系统，其稳定性难以保证，可能引发拥塞崩溃。C. 公平性BBR 无法自证在与自身或异构流量共存时的公平性。D. 成熟度BBR 缺乏像 CUBIC 那样广泛的实际部署验证。E. 兼容性BBR 在某些网络环境下表现不佳，甚至无法预期。F. 网络环境多样性真实网络环境复杂多变，BBR 无法像 CUBIC 那样普适。2. 未来展望随着 BBR 的发展和进一步的优化，可能有机会在更多系统中被采用。但作为缺省算法，CUBIC 的地位在可预见的未来难以被撼动。L4S 的标准化为高带宽低时延传输提供了另一种可能，AIMD + ECN 的方案展示了传统算法的潜力。正如作者所言，如果哪天来自某大厂的经理力排众议非要把 BBR 设置为 Linux 内核的缺省算法，也是说不准的事。但技术选择应该基于理性分析，而非市场宣传或个人偏好。参考资料BBR 为什么没有替代 CUBIC 成为 Linux 内核缺省算法Evaluating BBRv2 on the Dropbox Edge Network
使用 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 pandas as pd data_list = [] data_list.append((100, 104, 98, 102)) data_list.append((102, 108, 88, 96)) data_list.append((96, 100, 85, 93)) data_list.append((93, 115, 93, 105)) data = np.array(data_list).reshape(-1, 4) df = pd.DataFrame(data, columns=['Open', 'High', 'Low', 'Close']) dates = pd.date_range(start='2023-01-01', periods=len(df), freq='D') df.index = datesB. 图表绘制market_colors = mpf.make_marketcolors(up='g', down='r') style = mpf.make_mpf_style(marketcolors=market_colors) mpf.plot(df, type='candle')C. 输出结果绘制完成后，将生成标准的蜡烛图，其中：绿色实体表示收盘价高于开盘价（阳线）红色实体表示收盘价低于开盘价（阴线）3. BBR 数据处理A. 数据转换将 BBR 的吞吐率数据转换为蜡烛图格式：Open：周期开始时的带宽High：周期内的最大带宽Low：周期内的最小带宽Close：周期结束时的带宽B. 时间窗口选择选择合适的时间窗口对数据分组：过短：细节过多，难以识别趋势过长：细节丢失，类似移动平均建议根据实际场景调整，通常可以设置为 RTT 的整数倍。六、扩展应用1. Sigmoid 函数预处理当有多个指标可以分析时，可以使用 sigmoid 函数进行特征预处理。Sigmoid 函数普遍运用于 AI 大模型，将值域映射到固定区间（一般 0 到 1），通过设定激发阈值来获得输出或不输出。但在只有一个指标（如吞吐率散点图）的情况下，蜡烛图是更直观的分析方法。2. 与其他方法对比方法优点缺点适用场景移动平均平滑噪声，显示趋势滞后，丢失细节长期趋势分析算术平均计算简单丢失所有波动信息静态统计蜡烛图保留细节，显示趋势需要人工识别模式动态性能分析3. 实际应用场景网络性能监控：实时分析链路带宽变化故障诊断：识别拥塞原因和类型容量规划：分析带宽使用趋势算法优化：评估 BBR 参数调整效果七、总结蜡烛图为 BBR 拥塞控制算法的性能分析提供了一种直观且信息丰富的方法。相比传统的移动平均或算术平均，蜡烛图能够同时保留趋势和细节，通过实体长度、上下影线等特征识别各种网络状态。结合 Python 的 mplfinance 库，可以轻松实现 BBR 数据的蜡烛图可视化，为网络性能分析和故障排查提供有力工具。参考资料K 线图下的 BBR
流媒体拥塞控制与流控技术分析一、概述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. 简洁性正确的思路应一气呵成避免过度复杂化复杂累积往往意味着方向错误B. 本质思考数据中心网络是主板的延伸不是尽力而为的互联网需要根本性创新而非修补2. 常见误区A. 拿来主义直接套用广域网机制为兼容性牺牲性能膏药贴了一层又一层B. 局部优化只关注端点性能忽视网络整体本末倒置（如 PFC）3. 技术启示控制面与数据面分离是趋势集中式控制在特定场景更优时延是相对的，关键在于消除拥塞微秒级优化需要系统性思考参考资料数据中心的拥塞控制 - dog250 的 CSDN 博客
流媒体拥塞控制与流控技术分析一、概述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 -.流控.-> C E -.流控.-> D这相当于将大量墨菲氏滴管级联或组成胖树结构，仍能观测到稳定平衡水位的现象。每一个滴管都维持着稳定的平衡水位。结论：纯流控网络天然无拥塞，不再需要拥塞控制。六、现有技术方案1. InfiniBandInfiniBand 是一个 link 级流控方案实例：实现了真正的逐跳流控基于信用机制的流量控制在高性能计算领域有广泛应用2. RoCEv2RoCEv2（RDMA over Converged Ethernet version 2）是一个松散版本：采用 PFC（Priority Flow Control）Pause 帧在网络已经拥塞时迅速阻滞部分流量不是全程观测并平滑阻滞RoCEv2 的流控策略类似于：显示"剩余车位 2"的停车场入口排队等待几乎一定比显示"车位已满"的入口更严重七、系统动力学视角1. 系统动力学模型传输网络非常适用系统动力学建模。系统由以下元素组成：源：数据的产生点汇：数据的消费点存量：系统中的积累（如 buffer、队列）流量：存量之间的转移（数据传输速率）核心原则：流量刻画各存量水平之间的反馈。2. 存量决定行为系统动力学模型强调，存量决定行为，流量负责改变行为，但千万不要试图让流量决定行为。例子：一个屋子的室温是空调的设置决定的，而不是开窗关窗决定的。3. 流量关系的谬误善作计量者总是试图发现各种流量之间的关系，并以此为定论决定此后的流量，但这是徒劳的。他们不过在寻找一些不存在或至少不稳定的关系。事实：任何一个系统的流量和其它流量之间都没有稳定的关系，流量只受存量影响。4. 在网络传输中的应用数据和 buffer 就是存量，而 link 级的流控就是流量引起的反馈。端到端传输控制相当于丢失了很多反馈，那也就只好由端自行发现并处理异常（丢包或时延抖动）了，这就是拥塞控制。graph LR A[Link 级流控] -->|直接反馈| B[存量] C[端到端拥塞控制] -->|间接反馈| B B -.丢失很多反馈.-> C八、工程实践中的权衡1. 权衡的本质作者反复强调一个观点：由于交易的本质，设计和优化的过程本就是不断权衡的过程。优化的收益需要放弃一些别的收益，最终的工程方案一定不是最优的，而是足够好的。2. 流媒体传输的权衡对于流媒体传输：指标危害程度应对策略抖动危害更大使用 buffer 吸收时延次要影响接受少量 buffer 时延吞吐优先级最低码率适应网络稍微的 buffer 时延便可以吸收大量抖动，这种基于交换的解法也足够简单。3. 简单的价值简单是原罪的文化倾向导致了许多过度设计的方案。事实上，简单的方案往往更可靠、更易维护、更易理解。九、总结与启示1. 核心要点总结流媒体传输需要在毫秒级别进行速率调节过度复杂的拥塞控制算法往往弄巧成拙Buffer 水位控制是简单有效的方案，但被忽视流控适合数据中心，拥塞控制适合广域网系统动力学视角有助于理解网络传输的本质2. 工程实践的启示不要盲目追求"极低时延"的宣传话术接受权衡，追求"足够好"而非"最优"重视存量（buffer）的作用，而非仅仅关注流量简单的方案往往更有价值3. 对未来设计的建议流媒体传输系统设计应该：优先考虑 buffer 水位控制方案将时延职责更多分配到传输层应用层专注于根据反馈调整码率避免过度复杂的跨层优化在数据中心环境考虑 link 级流控参考资料流媒体拥塞控制与流控 - CSDN博客