拥塞控制方法？

访客网络编程 2026-06-06 12:06:35 2

本文目录导读：

拥塞控制是网络传输中至关重要的一环,目的是在网络负载过高时，避免数据包大量丢失和传输延迟急剧增加，从而保证网络的稳定性和公平性。

拥塞控制方法通常可以分为两大类：端到端拥塞控制（主要由发送端实现，如TCP）和网络辅助拥塞控制（需要路由器等中间设备的支持）。

以下是主要的拥塞控制方法及其核心原理：

经典的端到端拥塞控制（基于丢包检测）

这是TCP协议最传统、应用最广泛的方法，它通过检测“数据包丢失”作为网络发生拥塞的信号。

慢启动
- 目标：探测网络可用带宽的初始值。
- 机制：连接建立时，拥塞窗口(cwnd)初始值很小（通常为1个MSS），每收到一个ACK，cwnd翻倍，因此cwnd呈指数增长，直到发生丢包或达到慢启动阈值(ssthresh)。
拥塞避免
- 目标：在接近网络容量时缓慢增加窗口，避免拥塞。
- 机制：当cwnd >= ssthresh时，进入拥塞避免阶段，每收到一个ACK，cwnd增加 1/cwnd（即每个RTT增加1个MSS），窗口呈线性增长。
快速重传
- 目标：快速恢复丢失的数据包，不必等待超时。
- 机制：当发送端收到 3个重复的ACK（表示后续数据包已到达，但序号为X的数据包丢失），立即重传该数据包，而不必等待重传计时器超时。
快速恢复
- 目标：在检测到单个丢包后，维持网络吞吐量，避免直接回到慢启动。
- 机制：发生快速重传后：
  - ssthresh = cwnd / 2
  - cwnd = ssthresh + 3（保存已收到的重复ACK）
  - 之后每收到一个重复ACK,cwnd+1
  - 当收到新数据的ACK时,cwnd = ssthresh（进入拥塞避免）。

经典算法的演进：

这种方法不再等待丢包,而是通过监测RTT（往返时间）或延迟变化来预判拥塞。

Vegas：比较期望吞吐量与实际吞吐量，如果实际吞吐量低于期望值，说明网络开始拥塞，主动减少窗口。
BBR (Bottleneck Bandwidth and Round-trip propagation time)：由Google开发，是当前非常先进的算法。
- 思路：不依赖丢包，而是探测瓶颈带宽(BBR.BW)和最小RTT。
- 工作模式：通过周期性探测（ProbeBW、ProbeRTT等）来保持报文在管道中正好填满瓶颈链路，但又不排队，这使得BBR在高带宽（如光钎）和有一定丢包率（如无线网络）的环境下，能获得极高的吞吐量和极低的延迟。

发送端不再依赖ACK来驱动发送,而是基于一个计算出的发送速率来发送数据包。

需要网络设备（如路由器、交换机）参与，向发送端发送明确的拥塞信号。

显式拥塞通知
- 路由器在IP头中设置CE（拥塞经历）标记。
- 接收端将该标记反馈给发送端（通过在TCP头中的ECN标志）。
- 发送端收到ECN后,像对待丢包一样降低窗口。
基于速率的拥塞控制（如 ATM的ABR）
- 交换机根据当前队列长度计算一个允许的速率（ER），并将其填入一个控制帧中。
- 发送端严格按照该速率发送,这在复杂网络（如ATM网络）中实现，但TCP/IP网络中较少应用。

算法	核心信号	适用场景	优点	缺点
CUBIC	丢包	通用，高带宽长延迟	Linux默认，曲线平滑，公平性好	在高丢包率链路（如无线）性能下降
BBR	带宽 & RTT	大带宽、长延迟、高丢包	高吞吐，低延迟	对Buffer不足的网络不友好（可能饿死），公平性控制较复杂
Vegas	RTT	低延迟、无丢包	延迟极低，主动避免拥塞	在竞争环境下容易被其他算法“欺负”
Reno	丢包	经典，基础	简单，标准	丢包恢复慢，不适用于高BDP网络
DCTCP	ECN	数据中心网络	低队列积压，低延迟	需要交换机支持ECN