带宽评估是拥塞控制的起点，其核心是准确估计瓶颈带宽（BtlBw）以使inflight数据量贴近BDP（BtlBw×RTT），避免丢包或带宽浪费；传统算法如Reno通过丢包间接反推，BBR则主动探测BtlBw与RTprop，高估导致缓冲区溢出，低估造成吞吐不足，且必须结合RTT理解BDP才能适配不同网络场景。

带宽评估是网络传输与拥塞控制的起点，不是孤立测速，而是为动态调节发送行为提供依据。它直接影响拥塞窗口（cwnd）的初始值、增长节奏和稳定上限——换句话说，错估带宽，后续所有拥塞控制动作都可能失准。

带宽评估如何支撑拥塞控制

拥塞控制的核心目标是让 inflight 数据量尽量贴近 BDP（带宽 × RTT），既填满管道又不溢出缓冲区。而BDP中的“带宽”不是链路标称值，而是实测瓶颈带宽（BtlBw）。因此，准确评估当前路径的真实可用带宽，是避免进入“缓冲受限区”（丢包区）的前提。

• 传统基于丢包的算法（如Reno、Cubic）间接反推带宽：通过丢包触发窗口回退，再试探性恢复，本质上用丢包作为带宽超限的信号
• 现代模型驱动算法（如BBR）则主动测量：周期性发送probe数据，分析ACK返回时间与速率变化，直接估算BtlBw和RTprop
• 若带宽被高估（例如把瞬时突发误判为持续能力），cwnd会过快扩张，导致buffer堆积、排队延迟上升，最终丢包
• 若带宽被低估（例如因短暂干扰误判链路变差），cwnd长期偏小，无法充分利用链路，吞吐率下降

常见带宽评估方法及其局限

不同算法采用不同策略获取带宽线索，没有一种方式在所有场景下都可靠：

• ACK到达速率法：统计单位时间内收到的ACK字节数，反映接收方实际交付速率。简单但易受接收端应用读取慢、延迟确认（Delayed ACK）干扰
• 最小RTT追踪法：持续记录最小往返时延（min_rtt），结合最近发送速率估算BDP下界。对RTT抖动敏感，长肥管道中min_rtt难收敛
• 速率采样+滤波法（BBR核心）：在ProbeBW阶段以略高于当前估计速率发送，观察是否引发排队延迟增长；用低通滤波器平滑噪声。需足够探测周期，启动慢
• 丢包率映射法（Cubic等）：将丢包率映射为拥塞强度，间接调整窗口目标值。在轻丢包或零丢包高缓冲场景完全失效

为什么带宽评估必须结合RTT理解

单独谈“带宽”容易误导。真正决定传输效率的是BDP——它把带宽和传播时延绑在一起。例如：

• 一条100 Mbps、RTT=10 ms的链路，BDP = 100×10⁶ × 0.01 = 1 MB，意味着约1 MB数据可同时在链路上“流动”
• 同带宽但RTT=200 ms（如卫星链路），BDP飙升至20 MB，若cwnd仍按短RTT逻辑设置为64 KB，链路利用率不足0.3%
• 此时拥塞控制若只盯着丢包，很可能长期处于“应用受限区”，根本没触发拥塞，却严重浪费带宽
• BBR正是通过分离RTprop（传播时延）和BtlBw（瓶颈带宽）两个维度，才能在高BDP网络中稳定逼近理论吞吐

实际部署中的关键注意事项

带宽评估不是一劳永逸的静态配置，而是一个持续适应的过程：

• 应用层突发流量、共享链路上其他流抢占、无线信道质量波动，都会导致BtlBw动态变化，评估机制需有足够响应速度
• 内核协议栈默认参数（如初始cwnd=10 MSS）隐含了对典型带宽的假设，在低带宽IoT或超高带宽数据中心场景中往往不匹配
• 中间设备（如运营商NAT、防火墙）可能篡改TCP时间戳或ACK序列，干扰基于RTT/速率的测量，导致评估漂移
• QUIC等新协议将拥塞控制逻辑上移至用户态，使带宽评估更灵活（可定制滤波器、多模型切换），但也要求应用开发者理解其底层约束