📚 课程目录第2章 QoS基础模型与工具

2. QoS基础模型与工具

QoS不是单一技术，而是一组“对流量分类、标记、排队、调度、限速、整形”的能力集合。要理解这些能力如何落地，先要弄清三种基础服务模型：Best Effort（尽力而为）、IntServ（集成服务）和DiffServ（区分服务）。它们回答的是同一个问题——网络设备在拥塞时，凭什么决定哪个包先走、哪个包被丢、哪个包被限速。

三种服务模型的核心差异

Best Effort是最简单的模型：所有报文同等对待，先到先服务，拥塞时随机丢弃。它没有分类、没有标记、没有预留，因此无法对语音、视频、ERP等关键业务提供任何保障。企业网络如果只跑Best Effort，一旦出口带宽被P2P或大文件传输占满，视频会议就会卡顿、丢包，而网络设备本身并没有“做错什么”——它只是没有被告知谁更重要。

IntServ的思路是“按流预留”。在发送数据之前，主机或边缘设备通过RSVP（资源预留协议）向沿途每一台路由器申请资源，沿途设备为这条流维护状态并预留带宽、缓冲区。它的优点是保障精确、端到端可承诺；缺点是状态数量随流数量线性增长，核心路由器要维护海量微流状态，扩展性差。因此IntServ更适合小规模、流数量可控的场景，例如某些专网或实验环境，而不是大型企业园区网。

DiffServ的思路是“按类聚合”。它不在核心为每条流维护状态，而是在网络边缘对报文进行分类和标记，把流量归入少量行为聚合（BA），核心设备只根据DSCP（差分服务代码点）字段执行逐跳行为（PHB）。这样核心设备无需感知具体流，扩展性大幅提升。企业网络中最常用的PHB包括：EF（加速转发，用于语音）、AF（确保转发，分四个等级、每个等级三个丢弃优先级）、BE（默认尽力而为）。DiffServ因此成为当前企业QoS部署的事实标准。

DSCP与PHB：DiffServ的落地抓手

DiffServ的标记字段是IPv4头部的ToS字节（现称DS字段），其中高6位为DSCP，取值范围0～63。企业部署中常见的取值约定如下：EF对应DSCP 46（二进制101110），用于语音承载；AF41对应DSCP 34，用于视频会议；AF31对应DSCP 26，用于关键业务数据；AF21对应DSCP 18，用于普通办公；BE对应DSCP 0，用于默认流量。这些取值不是协议强制，而是工程约定，但一旦确定就应在全网保持一致，否则核心设备无法正确识别。

PHB是“逐跳行为”，描述设备对某一DSCP类流量的外部可见转发行为。EF要求低延迟、低抖动、低丢包，通常配合严格优先级队列；AF要求保证带宽并允许在拥塞时按丢弃优先级丢弃；BE则不做任何保证。理解DSCP与PHB的对应关系，是读懂设备QoS配置的前提。

CLI工具：从分类到验证的完整链路

以华为VRP和Cisco IOS为例，QoS配置通常遵循“分类—标记—队列—调度—验证”的链路。下面给出一段华为设备上的示例配置，用于在接入交换机上标记语音流量并为其提供优先队列。以下参数为教学示例，实际部署需根据现网地址、接口和业务规划调整。

# 1. 定义流分类，匹配语音VLAN与RTP端口
acl number 3001
 rule 5 permit udp destination-port range 16384 32767

traffic classifier VOICE operator and
 if-match acl 3001

# 2. 定义流行为：标记DSCP EF，并设置优先队列
traffic behavior VOICE
 remark dscp ef
 queue af1

# 3. 定义流策略并应用到接口
traffic policy QOS_POLICY
 classifier VOICE behavior VOICE

interface GigabitEthernet0/0/1
 traffic-policy QOS_POLICY inbound

# 4. 验证：查看分类统计与队列计数
display traffic policy statistics interface GigabitEthernet0/0/1 inbound
display qos queue statistics interface GigabitEthernet0/0/1

配置完成后，不能只看“命令是否敲上”，而要看三个层面的结果：第一，分类是否命中——通过display traffic policy statistics查看匹配报文数是否增长；第二，标记是否正确——在核心设备上抓包或查看DSCP值，确认EF报文未被重标记；第三，队列是否生效——通过display qos queue statistics观察EF队列的丢弃计数是否远低于BE队列。如果EF队列仍有大量丢弃，说明带宽预留不足或上游存在拥塞点，需要回到流量模型重新核算。

网管工具：从单点配置到全局视图

CLI适合精确配置和排障，但企业网络往往有数百台设备，逐台登录不现实。网管工具的价值在于批量下发、集中监控和趋势分析。常见做法包括：通过SNMP采集接口队列丢弃计数、通过NetFlow/sFlow采集流级统计、通过Syslog接收QoS策略变更日志、通过图形化网管平台（如eSight、Cisco DNA Center等）下发QoS模板。实际运维中，建议把“关键接口的EF/AF队列丢弃率”和“DSCP标记一致性”作为两个核心监控指标，设置阈值告警。例如，EF队列丢弃率持续大于0.1%即触发告警，提示语音质量可能劣化。

选择模型时，可遵循一个简单判断：如果网络规模大、流数量多、希望核心设备轻量，选DiffServ；如果流数量少且需要精确的端到端资源承诺，才考虑IntServ；如果业务无差异化要求，Best Effort即可，但关键业务一旦上线，就应尽快引入DiffServ。

小结与检查要点

Best Effort、IntServ、DiffServ的区别，本质是“状态放在哪里、粒度有多细、扩展性如何”。企业网络应以DiffServ为主线，在边缘完成分类与DSCP标记，在核心按PHB调度。CLI负责精确落地，网管工具负责规模化和持续验证。判断QoS是否真正生效，不能只看配置，而要看分类命中、标记一致、队列丢弃三个层面的实际数据。