本文基于真实项目场景，对 HQoS（分层服务质量）在满载条件下的带宽保障能力进行了实测验证。通过模拟 100M…
一、为什么要写这次测试？
因为我最近被某厂商的400售后给整不会了。
最近在企业网干活时遇到一个带宽跑满情况，配置完成QOS之后不生效，客户认为我是个水货，质疑我是个渣渣网工。
企业设备采购的时候写得好好的：“支持 QOS、支持带宽保证”，客户相信设备描述这无可厚非。
遇到问题之后联系技术支持，400 售后给的解释是这样：
“我们设备可以保证带宽……
只要你的总带宽没跑满。”
“如果跑满了，那我们也没办法保证。”
？？？
我当场(⊙﹏⊙)了。
出口都没跑满你保证什么？？？
我不担心业务空闲时抢不到带宽，
我担心的是——满载时哪些业务能活下去,不受影响。
这就好像：
- 不下雨的时候说“我这伞特别好用
- 下雨的时候说我这伞也挡不住
那要你伞干嘛？
这不是“保证带宽”，
这是“带宽富余的时候象征性照顾一下”。
企业根本不需要这种“摆设型 营销型 QOS”。
企业真正需要的带宽保障是什么？：
- 关键 IP 无论什么时候都能享有充足带宽。
- 出口爆满也要给保证的这些关键业务，不抖、不掉、不丢包。
- 关键业务不用的时候，其他IP才能占用这些带宽。
- 只要关键业务需要用带宽，其他的业务必须让出带宽。
这才是QOS该有的样子。
HQOS模拟企业测试环境：
企业内网有两个业务：
- 生产业务 （10.0.35.98）
- 办公用户（10.0.35.0/24）
公司有一条 100Mbps 的互联网出口。
需求非常明确：
生产业务必须在任何时刻都能稳稳获得 50Mbps，不能被挤、不能掉、不能抖。
当生产业务不占带宽时，办公用户可以自由使用整个 100Mbps，不浪费带宽。
一旦出口跑满，办公用户必须让出 50Mbps，把带宽优先给生产业务。
整个配置基于 HQOS，实现真正的“关键业务优先、带宽可借可还、不浪费、不中断”。
二、HQOS 基础配置
电信入接口进行分类
acl number 3333
rule 5 permit ip destination 10.0.35.98 0
traffic classifier qos-out operator or
if-match acl 3333
traffic behavior qos-out
car cir 50000 pir 100000 cbs 9350000 pbs 18700000 green pass service-class af1 color green yellow pass service-class be color green red pass service-class be color green
traffic policy qos-out
undo share-mode
statistics enable
classifier qos-out behavior qos-out precedence 5内网出接口进行整形
flow-queue qos-out
queue be lpq
queue af1 wfq weight 50
qos-profile qos-out
user-queue cir 100000 pir 100000 flow-queue qos-out三、效果测试
为了让结果足够“有感知”，我做了两组最能体现 QOS 价值的测试：
1、先把100Mbps带宽打满：
我们用环境把出口打满至 100Mbps，模拟企业最激烈的带宽竞争场景—整个出口几乎被挤爆。
这时就能看到 QOS 是否真的有效，而不是空闲时“看起来有效”。
2、对比办公网络和生产业务的体验差异：
在带宽被完全占满的情况下，结果非常明显：
生产业务 A：
- 访问 8.8.8.8 延时稳定在 1～2ms
- 无丢包、无抖动、无卡顿
- 仿佛出口完全没有拥塞
- 这证明关键业务拿到它专属的 50Mbps，谁也抢不走
办公用户：
- 延时升到 100～300ms
- 出现明显丢包
- 体验下降
- 因为办公流量必须让出带宽给关键业务，这是预期内的
四、总结
真正的企业级 QOS，必须能在“出口跑满时”依然稳得住。
企业需要的从来不是“空闲时的带宽保证”，而是在带宽被挤满时，关键业务仍然稳如磐石。
测试结果非常直观：
- 关键业务（生产业务 A）不管出口多拥堵，都能稳稳拿到 50Mbps，无丢包。
- 非关键流量（办公用户）在拥塞时主动让路，延时上升、有丢包，但不影响关键业务。
基于真实环境整理，如需进一步沟通相关需求，可通过页面右侧方式与我联系。