📚 课程目录第4章队列调度机制

4. 队列调度机制

当报文进入接口输出队列后，真正决定“谁先出、谁后出、每次出多少”的，是队列调度机制。拥塞管理解决的是排队与出队顺序问题，而调度算法决定了不同业务在同一出接口上的带宽分配、时延上界和抖动表现。理解 FIFO、PQ、CQ、WFQ、CBWFQ、LLQ 六种机制的差异，是设计 QoS 策略的核心。

一、从“无区分”到“有保障”的演进逻辑

FIFO（First In First Out）是最基础的队列模型：所有报文进入同一个队列，按到达顺序出队。它实现简单、开销极低，但没有任何区分能力——语音报文和批量下载报文在同一队列中竞争，一旦拥塞，时延和抖动完全不可控。因此 FIFO 只适合无 QoS 需求或带宽远大于业务峰值的场景。

PQ（Priority Queuing）引入高、中、普通、低四个优先级队列，调度器严格按优先级从高到低服务：只有高优先级队列为空时，才处理下一级。这保证了关键业务的低时延，但存在“低优先级饿死”风险——若高优先级流量持续占满带宽，低优先级队列可能长期得不到调度。

CQ（Custom Queuing）采用轮询思路，可配置 16 个队列，每个队列分配一个字节配额。调度器依次轮询各队列，每轮发送不超过配额的字节数。它避免了饿死，但无法提供严格的时延保证，且轮询顺序固定，对时延敏感业务不够友好。

WFQ（Weighted Fair Queuing）基于流进行自动分类，按 IP 优先级或五元组划分流，权重由优先级决定。低优先级流获得较少带宽，高优先级流获得较多带宽，同时保持各流之间的公平性。WFQ 适合中小型网络，但无法为特定业务预留固定带宽，也不支持对自定义类别的精确控制。

CBWFQ（Class-Based Weighted Fair Queuing）在 WFQ 基础上引入模块化 QoS 命令，允许管理员用 class-map 定义业务类别，并为每个类分配保证带宽（bandwidth 命令）和队列限制。它解决了 WFQ 无法自定义类别的问题，但所有类别仍共享同一调度器，没有绝对优先级，因此对语音这类需要严格低时延的业务保障不足。

LLQ（Low Latency Queuing）在 CBWFQ 基础上增加一个优先队列（priority 命令），该队列在拥塞时优先调度，且通常配合监管（policing）限制其最大带宽，防止高优先级流量挤占其他业务。LLQ 是当前企业网络中语音、视频等实时业务最常用的调度方案。

二、配置对比与关键命令

在 Cisco IOS 中，CBWFQ 和 LLQ 的配置结构最为典型。以下示例假设出接口为 GigabitEthernet0/1，总带宽 100 Mbps，语音类保证 30 Mbps 并启用优先队列，视频类保证 25 Mbps，其余数据类保证 40 Mbps。

! 定义类映射
class-map match-any VOICE
 match ip dscp ef
class-map match-any VIDEO
 match ip dscp af41
class-map match-any DATA
 match ip dscp af21

! 定义策略映射
policy-map WAN-QOS
 class VOICE
  priority 30000          ! LLQ优先队列，单位kbps
  police 30000 conform-action transmit exceed-action drop
 class VIDEO
  bandwidth 25000         ! CBWFQ保证带宽
 class DATA
  bandwidth 40000
 class class-default
  fair-queue              ! 默认类使用WFQ

! 应用到接口
interface GigabitEthernet0/1
 service-policy output WAN-QOS

关键点：priority 命令创建 LLQ 优先队列，其带宽通常需要配合 police 限制，防止语音流量在拥塞时无限占用带宽；bandwidth 命令为 CBWFQ 类提供保证带宽，但该类在拥塞时仍可能被优先队列抢占调度机会。若将 priority 改为 bandwidth，则退化为纯 CBWFQ，语音时延将明显上升。

三、选择依据与典型误区

选择调度机制时，先问三个问题：业务是否需要严格低时延？是否需要按类别保证带宽？是否允许某类业务被饿死？语音和视频会议需要 LLQ；普通数据业务按部门或应用分配带宽用 CBWFQ；小型网络无明确分类需求可用 WFQ；仅需简单比例分配可用 CQ；无 QoS 需求则 FIFO 即可。

常见误区：把 priority 当成“高带宽保证”使用。LLQ 的优先队列在拥塞时优先调度，若不配合监管，语音突发可能挤占其他所有队列，导致数据业务严重丢包。正确做法是：priority 带宽按语音编码实际需求计算（如 G.711 每路约 80 kbps，含 IP 头开销），并配置 police 限制超额流量。

验证方法：配置完成后，用 show policy-map interface GigabitEthernet0/1 查看各类别的匹配报文数、丢弃数、当前队列深度和带宽使用率。若 VOICE 类 exceed-action 丢弃计数持续增长，说明监管阈值偏低或语音流量超出预期；若 DATA 类队列深度长期接近上限，说明保证带宽不足或存在拥塞。

六种机制并非互相替代，而是按需组合。实际工程中，LLQ 通常作为核心调度策略，配合 CBWFQ 为其他类别提供带宽保证，class-default 使用 WFQ 兜底，形成“优先队列 + 保证带宽 + 公平调度”的三层结构。理解每种机制的调度顺序、带宽语义和时延特性，才能在设计 QoS 策略时做出正确取舍。