拥塞控制是什么
发送速率由一个叫拥塞窗口的变量决定：连接刚开始时窗口快速翻倍以探测可用带宽，接近上限后改为每轮小幅增长，出现丢包则迅速回退。这套机制的目的是在跑满链路的同时不把中间网络压垮。它是端到端算法，双方各自运行，路径上的设备不参与——因此同一条链路上可能有多种算法共存，表现出的吞吐特性也各不相同。
基本信息
| 核心变量 | 拥塞窗口，决定同一时刻能有多少未被确认的数据 |
|---|---|
| 定位 | 端到端算法，运行在发送方 |
| 四个阶段 | 慢启动、拥塞避免、快速重传、快速恢复 |
| 常见算法 | 常见系统默认使用一种，跨境高丢包链路更常用另一种 |
| 观察方式 | 内核参数查看当前算法，连接工具查看窗口与重传 |
四个阶段
| 阶段 | 触发条件 | 核心动作 |
|---|---|---|
| 慢启动 | 连接开始或长时间空闲后 | 窗口从较小初值按轮次快速翻倍 |
| 拥塞避免 | 窗口超过慢启动阈值 | 每轮小幅增长，线性探测上限 |
| 快速重传 | 收到多个重复确认 | 不等超时就立即重发疑似丢失的数据 |
| 快速恢复 | 快速重传之后 | 把阈值与窗口同时下调，继续传输 |
典型使用场景
- 评估跨地域传输效率：高延迟链路受窗口增长方式影响明显
- 排查吞吐上不去：确认是否频繁丢包导致窗口反复回退
- 容量评估：理解为何新连接起步阶段带宽利用率偏低
- 配置优化：在明确场景下更换算法以适配链路特性
- 抓包分析：观察窗口变化与重传的关系
查看算法与窗口
查看算法与窗口
sysctl net.ipv4.tcp_congestion_control # 当前使用的算法
sysctl net.ipv4.tcp_available_congestion_control # 系统支持哪些算法
ss -ti | head -20 # 观察连接的往返时延、拥塞窗口与重传计数排查要点
- 吞吐偏低时先看重传率，频繁重传会让窗口一直停留在低位
- 不要只看带宽总量，延迟偏高时窗口增长需要更多轮次才能跑满
- 更换算法属于全局配置，改动前先在非核心服务上验证效果
拥塞控制对丢包有强假设：它把丢包当作拥塞信号并主动降速。这在无线与跨境链路上会误判——链路本身有随机丢包但并不拥塞，于是吞吐被无谓压低，这也是另一种算法在这些场景更受欢迎的原因。
链路不丢包但排队严重时，基于丢包的算法会把延迟堆得很高却仍不降速，表现为「带宽跑满但体验卡顿」。这类问题需要主动队列管理配合，单纯加大缓冲只会让延迟更长。