网络拥塞管理与拥塞避免技术详解
网络拥塞管理与拥塞避免技术详解
一、拥塞管理概述
1.1 拥塞的产生
拥塞是网络中最常见的问题之一。当高速链路向低速链路发送数据时,由于传输速率不匹配,数据会在出口处堆积,从而产生拥塞。
拥塞管理是指在网络发生拥塞时,进行管理和控制,合理分配网络资源的技术手段。通常采用队列调度技术实现差分转发,其基本流程为:
- 报文按一定的策略缓存到队列中
- 按一定的调度策略把报文从队列中取出
- 在接口上发送出去
1.2 拥塞的识别
设备如何识别发生了拥塞?判断标准非常简单:当出口报文缓存队列满了,即认为产生了拥塞。
1.3 队列的概念
队列是拥塞管理的核心载体,分为两类:
- 软件队列:用于在硬件队列已满时暂存报文
- 硬件队列:直接用于报文发送的队列,硬件队列满了即发生拥塞
1.4 带宽保证
带宽保证就是对报文流量进行量化、精细化的控制保障,确保关键业务能够获得所需的带宽资源。
1.5 队列的组成
一个完整的队列机制包含三个核心组件:
| 组件 | 功能说明 |
|---|---|
| 分类机制 | 决定报文进入哪个队列 |
| 插入机制 | 决定报文如何进入队列(尾丢弃/WRED) |
| 调度算法 | 决定队列中的报文如何被发送 |
二、基于队列的拥塞管理技术
2.1 FIFO(先进先出队列)
工作原理
FIFO 是最简单的队列调度方式,所有报文按照到达顺序进入同一个队列,先到的报文先被发送。
优点
- 缺省队列机制,配置简单,易于使用
- 处理简单,处理延迟小
缺点
- 所有报文同等对待,无法实现差异化传输
- 对实时业务的延迟得不到保障
2.2 PQ 调度(优先级队列)
工作原理
PQ 调度严格按照队列优先级的高低顺序进行调度。只有高优先级队列中的报文全部调度完毕后,低优先级队列才有调度机会。
优点
- 可对不同业务数据提供绝对的优先
- 对优先业务的报文带宽占用可以绝对优先
- 对实时业务的延迟可以得到保证
缺点
- 需要配置,处理速度慢
- 如果不对高优先级报文的带宽加限制,会造成低优先级报文得不到服务("饿死"现象)
- 高优先级报文过大时,会导致 TCP 全局同步
应用场景
适用于实时性流量场景,如语音、视频、直播等。将延迟敏感的关键业务放入高优先级队列,将非关键业务放入低优先级队列,确保关键业务被优先发送。
2.3 WRR 调度(加权轮询调度)
工作原理
WRR 在队列之间根据每个队列的权重来分配服务时间。调度时,设备根据每个队列的权值进行轮询,每调度一轮权值减一,权值减到 0 的队列不参加调度,当所有队列权值都减到 0 时,开始下一轮调度。
优点
- 避免了 PQ 调度时低优先级队列可能长时间得不到服务的缺点
- 队列为空时立即切换到下一个队列,带宽资源充分利用
缺点
- 低延时需求业务(如语音)得不到及时调度
- WRR 按报文个数调度,当队列平均报文长度变化时,无法按配置比例分配带宽(大报文获得的实际带宽大于小报文)
- 在带宽分配上没有体现区分服务的特点
2.4 DRR 调度(差额轮询调度)
工作原理
DRR 的实现原理与 WRR 基本相同,区别在于:
- WRR:按照报文个数进行调度
- DRR:按照报文长度进行调度
DRR 允许出现负权重,以保证长报文也能得到调度。但下次轮循时,负权重的队列将不参与调度,直到权重恢复为正。
优点
- 避免了 PQ 队列时低优先级报文长时间得不到服务的问题
- 避免了各队列长度不等或变化较大时,WRR 不能按配置比例分配带宽的问题
缺点
- 与 WRR 一样,无法为低延时需求业务(如语音)提供及时调度
- 在带宽分配上没有体现区分服务的特点
2.5 WFQ 调度(加权公平队列)
工作原理
WFQ 尽可能公平地分享网络资源。当不同队列中同时存在长报文和短报文时,优先给短报文队列分配更多带宽,优先获得调度,从而在总体上减少各个流报文间的抖动。
抖动的产生原因
抖动来自队列中报文长度的差异化和不确定性。例如:
- 第一个短报文前面可能排了一个长报文
- 第二个短报文前面可能排了三个长报文
WFQ 优先调度长度短的报文,从而有效减少了抖动,这被称为宏观优化。
分类机制
| 分类方式 | 说明 | 适用场景 |
|---|---|---|
| 基于"流"的分类 | SIP + DIP + Sport + Dport + TCP/UDP + Tos 进行哈希计算,hash 值为队列号 | 仅在 CBQ 调度 BE 队列时使用 |
| 基于优先级的分类 | 与 PQ、WRR、DRR 相同,基于 IP 优先级分类 | 接口启用 WFQ 时的默认分类 |
优点
- 优先调度短报文,减少各流之间的抖动
缺点
- 单纯使用 WFQ 时,分类机制与 PQ、WRR、DRR 相同,基于 IP 优先级分类,无法量化、精细化地保障带宽
2.6 组合调度方式
PQ、WRR、DRR 各有优缺点,可以搭配使用,相互弥补缺点:
- PQ + WRR
- PQ + DRR
- PQ + WFQ
配置示例(基于接口的队列配置)
# 创建队列模板
[Huawei] qos queue-profile X
# 将队列 7 配置为 PQ 调度,队列 0~6 配置为 DRR 调度
[Huawei-qos-queue-profile-X] schedule pq 7 drr 0 to 6
# 在接口上应用
[Huawei] interface gigabitethernet 0/0/1
[Huawei-GigabitEthernet0/0/1] qos queue-profile X
接口板卡支持情况、接口类型、支持的调度方式
LAN 侧接口板卡 PQ、DRR、PQ+DRR、WRR、PQ+WRR
WAN 侧接口板卡 PQ、WFQ、PQ+WFQ
二、基于流的拥塞管理与拥塞避免技术
一、基于流的拥塞管理:CBQ调度
1.1 CBQ概述
CBQ(Class-Based Queuing,基于类的加权公平队列) 是对WFQ功能的扩展,为用户提供了定义类的支持,是当前主流的拥塞管理队列。
1.2 CBQ工作原理
CBQ的工作流程如下:
- 首先根据以下规则对报文进行分类:
- IP优先级或DSCP优先级
- 输入接口
- IP报文的五元组(源IP、目的IP、源端口、目的端口、协议号)
- 不同类别的报文进入不同的队列
- 不匹配任何类别的报文,送入系统定义的缺省类
1.3 CBQ提供的四种队列
| 队列类型 | 全称 | 说明 | 带宽特性 |
|---|---|---|---|
| EF队列 | Expedited Forwarding(快速转发) | 满足低时延业务,带宽保证并监管 | 保证1M,最多1M(监管限速) |
| LLQ队列 | Low Latency Queuing(低延迟队列) | 适合语音业务,比EF效果更好,提供更低延时 | 带宽保证并监管 |
| AF队列 | Assured Forwarding(确保转发) | 满足关键数据业务,但不提供低时延服务 | 拥塞时保证1M,不拥塞可超过1M |
| BE队列 | Best Effort(尽力而为) | 不需要严格QoS保证的尽力发送业务 | 使用WFQ调度 |
重要提示:队列是实现拥塞管理的主要手段,是一种"保证关键业务体验不下降,劣化其他非关键业务体验"的技术。不建议将太多业务放入LLQ或EF队列中。
1.4 EF队列详解
EF队列具有以下特性:
- 高优先级:EF队列是具有高优先级的队列
- 灵活配置:一个或多个类别的报文可以被设定进入EF队列,且可以为不同类别的报文设定不同的带宽
- 优先调度:EF队列中有报文时,优先获得调度
- 拥塞控制:当接口发生拥塞时,EF队列以设置带宽限速,防止AF、BE队列得不到调度
- 带宽借用:当接口不再拥塞时,EF队列可以占用AF、BE队列的空闲流量,从而优先调度
1.5 AF队列详解
AF队列具有以下特性:
- 分类保障:每个AF队列分别对应一类报文,用户可以设定每类报文占用的带宽
- 按比例调度:在系统调度报文出队列时,按用户为各类报文设定的带宽将报文发送
- 剩余带宽共享:当接口有剩余带宽时,AF队列将按照权重分享剩余带宽
- 丢弃策略:队列长度拥塞时,默认采取尾丢弃
1.6 BE队列详解
BE队列具有以下特性:
- 兜底机制:当报文不匹配用户设定的所有类别时,将被送入系统定义的缺省类(BE队列)
- 调度方式:BE队列使用WFQ调度
- 丢弃策略:队列长度拥塞时,默认采取尾丢弃
二、拥塞避免技术
2.1 插入机制概述
插入机制决定报文如何进入队列。默认插入机制为尾丢弃(Tail Drop)。
2.2 尾丢弃(Tail Drop)
工作原理
由于每个队列长度有限,当某一队列已经被装满时,流量将会被缓存。缓存如果也满了,传统的处理方法将后续发往该队列的报文全部丢弃,直至拥塞解除。这种处理方法称为尾丢弃。
缺点一:无差别丢弃报文
当队列发生拥塞时,尾丢弃将会无差别地进行丢弃报文,很有可能会丢弃关键业务流量。
缺点二:引发TCP全局同步
TCP全局同步的定义:
由于拥塞,大量的TCP连接包被丢弃。由于TCP的滑动窗口机制,如果发送出去的TCP报文由于拥塞没有收到确认报文,TCP就会认为网络中产生了拥塞,从而降低滑动窗口的大小,使得整体流量同时减小。
当网络拥塞消除,发送方又能收到TCP的确认报文,即增加滑动窗口的大小。而后这些TCP连接又会在某一时刻同时出现流量高峰。如此反复,使网络流量忽大忽小,影响链路利用率,这就称为TCP全局同步现象。
TCP全局同步的核心原因:
- 尾丢弃没有差别的丢弃报文,造成所有TCP流的报文几乎在同一时刻丢弃
- TCP又几乎在同一时刻重传
- TCP窗口会在几乎同一时刻缩小,然后又几乎在同一时刻增大
- 这将造成所有TCP连接的流量以相同的"频率"持续震荡
缺点三:引发TCP流量"饿死"
TCP流量饿死的定义:
当队列发生拥塞时,由于TCP的滑动窗口机制,会减少窗口的大小,降低流量的发送。而UDP并没有滑动窗口机制,也不会减少流量,反而可能会占满整个队列,造成TCP流量"饿死"的现象。
导致TCP流量饿死的主要原因:尾丢弃无法对流量进行区分丢弃。
2.3 RED(早期随机检测)
工作原理
RED通过随机丢弃数据报文,让多个TCP连接不同时降低发送速度,从而在一定程度上避免了TCP全局同步的问题。
阈值门限机制
RED为每个队列的长度都设定了阈值门限,并规定:
| 队列长度范围 | 处理方式 |
|---|---|
| 小于低门限 | 不丢弃报文 |
| 大于高门限 | 丢弃所有报文 |
| 低门限与高门限之间 | 开始随机丢弃到来的报文 |
局限性
- RED依然无法对流量进行差异化丢弃,依然会造成TCP饿死的问题
- 虽然在一定程度上避免了TCP全局同步,但当流量超过门限时,仍可能出现TCP全局同步
2.4 WRED(加权随机检测)
工作原理
WRED基于丢弃参数(IP优先级)随机丢弃报文:
- 考虑到高优先级报文的利益,使其被丢弃的概率相对较小
- 可以为不同业务的报文指定不同的丢弃策略
- 通过随机丢弃报文,避免了TCP全局同步现象
阈值门限机制
WRED技术为每个队列的长度都设定了阈值上下限,并规定:
| 队列长度范围 | 处理方式 |
|---|---|
| 小于阈值下限 | 不丢弃报文 |
| 大于阈值上限 | 丢弃所有新收到的报文 |
| 阈值下限与上限之间 | 开始随机丢弃新收到的报文,队列越长,丢弃概率越高 |
WRED与RED的核心区别
| 对比项 | RED | WRED |
|---|---|---|
| 丢弃策略 | 无差别随机丢弃 | 可差别随机丢弃(基于IP优先级等参数) |
| TCP全局同步 | 一定程度上避免 | 有效避免 |
| TCP流量饿死 | 仍可能发生 | 有效避免 |
2.5 三种丢弃方式总结
| 丢弃方式 | 特点 | 说明 |
|---|---|---|
| 尾丢弃 | 无差别丢弃报文 | 传统方法,缺点最多 |
| RED | 无差别随机丢弃报文 | 一定程度上避免TCP全局同步 |
| WRED | 可差别随机丢弃报文 | 避免TCP全局同步 + 避免TCP饿死 |
核心理解:
- 尾丢弃 = 无差别的丢弃报文
- RED = 无差别随机丢弃报文
- WRED = 可差别随机丢弃报文
三、队列配置方式
3.1 基于接口的队列配置
直接在接口上配置队列调度,支持的调度方式包括:
| 调度方式 | 说明 |
|---|---|
| PQ | 优先级队列 |
| WRR | 加权轮询队列 |
| DRR | 差额轮询队列 |
| PQ+WRR | 优先级+加权轮询组合 |
| PQ+DRR | 优先级+差额轮询组合 |
| PQ+WFQ | 优先级+加权公平队列组合 |
3.2 基于MQC的队列配置
MQC(Modular QoS Command-line,模块化QoS命令行)是配置QoS策略的标准方法,主要用于配置CBQ。
配置CBQ的三要素:
| 组件 | 命令 | 作用 |
|---|---|---|
| 流分类 | traffic classifier |
定义匹配规则 |
| 流行为 | traffic behavior |
定义队列及带宽参数 |
| 流策略 | traffic policy |
绑定分类和行为 |
CBQ配置示例
# 1. 创建流分类(匹配语音流量)
[Huawei] traffic classifier voice
[Huawei-classifier-voice] if-match acl 3000
[Huawei-classifier-voice] quit
# 2. 创建流行为(配置LLQ队列)
[Huawei] traffic behavior voice
[Huawei-behavior-voice] queue llq bandwidth 1000
[Huawei-behavior-voice] quit
# 3. 创建流策略并绑定
[Huawei] traffic policy cbq-policy
[Huawei-trafficpolicy-cbq-policy] classifier voice behavior voice
[Huawei-trafficpolicy-cbq-policy] quit
# 4. 应用策略到接口
[Huawei] interface gigabitethernet 0/0/1
[Huawei-GigabitEthernet0/0/1] traffic-policy cbq-policy outbound
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐

所有评论(0)