介绍TCP的拥塞控制
文章目录
- 一、核心概念：拥塞窗口（cwnd）
- 二、TCP拥塞控制的4个核心阶段
- 1. 慢启动（Slow Start，SS）：快速“试探”网络容量
- 2. 拥塞避免（Congestion Avoidance，CA）：平稳“接近”网络上限
- 3. 拥塞检测与处理：发现拥塞后快速“退避”
- 4. 快速恢复（Fast Recovery，FR）：拥塞后“快速恢复”吞吐量
- 三、主流TCP拥塞控制算法对比
- 四、总结
TCP（传输控制协议）的拥塞控制，是指TCP通过动态调整发送端的发送窗口大小，避免网络链路因数据量过大而发生“拥塞”（即数据包丢失、延迟剧增），最终实现网络资源的合理利用与数据的稳定传输。其核心目标是：在不引发拥塞的前提下，尽可能最大化网络吞吐量。
一、核心概念：拥塞窗口（cwnd）
TCP拥塞控制的核心是拥塞窗口（Congestion Window，cwnd），它代表发送端在未收到确认（ACK）的情况下，最多能向网络发送的字节数（或数据包数）。
发送端实际的发送窗口大小，由“拥塞窗口（cwnd）”和“接收端通告窗口（rwnd，即接收端的缓存剩余空间）”中的较小值决定（实际窗口 = min(cwnd, rwnd)），确保既不拥塞网络，也不撑爆接收端缓存。
二、TCP拥塞控制的4个核心阶段
现代TCP（如TCP Reno、Cubic）的拥塞控制逻辑，主要分为以下4个阶段，本质是“先试探性增窗，遇拥塞则调窗，再逐步恢复”的循环：
1. 慢启动（Slow Start，SS）：快速“试探”网络容量
- 触发时机：TCP连接刚建立（如三次握手后），或拥塞后恢复时。
- 核心逻辑：拥塞窗口（cwnd）从初始值（通常为2-4个MSS，MSS是最大分段大小）开始，每收到一个ACK，cwnd就翻倍（指数级增长），快速接近网络的承载上限。
- 终止条件：当
cwnd增长到“慢启动阈值（Slow Start Threshold，ssthresh）”时，进入下一阶段。- 初始
ssthresh通常设为较大值（如65535字节），或由上一轮拥塞时的cwnd值决定。
2. 拥塞避免（Congestion Avoidance，CA）：平稳“接近”网络上限
- 触发时机：
cwnd达到ssthresh后。- 核心逻辑：为避免直接引发拥塞，
cwnd从“指数增长”转为线性增长——每收到一个往返时间（RTT）的ACK，cwnd只增加1个MSS（而非翻倍），缓慢接近网络的实际容量。- 目标：在不触发拥塞的前提下，逐步提升吞吐量。
3. 拥塞检测与处理：发现拥塞后快速“退避”
当网络发生拥塞时（主要通过“超时重传”或“快速重传”两种信号判断），TCP会立即调整
cwnd和ssthresh，避免拥塞加剧：
| 拥塞信号 | 判断依据 | 处理逻辑（以主流的TCP Reno为例） |
|---|---|---|
| 超时重传（Timeout） | 发送端未在重传超时时间（RTO）内收到ACK，认为数据包丢失（大概率是严重拥塞） | 1. 将ssthresh设为当前cwnd的1/2；2. 将 cwnd重置为初始值（如1个MSS）；3. 重新进入“慢启动”阶段，从头试探网络。 |
| 快速重传（Fast Retransmit） | 短时间内收到3个相同的“重复ACK”（Duplicate ACK），认为数据包丢失（轻微拥塞，网络仍有部分连通性） | 1. 立即重传丢失的数据包（无需等待RTO）； 2. 将 ssthresh设为当前cwnd的1/2；3. 将 cwnd设为新的ssthresh，直接进入“拥塞避免”阶段（跳过慢启动，快速恢复）。 |
4. 快速恢复（Fast Recovery，FR）：拥塞后“快速恢复”吞吐量
- 触发时机：仅在“快速重传”后（即收到3个重复ACK时）触发，是对“拥塞避免”的优化。
- 核心逻辑：
- 重传丢失的数据包后，
cwnd从ssthresh开始，每收到一个重复ACK，cwnd就增加1个MSS（快速补充因丢失而“空缺”的窗口）；- 当收到第一个“新的ACK”（确认丢失数据包及后续所有数据包）时，说明拥塞已缓解，将
cwnd重置为ssthresh，回到“拥塞避免”阶段，继续线性增长。
三、主流TCP拥塞控制算法对比
不同场景下，TCP会采用不同的拥塞控制算法，核心差异在于“拥塞避免”和“恢复”阶段的策略：
| 算法 | 核心特点 | 适用场景 |
|---|---|---|
| TCP Reno | 经典算法，包含“慢启动、拥塞避免、快速重传、快速恢复”四阶段，逻辑简单稳定 | 早期互联网、通用场景 |
| TCP Cubic | 基于“三次函数”调整cwnd，拥塞后恢复更快，吞吐量更高（非指数/线性增长） | 现代Linux默认算法、高带宽延迟网络（如云计算、长距离通信） |
| TCP BBR | 基于“带宽和延迟乘积（BDP）”估算网络容量，而非依赖丢包信号，适合高带宽低延迟场景 | 谷歌云、视频流、大文件传输 |
| TCP Vegas | 基于“RTT变化”预判拥塞（而非等待丢包），更早调窗，减少延迟 | 对延迟敏感的场景（如实时通信） |
四、总结
TCP拥塞控制的本质是“试探-反馈-调整”的闭环：
- 通过“慢启动”快速接近网络容量；
- 通过“拥塞避免”平稳提升吞吐量；
- 通过“超时/快速重传”检测拥塞，并快速退避；
- 通过“快速恢复”减少拥塞后的性能损失。
这一机制让TCP能自适应不同网络环境（如家庭宽带、数据中心、跨洋链路），在可靠性与吞吐量之间取得平衡，是互联网稳定运行的核心保障之一。