网络拥塞管理与拥塞避免技术详解

一、拥塞管理概述

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的工作流程如下:

  1. 首先根据以下规则对报文进行分类:
    • IP优先级或DSCP优先级
    • 输入接口
    • IP报文的五元组(源IP、目的IP、源端口、目的端口、协议号)
  2. 不同类别的报文进入不同的队列
  3. 不匹配任何类别的报文,送入系统定义的缺省类

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
Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐