1. 项目概述：为什么今天还在认真搞QoS？不是早该被SD-WAN和云网络淘汰了吗？
“QoS流量监管和流量整形配置实例”——看到这个标题，不少刚接触网络运维的朋友第一反应可能是：这玩意儿是不是老古董了？现在都上云了，带宽随便买，链路还搞什么限速、整形？我当年在某高校实验室第一次实操这个功能时，也抱着同样的疑问。直到某次线上会议系统突然卡顿，后台监控显示核心出口链路瞬时利用率冲到98%，而语音流的延迟抖动直接飙到200ms以上，用户投诉电话打爆运维台。排查一圈才发现，是某台备份服务器在凌晨三点偷偷发起全量数据同步，把本该留给VoIP的保障带宽全部吃干抹净。那一刻我才真正明白：QoS不是过时的技术，而是网络资源有限性在数字世界里的物理法则具象化表达。它解决的从来不是“有没有带宽”的问题，而是“关键业务能不能抢到带宽”的生存问题。
这个配置实例，核心关键词就是流量监管（Policing）和流量整形（Shaping）。它们看起来像一对双胞胎，都管“流速”，但底层逻辑截然不同：监管是“硬闸门”，超速就直接丢包，像高速路口的ETC拒入；整形是“软缓冲池”，超速先排队，等有空闲再发，像地铁站的蛇形通道。实际部署中，监管多用在入口（如接入交换机端口），快速过滤恶意突发；整形则常用在出口（如路由器WAN口），平滑输出避免下游设备拥塞。本文不讲抽象定义，只聚焦一个真实可复现的场景：如何在一台主流企业级路由器上，为视频会议流（DSCP EF）、办公OA系统（DSCP AF31）和普通上网（DSCP BE）三类业务，分别配置独立的带宽保障与突发控制策略，并通过实测验证效果。适合刚考完HCIA/CCNA想动手验证理论的新人，也适合已在一线扛着割接压力的老手查漏补缺——毕竟，配置命令敲错一个参数，可能就是整栋楼视频会议集体掉线。
2. 核心原理拆解：监管与整形的本质差异，远不止“丢包”和“缓存”两个词
2.1 流量监管（Policing）：为什么它必须是“无状态”的暴力裁决者？
很多人误以为监管就是“限速”，其实它的设计哲学更接近“交通警察现场执法”。关键在于它必须无状态、低延迟、零缓冲。我们来拆解一个典型单速率双桶（Single Rate Two Color）监管器的工作流程：
- 第一个桶（C桶）：容量为CIR × Tc，其中CIR是承诺信息速率（比如10Mbps），Tc是时间常数（通常由设备自动计算）。这个桶里装的是“合规信用”，每秒按CIR速率匀速注入令牌。
- 第二个桶（E桶）：容量为（CIR + PIR）× Te，PIR是峰值信息速率（比如15Mbps），Te是另一个时间常数。它装的是“额外容忍额度”，注入速率也是PIR。
- 决策逻辑：当一个数据包到达时，先尝试从C桶扣减其字节数对应的令牌。如果C桶够用，标记为绿色（Green），正常转发；如果C桶不够但E桶够，标记为黄色（Yellow），可选择降DSCP或丢弃；如果两个桶都不够，标记为红色（Red），直接丢弃。
提示：这里的关键陷阱是“时间常数Tc/Te的物理意义”。很多新手以为Tc=1秒，其实Tc = C桶容量 ÷ CIR。例如CIR=10Mbps，C桶容量设为125000字节（即1Mbit），那么Tc=0.1秒。这意味着监管器每0.1秒才重置一次令牌，而不是每秒。这直接影响突发流量的容忍度——Tc越小，对短时突发越敏感。
为什么监管必须无缓冲？因为一旦引入队列，就违背了“实时判决”原则。想象一下，如果监管器给每个包排队等待令牌，那它自己就成了新的拥塞点，延迟不可控，完全失去保障实时业务的意义。所以所有主流厂商的监管实现，底层都是纯硬件查表+令牌桶状态寄存器，毫秒级响应。
2.2 流量整形（Shaping）：缓冲区不是万能的，它是一把双刃剑
整形的核心是“有状态、可预测、带缓冲”，但它绝不是简单加个队列就完事。以最常见的基于类的整形（CB-Shaping）为例，其背后是三层精密协作：
第一层：分类与标记（Classification & Marking）
这是整形的前提。必须先用ACL或DSCP值精准识别出视频会议流（如源端口5060/UDP，DSCP=EF），否则整形策略就像给空气上锁。某次我在某金融公司做割接，发现整形策略始终不生效，最后排查发现是上游防火墙把所有VoIP流量的DSCP都重写了，导致路由器根本匹配不到规则。第二层：整形队列管理（Shaping Queue）
这里藏着最易被忽视的细节：整形队列深度（Queue Depth）。默认值往往只有几十个包，对于千兆链路下的大文件传输，几毫秒就填满。一旦队列满，后续包只能被丢弃（Tail Drop），这反而制造了新的拥塞点。实测建议：队列深度 = （整形速率 × RTT）÷ MTU。例如整形到50Mbps，RTT=20ms，MTU=1500字节，则理想队列深度 ≈ (50×10⁶ × 0.02) ÷ 1500 ≈ 667个包。不调这个参数，整形效果大打折扣。第三层：调度算法（Scheduling Algorithm）
常见的WFQ（加权公平队列）或LLQ（低延迟队列）在这里起决定性作用。LLQ会为EF类流量预留绝对优先级，确保其队列中的包永远最先被发送，哪怕其他队列已积压百个包。但注意：LLQ的预留带宽不能超过整形总速率的1/3，否则会饿死其他业务。这是某次客户投诉“OA系统变慢”的根源——他们把LLQ带宽设到了整形速率的70%。
2.3 监管 vs 整形：一张表看懂何时该用谁
| 对比维度 | 流量监管（Policing） | 流量整形（Shaping） |
|---|---|---|
| 部署位置 | 通常在入口方向（Ingress），如接入层端口 | 通常在出口方向（Egress），如核心路由器WAN口 |
| 核心动作 | 超速即丢弃（Red）或标记降级（Yellow） | 超速即缓存排队，择机发送 |
| 延迟影响 | 零新增延迟（判决瞬间完成） | 引入确定性延迟（排队等待时间 = 队列长度 ÷ 发送速率） |
| 适用场景 | 防御DDoS攻击、限制用户最大带宽、防止恶意扫描 | 平滑WAN链路输出、保障VoIP/视频会议、配合下游设备QoS策略 |
| 资源消耗 | 极低（仅需令牌桶状态寄存器） | 较高（需分配内存作为队列缓冲区） |
| 配置复杂度 | 低（通常只需CIR/PIR两个参数） | 高（需协调分类、队列深度、调度算法、整形速率四要素） |
注意：监管和整形可以串联使用。例如在接入交换机上先用监管限制单用户最大带宽（防内网滥用），再在核心路由器出口用整形平滑整体流量（保WAN稳定）。但绝不能反向串联——在出口先整形再监管，等于让缓冲区白忙活。
3. 实操配置全流程：从拓扑设计到效果验证，一步不跳过
3.1 环境准备与拓扑设计：为什么必须用真实设备而非模拟器？
本次实操基于一台华为AR3260路由器（VRPv8系统）和一台思科ISR4331（IOS-XE 17.6），两端通过千兆光纤直连，中间无其他设备。之所以坚持用真机，是因为模拟器（如eNSP、GNS3）在QoS行为上存在三个致命偏差：
- 令牌桶精度失真：模拟器的时间片调度无法精确到微秒级，导致突发流量测试结果虚高；
- 队列深度模拟失效：eNSP的整形队列实际是软件队列，内存分配机制与真实ASIC芯片完全不同；
- 丢包模式错误：模拟器丢包往往是随机的，而真实设备在Tail Drop时有明确的序列号规律。
拓扑极其简洁：PC1（192.168.10.10）→ AR3260（G0/0/0:192.168.10.1）→ 光纤 → ISR4331（G0/0/0:192.168.20.1）→ PC2（192.168.20.20）。所有QoS策略均配置在AR3260的G0/0/0接口出方向（outbound），因为我们要整形的是流向WAN的流量。
3.2 分类与标记：用ACL还是DSCP？这次选后者
虽然ACL能基于五元组精准识别，但本例中我们选择基于DSCP值分类，原因有三：
- 视频会议终端（如某品牌会议系统）出厂即设置DSCP=EF，无需额外配置；
- 办公OA系统由某云服务商提供，其API网关支持DSCP透传，我们只需在客户端浏览器插件中启用；
- 普通上网流量默认DSCP=BE（0），天然可区分。
配置命令（华为AR3260）：
# 创建流分类：识别三类业务 traffic classifier video operator and if-match dscp ef traffic classifier oa operator and if-match dscp af31 traffic classifier internet operator and if-match dscp be # 创建流行为：为video类配置LLQ，oa类配置WFQ，internet类配置默认BE traffic behavior video queue llq bandwidth 3000 # 预留3Mbps给EF流，注意单位是kbps traffic behavior oa queue wfq bandwidth 4000 # 分配4Mbps给AF31流 traffic behavior internet queue wfq bandwidth 3000 # 分配3Mbps给BE流实操心得：
queue llq bandwidth的数值不是“保证带宽”，而是LLQ队列的绝对发送上限。如果设得过大（如5000），当EF流突发时会持续占用链路，导致oa和internet流长期得不到服务。我们实测3000kbps（约3.75MB/s）刚好满足4K视频会议的峰值码率，且留有余量。
3.3 流量整形配置：关键参数的计算与取舍
在AR3260上，整形必须绑定到接口的QoS策略中。完整配置如下：
# 创建QoS策略，关联分类与行为 qos policy video-policy classifier video behavior video classifier oa behavior oa classifier internet behavior internet # 在接口G0/0/0出方向应用策略，并启用整形 interface GigabitEthernet0/0/0 qos policy video-policy outbound qos lr cir 10000 # 总整形速率10Mbps，注意单位是kbps！这里qos lr cir 10000是关键。lr是Link Rate（链路速率）的缩写，华为用它实现整形。但注意：这个10000kbps不是“总带宽”，而是整形后的输出速率上限。所有分类的带宽之和（3000+4000+3000=10000）必须严格等于此值，否则策略无法提交。这是华为设备的硬约束，不同于思科的shape average可超限。
提示：为什么不用
qos car（Committed Access Rate）？因为CAR是监管命令，用在inbound方向。在outbound用CAR会导致策略被拒绝——华为明确禁止在出方向配置监管。
3.4 流量监管配置：放在哪里才能发挥最大效力？
监管我们放在上游接入交换机（假设为S5735）的端口上，用于限制单PC最大带宽，防止内网滥用。配置如下：
# 在接入交换机S5735的G1/0/1端口（连接PC1）配置监管 interface GigabitEthernet1/0/1 qos car inbound cir 5000 cbs 625000 pbs 937500 # CIR=5Mbps, CBS=625KB, PBS=937.5KB参数详解：
cir 5000：承诺速率5Mbps；cbs 625000：C桶容量 = 5Mbps × 0.1s = 625000字节（因Tc=0.1s）；pbs 937500：P桶容量 = （5+2.5）Mbps × 0.1s = 937500字节（PIR=7.5Mbps，允许2.5Mbps突发）。
实操心得：CBS和PBS的计算必须手动完成。设备不会帮你算，输错一个零，突发容忍度就差10倍。我们曾因PBS少输一个零，导致视频会议开局时连续3秒卡顿——因为首帧I帧太大，直接被标红丢弃。
3.5 效果验证：用iPerf3和Wireshark做交叉验证
验证不能只看设备show命令，必须用第三方工具实测。我们分三步走：
第一步：基线测试（关闭QoS）
在PC1上运行：iperf3 -c 192.168.20.20 -t 60 -i 1
结果：平均吞吐945Mbps，抖动<0.2ms，无丢包。
第二步：开启整形后测试
在PC1上同时启动三个iperf3任务：
- 视频流：
iperf3 -c 192.168.20.20 -u -b 3M -t 60（UDP，3Mbps） - OA流：
iperf3 -c 192.168.20.20 -b 4M -t 60（TCP，4Mbps） - 上网流：
iperf3 -c 192.168.20.20 -b 3M -t 60（TCP，3Mbps）
在AR3260上执行：display qos policy interface GigabitEthernet0/0/0 outbound
关键字段：
Classifier: video Behavior: video Queue: LLQ, Bandwidth: 3000 kbps, Queue Length: 64 packets Packets matched: 284512, Packets dropped: 0 Classifier: oa Behavior: oa Queue: WFQ, Bandwidth: 4000 kbps, Queue Length: 128 packets Packets matched: 379205, Packets dropped: 0 Classifier: internet Behavior: internet Queue: WFQ, Bandwidth: 3000 kbps, Queue Length: 96 packets Packets matched: 284398, Packets dropped: 0第三步：Wireshark抓包分析
在PC2上抓包，过滤ip.dsfield.dscp == 46（EF），观察时间间隔。理想情况下，EF包应以恒定间隔到达（如每333μs一个1500字节包）。实测结果：平均间隔335μs，标准差仅12μs，证明LLQ整形效果极佳。
常见误区：很多人用
ping测延迟来验证QoS，这是无效的。Ping用的是ICMP，DSCP值通常被中间设备重置为0，完全不走你的QoS策略。必须用真实业务流（如iperf3的UDP流）或业务终端本身。
4. 常见问题与排错实战：那些文档里绝不会写的坑
4.1 问题现象：策略应用后，所有流量都被限速到10Mbps，但三类业务间无差别
排查思路：
首先确认分类是否生效。在AR3260上执行：display traffic classifier verbose，检查if-match条件是否匹配成功。我们曾遇到一次，发现if-match dscp ef始终显示0匹配，原因是PC1发出的包DSCP值被Windows网卡驱动重置了。解决方案：在PC1上执行netsh int ipv4 set subinterface "以太网" mtu=1500 store=persistent并重启网卡，强制禁用DSCP覆盖。
根本原因：
Windows默认启用“QoS数据包计划程序”，会将所有非特权进程的DSCP清零。这不是设备问题，而是终端OS的“好心办坏事”。
4.2 问题现象：LLQ队列持续满载，OA和Internet流几乎收不到包
排查思路：
执行display qos queue statistics interface GigabitEthernet0/0/0，重点看LLQ Queue Length和WFQ Queue Length。若LLQ队列长度长期>90%而WFQ<10%，说明EF流占满带宽。此时需检查：
- 视频会议终端是否异常发送超码率流（如4K会议误设为8K）；
- 是否有其他设备也标记为EF（如某监控摄像头NVR）；
独家技巧：
在AR3260上启用qos pre-classify（预分类），让设备在IP层就完成DSCP匹配，避免因NAT或隧道封装导致DSCP丢失。命令：qos pre-classify在接口视图下执行。
4.3 问题现象：整形后延迟大幅增加，视频会议出现明显卡顿
排查思路：
这是整形队列深度设置不当的典型症状。执行display qos queue depth interface GigabitEthernet0/0/0，查看当前队列深度。若显示Current Queue Depth: 256 packets，而理论值应为667，则立即扩容：
# 进入系统视图 qos queue-length 667 # 华为设备全局队列深度设置为什么必须全局设置？
因为华为的整形队列深度是设备级参数，不是接口级。不改这个，单改接口策略无效。
4.4 问题现象：监管策略在inbound方向生效，但outbound方向同样限速
根本原因：
这是初学者最易踩的坑——混淆了方向概念。inbound指“进入该接口的数据流”，即从PC1流向AR3260的数据；outbound指“从该接口发出的数据流”，即从AR3260流向ISR4331的数据。如果你在AR3260的G0/0/0口配qos car inbound，那监管的是PC1发来的包；但如果你本意是限制AR3260发给ISR4331的包，就必须用qos lr（整形）或换到ISR4331的G0/0/0口配inbound监管。
速查表：QoS方向决策指南
| 你想控制的流量方向 | 应配置的方向 | 推荐技术 | 典型命令（华为） |
|---|---|---|---|
| PC1 → AR3260（防PC1滥用） | inbound | 监管 | qos car inbound cir 5000 |
| AR3260 → ISR4331（保WAN稳定） | outbound | 整形 | qos lr cir 10000 |
| ISR4331 → PC2（防下游拥塞） | inbound | 监管 | qos car inbound cir 10000 |
4.5 问题现象：DSCP值在跨厂商设备时丢失
终极解决方案：
在AR3260和ISR4331之间启用DSCP透明传输。华为侧：
# 在AR3260的G0/0/0口下 qos trust dscp # 告诉设备信任入向DSCP值，不重写思科侧（ISR4331）：
interface GigabitEthernet0/0/0 service-policy input POLICY-IN ! policy-map POLICY-IN class class-default set dscp-transmit ef # 强制透传，不修改注意：
qos trust dscp必须在应用QoS策略前配置，否则策略会覆盖DSCP值。这是华为文档里一笔带过的细节，但实际中90%的跨厂商DSCP失效都源于此。
5. 进阶思考：当QoS遇上SD-WAN和云原生，它真的过时了吗？
写到这里，可能有人会问：现在都用SD-WAN了，底层链路自动选路、应用识别内置、带宽按需弹性，还要手敲QoS命令吗？我的答案是：QoS没有消失，只是下沉为SD-WAN控制器的隐式能力。某次参与某跨国企业的SD-WAN部署，我们发现其控制器后台的“应用策略”页面，所有带宽保障、优先级设置的底层，依然是生成了一套等效的QoS配置下发到边缘设备。区别只在于，你不再面对命令行，而是面对一个图形界面——但背后的令牌桶、LLQ队列、WFQ权重，一个都没少。
更值得警惕的是云原生场景。当业务容器化部署在Kubernetes集群中，网络策略（NetworkPolicy）只能控制“通/不通”，而真正的带宽保障、延迟控制，依然要靠节点上的CNI插件（如Calico）调用Linux TC（Traffic Control）子系统实现。而TC的htb（Hierarchical Token Bucket）和tbf（Token Bucket Filter）模块，本质上就是QoS监管与整形的开源实现。我们曾为某电商大促系统优化，在K8s节点上部署TC脚本，将支付服务Pod的出向流量整形到200Mbps，效果立竿见影——大促期间支付成功率提升12%，因为支付请求不再被日志采集流量挤占带宽。
所以，与其说QoS过时了，不如说它正以更隐蔽、更自动化的方式，成为数字基础设施的“呼吸系统”。你可能不再天天敲qos lr，但当你在云控制台拖拽一个“视频会议保障策略”时，那个正在后台默默运转的令牌桶，依然是二十年前RFC 2697定义的模样。理解它，不是为了怀旧，而是为了在任何一个需要“掌控流量脉搏”的时刻，都能精准地按下那个正确的开关。
