拥塞控制是什么
发送方用拥塞窗口控制同时未被确认的数据量：起步阶段指数增长，达到阈值后转为线性增长，遇到丢包就收缩。Linux 默认使用 CUBIC，也可以切换到 BBR 等算法。拥塞参数本身不会出现在抓包里，只能通过发送节奏与丢包后的反应间接推断。
基本信息
| 控制对象 | 发送方可同时未确认的数据量 |
|---|---|
| 常见算法 | CUBIC（Linux 默认）、BBR、Reno 等 |
| 观测方式 | 发送速率曲线与丢包后的窗口变化 |
| 相关字段 | 重传标注、吞吐曲线、往返时延 |
| 调参影响 | 不同算法对时延与丢包的敏感度差异明显 |
典型使用场景
- 解释为什么链路没有明显拥塞但吞吐上不去
- 评估丢包发生后业务恢复的快慢
- 对比不同算法在长距离链路上的表现
- 判断速率曲线的锯齿形态是否属于正常的拥塞循环
- 为跨地域传输选择更合适的发送端配置
观察线索
观察线索
起步阶段快速上涨 # 慢启动阶段
丢包后发送骤减 # 拥塞窗口收缩
RTT 上升仍持续加大发送 # 可能为对丢包不敏感的算法
速率呈规律锯齿 # 收缩与恢复循环
长期低速率 # 窗口或路径受限线索与结论
| 观察线索 | 可能结论 | 说明 |
|---|---|---|
| 起步快速上涨 | 处于慢启动阶段 | 属于正常行为 |
| 丢包后发送骤减 | 典型的拥塞响应 | 收缩与恢复循环 |
| 时延上升仍加大发送 | 可能使用 BBR 类算法 | 对丢包不如传统算法敏感 |
| 速率长期上不去 | 窗口或路径受限 | 结合窗口与往返时延判断 |
丢包不等于拥塞：链路误码与限速也会触发类似反应，需要看丢包的分布与位置。
更换拥塞算法前先确认瓶颈在哪里，否则容易把问题掩盖过去。
补充要点
- 把吞吐曲线与往返时延曲线叠在一起看，能区分拥塞响应与路径本身变慢
- 规律性的速率锯齿通常说明机制在正常工作，不必当作故障
- 发送端与接收端部署在不同区域时，算法选择对体验的影响会被时延放大
- 调优后要用同样的业务场景复测，指标口径保持一致
抓包只能观察外部行为，算法参数需要结合发送端配置与内核信息一起判断。