第129篇：园区网 QoS 基础：队列调度与拥塞管理
关键词：QoS、队列调度、拥塞管理、PQ、WRR、WFQ、FIFO、拥塞避免、RED、WRED、DiffServ
一、引言
在园区网中，不同类型的业务对网络有着截然不同的要求：语音通话需要低延迟（< 150ms），视频会议需要低抖动（< 30ms），在线游戏需要低延迟和稳定带宽，而文件传输则需要高吞吐量但对延迟不敏感。
当网络拥塞时，如果没有 QoS（Quality of Service，服务质量）机制，所有业务平等竞争带宽——大文件传输会占满出口带宽，导致语音断续、视频卡顿。QoS 通过队列调度、流量整形、流量监管等机制，为不同业务提供差异化的服务等级。
二、核心概念
2.1 QoS 服务模型
| 模型 | 说明 | 适用场景 |
|---|---|---|
| Best Effort（尽力而为） | 无差异化，所有报文平等对待 | 普通互联网 |
| IntServ（集成服务） | 每流保证，需要 RSVP 信令建立预留 | 军事/科研网络（极少使用） |
| DiffServ（差异化服务） | 基于 DSCP 粗粒度分类，逐跳行为 | 企业园区网（✅ 推荐） |
DiffServ 是目前最广泛使用的 QoS 模型。它在 IP 报文头部的 ToS 字节中使用 6 bit 的 DSCP（Differentiated Services Code Point）字段标记业务优先级，路由器根据 DSCP 值对报文进行不同的处理。
2.2 QoS 处理机制全景
| 处理阶段 | 位置 | 说明 |
|---|---|---|
| 流分类（Classification） | 入口 | 识别报文的业务类型（基于 ACL/DSCP/端口等） |
| 流标记（Marking） | 入口 | 根据分类结果设置 DSCP/802.1p 优先级 |
| 拥塞避免（Avoidance） | 队列满前 | 主动丢弃低优先级报文（RED/WRED） |
| 拥塞管理（Management） | 队列中 | 决定报文从哪个队列发送（PQ/WRR） |
| 流量监管（Policing） | 出口 | 丢弃或重标记超出速率限制的报文 |
| 流量整形（Shaping） | 出口 | 缓存超限报文，平滑输出速率 |
2.3 队列调度算法
| 算法 | 全称 | 调度策略 | 特点 |
|---|---|---|---|
| FIFO | First In First Out | 先进先出 | 最简单，无差异化，拥塞时所有业务平等排队 |
| PQ | Priority Queuing（严格优先级） | 高优先级队列非空时，不调度低优先级队列 | 关键业务（语音/视频）零等待，但可能"饿死"低优先级 |
| WRR | Weighted Round Robin（加权轮询） | 按权重轮询各队列 | 保证各队列的最低带宽，权重越大发送越多 |
| WFQ | Weighted Fair Queuing（加权公平队列） | 按权重 + 报文大小公平分配 | 考虑报文大小，小报文优先 |
| DRRW | Deficit Round Robin with Weight | 华为优化算法 | 综合考虑权重和带宽利用率 |
三、技术细节
3.1 PQ + WRR 混合调度模型
最常见的 QoS 调度模型是将 PQ 和 WRR 结合使用：
调度规则：
- 如果 PQ 区域（队列 6/7）中有报文，优先发送 PQ 队列
- 如果 PQ 区域为空，按 WRR 权重轮询 WRR 区域（队列 0/3/4）
- 保证语音/视频零延迟，同时保证其他业务最低带宽
3.2 WRED（加权随机早期检测）
WRED 是一种拥塞避免机制，在队列达到一定长度时主动丢弃低优先级报文，防止 TCP 全局同步：
| 队列长度阶段 | 行为 | 丢弃概率 |
|---|---|---|
| 低于最小阈值 | 不丢弃 | 0% |
| 最小阈值 ~ 最大阈值之间 | 按概率丢弃 | 0% ~ 100%（随长度递增） |
| 超过最大阈值 | 尾部丢弃（Tail Drop） | 100% |
WRED 的丢弃概率还受 DSCP 优先级影响：低优先级（DSCP 0）的报文在更低的队列长度就开始被丢弃，高优先级（DSCP 46）的报文允许更大的队列长度。
3.3 DSCP 与 802.1p 映射关系
| DSCP 值 | PHB 名称 | 802.1p | 业务类型 | 队列 |
|---|---|---|---|---|
| 46 (101110) | EF（加速转发） | 5/6 | 语音/实时视频 | PQ 队列 7 |
| 34 (100010) | AF41 | 4 | 视频会议控制 | PQ 队列 6 |
| 26 (011010) | AF31 | 4 | 关键业务数据 | WRR 队列 4 |
| 18 (010010) | AF21 | 2 | 普通业务数据 | WRR 队列 3 |
| 0 (000000) | BE（尽力而为） | 0 | 后台/普通流量 | WRR 队列 0 |
四、实战配置/案例分析
4.1 华为交换机 QoS 完整配置
# ========== 场景：为语音、视频和关键数据配置 QoS ==========
<HUAWEI> system-view
[HUAWEI] sysname Core-SW
# ============================
# 步骤 1：定义流分类（Traffic Classifier）
# ============================
# 语音流量分类（匹配 DSCP EF = 46）
[Core-SW] traffic classifier VOICE operator or
[Core-SW-traf-crs-VOICE] if-match car-dscp ef
[Core-SW-traf-crs-VOICE] quit
# 视频流量分类（匹配 DSCP AF41 = 34）
[Core-SW] traffic classifier VIDEO operator or
[Core-SW-traf-crs-VIDEO] if-match car-dscp af41
[Core-SW-traf-crs-VIDEO] quit
# 关键数据分类（匹配 DSCP AF31 = 26）
[Core-SW] traffic classifier CRITICAL_DATA operator or
[Core-SW-traf-crs-CRITICAL_DATA] if-match car-dscp af31
[Core-SW-traf-crs-CRITICAL_DATA] quit
# 默认流量分类（匹配所有其他流量）
[Core-SW] traffic classifier DEFAULT operator or
[Core-SW-traf-crs-DEFAULT] if-match acl 3001
[Core-SW] acl number 3001
[Core-SW-acl-adv-3001] rule 5 permit ip
[Core-SW-acl-adv-3001] quit
# ============================
# 步骤 2：定义流行为（Traffic Behavior）
# ============================
# 语音行为：映射到 WRR 权重最高的队列
[Core-SW] traffic behavior VOICE-BEH
[Core-SW-traf-beh-VOICE-BEH] queue wrr weight 100
# 权重 100，最高优先级
[Core-SW-traf-beh-VOICE-BEH] quit
# 视频行为
[Core-SW] traffic behavior VIDEO-BEH
[Core-SW-traf-beh-VIDEO-BEH] queue wrr weight 80
[Core-SW-traf-beh-VIDEO-BEH] quit
# 关键数据行为
[Core-SW] traffic behavior CRITICAL-BEH
[Core-SW-traf-beh-CRITICAL-BEH] queue wrr weight 40
[Core-SW-traf-beh-CRITICAL-BEH] quit
# 默认行为
[Core-SW] traffic behavior DEFAULT-BEH
[Core-SW-traf-beh-DEFAULT-BEH] queue wrr weight 10
[Core-SW-traf-beh-DEFAULT-BEH] quit
# ============================
# 步骤 3：定义流策略（Traffic Policy）
# ============================
[Core-SW] traffic policy QOS-CORE-POLICY
[Core-SW-trafficpolicy-QOS-CORE-POLICY] classifier VOICE behavior VOICE-BEH
[Core-SW-trafficpolicy-QOS-CORE-POLICY] classifier VIDEO behavior VIDEO-BEH
[Core-SW-trafficpolicy-QOS-CORE-POLICY] classifier CRITICAL_DATA behavior CRITICAL-BEH
[Core-SW-trafficpolicy-QOS-CORE-POLICY] classifier DEFAULT behavior DEFAULT-BEH
[Core-SW-trafficpolicy-QOS-CORE-POLICY] quit
# ============================
# 步骤 4：在接口应用流策略
# ============================
# 在出方向应用 QoS 策略（队列调度在出口生效）
[Core-SW] interface GigabitEthernet 1/0/1
[Core-SW-GigabitEthernet1/0/1] traffic-policy QOS-CORE-POLICY outbound
[Core-SW-GigabitEthernet1/0/1] quit
[Core-SW] interface GigabitEthernet 1/0/2
[Core-SW-GigabitEthernet1/0/2] traffic-policy QOS-CORE-POLICY outbound
# ========== 验证 ==========
[Core-SW] display traffic policy applied-interface GigabitEthernet 1/0/1 outbound
# 查看接口应用的 QoS 策略
[Core-SW] display qos queue statistics interface GigabitEthernet 1/0/1
# 查看队列统计信息
4.2 配置 WRED 拥塞避免
# ========== 配置 WRED ==========
# 在流行为中启用 WRED
[Core-SW] traffic behavior DEFAULT-BEH
[Core-SW-traf-beh-DEFAULT-BEH] wred dscp 0 queue 0 min-threshold 30 max-threshold 70
# 对 DSCP 0（BE）报文，队列 0，最小阈值 30%，最大阈值 70%
[Core-SW-traf-beh-DEFAULT-BEH] wred dscp 26 queue 4 min-threshold 40 max-threshold 80
# 对 DSCP 26（AF31）报文，队列 4，最小阈值 40%，最大阈值 80%
[Core-SW-traf-beh-DEFAULT-BEH] quit
# WRED 效果：
# - 队列长度 < 30%：不丢弃任何报文
# - 队列长度 30%~70%：对 DSCP 0 报文按概率丢弃
# - 队列长度 40%~80%：对 DSCP 26 报文按概率丢弃
# - 队列长度 > 70%：DSCP 0 报文 100% 丢弃
# - 队列长度 > 80%：DSCP 26 报文 100% 丢弃
# 低优先级报文更早被丢弃，保护高优先级报文
4.3 故障案例：视频会议卡顿，带宽利用率却不高
场景描述
某园区网部署了视频会议系统，但用户经常反映视频会议出现卡顿和丢帧。奇怪的是，网络监控显示出口带宽利用率只有 40%。
排查过程
# 步骤 1：检查 QoS 配置
[Core-SW] display traffic policy applied-interface GigabitEthernet 1/0/1 outbound
# 发现：QoS 策略存在，但视频流量（DSCP 46）被映射到了队列 0（BE）
# 而非高优先级队列
# 步骤 2：检查队列统计
[Core-SW] display qos queue statistics interface GigabitEthernet 1/0/1
# Queue 0 (BE): 利用率 85%（大量文件传输占用）
# Queue 7 (EF): 利用率 5%（语音/视频）
# 但视频流量实际上被放入了 Queue 0，而非 Queue 7
# 步骤 3：检查流分类匹配
[Core-SW] display traffic classifier VOICE
# 分类器匹配的是 DSCP EF（46）
# 但视频会议使用的 DSCP 是 AF41（34），而非 EF
# 步骤 4：检查视频流量的 DSCP 标记
# 通过抓包发现视频会议报文的 DSCP = 0（未标记）
根因分析
视频会议终端（如华为 eSpace Conference）发送的报文没有设置 DSCP 标记，DSCP = 0，被归类为"尽力而为"流量，放入低优先级队列。大文件传输同样 DSCP = 0，在低优先级队列中竞争带宽，导致视频卡顿。
处理
# 方案一：在视频终端上配置 DSCP 标记（源头解决）
# 在 eSpace Conference 客户端设置 QoS 标记为 AF41
# 方案二：在入口交换机上重标记（网络侧解决）
# 基于视频流量特征（如目的端口范围 16384~32767）重新标记 DSCP
[Core-SW] traffic classifier VIDEO-PORT operator or
[Core-SW-traf-crs-VIDEO-PORT] if-match acl 3010
[Core-SW] acl number 3010
[Core-SW-acl-adv-3010] rule 5 permit tcp destination-port range 16384 32767
[Core-SW-acl-adv-3010] quit
[Core-SW] traffic behavior VIDEO-MARK
[Core-SW-traf-beh-VIDEO-MARK] remark car-dscp af41
# 将匹配的视频流量重新标记为 AF41
[Core-SW-traf-beh-VIDEO-MARK] quit
[Core-SW] traffic policy VIDEO-MARK-POLICY
[Core-SW-trafficpolicy-VIDEO-MARK-POLICY] classifier VIDEO-PORT behavior VIDEO-MARK
[Core-SW-trafficpolicy-VIDEO-MARK-POLICY] quit
# 在接入端口入方向应用重标记策略
[Core-SW] interface GigabitEthernet 0/0/1
[Core-SW-GigabitEthernet0/0/1] traffic-policy VIDEO-MARK-POLICY inbound
五、总结
| 项目 | 说明 |
|---|---|
| DiffServ | 基于 DSCP 的差异化服务模型，企业网推荐 |
| PQ | 严格优先级，关键业务（语音/视频控制）使用 |
| WRR | 加权轮询，保证各队列最低带宽 |
| PQ + WRR 混合 | PQ 优先发送，PQ 为空时 WRR 轮询 |
| WRED | 主动丢弃低优先级报文，防止 TCP 全局同步 |
| 配置模型 | 流分类 → 流行为 → 流策略 → 接口应用 |
| 华为实现 | traffic classifier → traffic behavior → traffic policy |
| 注意 | 队列调度在出口方向生效，标记在入口方向生效 |
思考
-
PQ 严格优先级调度可能导致低优先级队列"饿死"（当高优先级队列持续非空时）。在什么场景下这个问题最严重？如何通过 WRR 权重配比来缓解？
-
WRED 的丢弃概率随队列长度递增。如果所有报文都是 TCP 报文，WRED 能否有效避免拥塞？如果大量报文是 UDP（如视频流），WRED 还有效吗？
-
DSCP 标记在 IP 报文头部，802.1p 在 VLAN 标签中。当报文从二层 VLAN 进入三层网络时，802.1p 到 DSCP 的映射关系如何保证一致性？
下篇预告：第130篇：流量限速：CAR（Committed Access Rate）