简介《QoS网络技术白皮书.docx》是一份面向网络运营商、行业用户及网络工程师的技术参考资料聚焦传统IP网络在VoIP、视频会议等实时业务中的不足系统阐述如何通过区分服务实现网络资源优化分配与关键业务保障。整份资源仅包含1个docx格式文档压缩包大小2.53MB内容组织完整适合作为QoS原理学习与H3C设备部署方案的随身手册。已有110人学习下载。文档从Best-Effort、IntServ与DiffServ三种服务模型讲起详细展开流量分类与标记、拥塞管理CQ、PQ、CBWFQ、拥塞避免RED/WRED、流量监管与整形、链路效率机制及MPLS QoS等关键技术并配有缩略语对照与目录式结构便于快速定位知识点。读者可借此系统建立QoS技术框架掌握从流量识别到队列调度、从拥塞控制到SLA保障的完整实施路径为网络规划与故障排查提供直接参考。1. 从 Best-Effort 到 DiffServ这份 QoS 白皮书解决什么问题前阵子替客户排查一个视频会议卡顿的问题出口带宽明明还有余量可会开到一半画面还是糊成一团。抓包一看语音流和数据流全挤在同一个 FIFO 队列里。这就是传统 IP 网络最典型的毛病——所有报文无差别对待转发设备只负责尽力而为对时延、抖动、丢包率一概不承诺。后来照着这份《QoS 网络技术白皮书》的思路把流量分类、队列调度、拥塞避免逐项配下去问题才算真正解决。这份资源覆盖了 Best-Effort、IntServ、DiffServ 三种服务模型把流量分类标记、拥塞管理、拥塞避免、流量监管与整形、链路效率机制以及 MPLS QoS 全部串成一条可落地的解决方案链。适合做企业网、运营商承载网、VoIP 和视频会议保障的网络工程师也适合刚接触 QoS 想系统梳理知识体系的从业者。2. 流量分类和标记DSCP、IP Precedence、CoS 映射与处理顺序2.1 各 QoS 技术在同一设备上的处理顺序白皮书里有一句话特别关键流量分类和标记是基础是有区别地实施服务的前提。很多人在设备上配置了一堆队列策略却发现不生效回头一查往往是入方向的分类规则就没写对。QoS 各技术在同一条转发路径上的处理顺序是这样的报文从接口进来先做流量分类和标记紧接着是 CAR 流量监管决定是否限制或惩罚超规格流量报文往接口外出时再进入拥塞管理和拥塞避免环节由队列调度决定发送次序由 WRED 决定是否主动丢弃最后如果配置了 GTS 或 LR再在出方向做速率整形和总速率限制。这个顺序直接决定了配置的位置分类和监管作用在接口入方向队列和整形作用在接口出方向。有些工程师习惯把所有 QoS 动作都堆在入方向结果下游设备看到的 DSCP 值是对的但本设备根本没参与队列调度等于忙活半天只帮别人做了标记。白皮书的图把这条链路画得很清楚先分类后监管再排队最后整形每一步的职责边界是分开的。2.2 IPv4、IPv6、以太网三类业务分类位IPv4 报文在 ToS 域里定义了 8 种 IP 优先级从 Routine 到 Network Control数值越大优先级越高。DiffServ 模型则把 ToS 域重新定义成 DSCP 字段一共 64 种取值白皮书列出了典型 PHB 的推荐值EF 是 46对应交互式语音AF41 是 34对应交互式视频AF31 是 26对应视频控制AF2x 是 18、20、22对应事务型交互业务AF1x 是 10、12、14对应批量数据。几个关键映射我整理成了表平时做方案直接照这个表对。表 2-1 典型 DSCP PHB 定义业务类型DSCP PHBDSCP 值十进制网络控制CS756IP 路由CS648交互式语音EF46交互式视频AF4134视频控制AF3126事务型交互AF2x18、20、22批量数据AF1x10、12、14流媒体视频CS44电话信令CS33网络管理CS22尽力转发BE0IPv6 在报头里保留了类似 IPv4 的 ToS 域称为传输级别域 TC同时新增了 20 比特的流标签。白皮书指出IPv6 QoS 可以基于 TC 域做分类和标记流标签则留给后续扩展。以太网这边802.1Q 的 VLAN TAG 里用 3 比特定义 CoS 值一共 8 种业务优先级。同一份白皮书给出的建议是语音业务时延一般要求小于 10 毫秒视频业务小于 100 毫秒网络控制报文要保证低丢包率。这些数字直接决定你后面把不同业务扔进哪个队列。2.3 分类标记配置ACL 匹配与 DSCP 重标记配置流量分类和标记时常见做法是先用 ACL 匹配五元组或网段再定义类和行为最后在接口入方向应用。以 H3C Comware V7 的写法为例system-view # 定义 ACL 3001匹配视频会议终端所在网段发往对端的 UDP 流 acl advanced 3001 rule 0 permit udp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 # 定义流量分类 video关联 ACL 3001 traffic classifier video if-match acl 3001 # 定义流量行为 mark-ef把命中报文的 DSCP 重标记为 EF traffic behavior mark-ef remark dscp ef # 定义策略 video_inbound将分类与行为绑定 qos policy video_inbound classifier video behavior mark-ef # 在入接口应用该策略 interface GigabitEthernet1/0/1 traffic-policy video_inbound inbound这段配置的逻辑是先通过 ACL 圈定目标流量再用 traffic classifier 把它归为一类然后由 traffic behavior 执行动作。remark dscp ef的意思是重标记 DSCP 值为 46也就是 EF 加速转发。注意动作里没有涉及任何队列调度因为分类标记只是给报文打标签真正的优先发送要靠后续的出方向队列来兑现。参数上有两个容易被忽略的地方。一是 ACL 的匹配条件越精确分类覆盖范围越可控但规则数也会膨胀建议按业务网段聚合而不是精确到单个 IP。二是策略应用方向入方向做标记可以确保本设备以及下游设备都能看到统一的 DSCP 值但如果你希望本设备自己也参与队列调度那么出方向也要留意是否缺策略。标记是给下游看的队列才是给自己用的两者不冲突但很多人只做了前者。2.4 IEEE 802.1Q 推荐的 CoS 到队列映射二层交换场景里802.1P 的 CoS 值最终要映射到出端口的不同队列。白皮书给出了 IEEE 802.1Q 推荐的映射关系以常用的 4 队列为例表 2-2 IEEE 802.1Q 推荐的 CoS 与 4 队列映射队列 ID业务类型1Best Effort、Background2Critical Applications、Excellent Effort3Voice、Video4Network Control、Internetwork Control这个映射表直接回答了“标记完了往哪个队列放”的问题。如果你的交换机只有 4 个队列语音视频放队列 3网络控制放队列 4普通上网业务放队列 1数据库这类关键应用放队列 2。实际配置里有些设备支持自定义映射表我一般会基于这个推荐表微调把视频会议这类对时延敏感的业务和普通 VoD 流媒体拆开避免它们互相挤占带宽。3. 拥塞管理队列实战FIFO、PQ、CQ、WFQ、CBWFQ 怎么选怎么配3.1 拥塞是怎么发生的队列又是怎么解决的拥塞的本质是报文到达速度超过接口发送速度。比如局域网是 10M 接入出口串口只有 2M那么路由器串口必然成为瓶颈。此时报文如果直接丢弃应用层会重传进一步加剧拥塞如果全部缓存时延又无法控制。队列技术就是在接口出方向建立缓冲区把报文按类别送入不同队列再通过调度算法决定谁先出队。白皮书对 FIFO 的定义最简单不对报文分类先进先出。它的优点是实现成本低缺点是关键的语音流可能被批量下载的数据堵在后面。FIFO 只适合没有拥塞风险的链路或者作为其他队列机制的兜底。3.2 PQ 和 CQ绝对优先与带宽比例PQ 把所有报文分成最多 4 类分别进入高、中、正常、低四个队列。调度时先发高优先队列发空了再发中队列以此类推。这样做的好处是 VoIP 这类高优先级业务能得到绝对的时延保障坏处是如果高优先队列持续有流量低优先队列可能被饿死。白皮书特别提到一个场景关键业务报文总是被先发送直到暂时没有关键业务的报文才发送普通业务报文。这个“绝对优先”既是优势也是风险后面避坑章节我会专门展开。CQ 的设计则不同它把报文分成最多 16 个队列每个队列按定义的比例占用接口带宽。出队时按字节数轮询比如队列 1 每次取 6000 字节、队列 2 取 2000 字节就能近似实现 60% 和 20% 的带宽分配。CQ 避免了 PQ 的低队列饿死问题但对实时业务来说轮询带来的时延抖动比 PQ 明显。所以 CQ 适合对带宽比例有要求但对时延不极敏感的业务比如给数据库访问分配保证带宽同时给 FTP 设定上限。3.3 WFQ、CBWFQ 与 RTP 优先队列WFQ 是加权公平队列它基于流的优先级和权重来分配带宽。优先级高的流获得更多调度机会同时低优先级流也不会完全得不到带宽。WFQ 的优点是配置简单不需要手工定义分类规则系统自动按会话区分流缺点是难以对特定业务做精细化保障因为它依赖报文中已有的优先级字段。CBWFQ 则在 WFQ 基础上引入了“类”的概念先按自定义规则把流量分类再为每个类单独指定带宽。白皮书的说法是“基于类的加权公平队列”它兼顾了 CQ 的带宽比例能力和 PQ 的优先调度能力。实际工程里还有一个更常用的组合叫 LLQ低时延队列。它在 CBWFQ 的基础上把语音这类对时延极敏感的业务放进一个优先队列其他类仍然按 WFQ 调度。RTP 优先队列则专门针对 RTP 报文识别语音流后直接给予优先发送。三类队列的处理差异用一张表来对比更直观表 3-1 常用队列技术对比队列类型分类能力队列数量是否可能饿死低优先级典型场景FIFO不分类1无优先级概念无拥塞链路PQ支持最多 4是VoIP 绝对优先CQ支持最多 16否按比例分配带宽WFQ自动按流动态否默认公平调度CBWFQ支持自定义视配置语音数据混合RTP 优先队列识别 RTP与队列结合否VoIP 低时延保障3.4 CBWFQ 配置示例语音带宽怎么保证以 H3C Comware V7 为例把语音流放进 LLQ 并保证带宽其他数据流按 AF 类分配带宽的常见配置如下system-view # 定义语音类匹配 DSCP EF 的流量 traffic classifier voice if-match dscp ef # 定义语音行为进入低时延队列保证 512 kbps 带宽 traffic behavior voice-llq queue llq bandwidth 512 # 定义数据类匹配 DSCP AF21 的流量 traffic classifier data if-match dscp af21 # 定义数据行为进入 AF 队列保证 2048 kbps 带宽 traffic behavior>system-view # 入方向匹配 DSCP AF11 的流量限制 CIR 为 4000 kbps acl advanced 3010 rule 0 permit ip traffic classifier af11 if-match dscp af11 traffic behavior car-af11 car cir 4000 cbs 40000 ebs 40000 red-action discard qos policy car-inbound classifier af11 behavior car-af11 interface GigabitEthernet1/0/1 traffic-policy car-inbound inbound # 出方向对接口所有流量整形到 2000 kbps interface Serial1/0 qos gts outbound cir 2000 cbs 20000CAR 参数里cir是承诺信息速率cbs是承诺突发尺寸ebs是超出突发尺寸red-action discard表示超速报文直接丢弃。这里cbs的设置尤其关键它决定你能容忍多大的瞬时突发。如果 cbs 太小即使平均速率没超突发也会被误杀。GTS 参数则简单得多它不丢包只是把超出cir的报文缓存进队列按 2 Mbps 的速率往外发。一个需要留意的副作用是如果入方向持续大于整形速率队列会越积越长时延随之增大。所以 GTS 只适合入向速率略大于出向速率的场景差距过大时要考虑同时配置 CAR 限制入向速率否则整形的缓存就成了延迟的温床。4.5 MPLS 网络里的 QoS 组合白皮书第 3 章单独讲了 MPLS QoS。MPLS DiffServ 的核心是把 DSCP 映射到 MPLS 报文的 EXP 域再由标签交换路径上的每一跳根据 EXP 值执行 PHB。这里有个容易忽略的点在倒数第二跳弹出标签后设备需要把 EXP 信息重新映射回 IP 报文的 DSCP否则 QoS 策略在最后一跳就断了。MPLS-TE 则解决的是带宽资源预留的问题。它通过 RSVP-TE 建立具备带宽约束的隧道把流量引入指定路径。白皮书提到 DS-TE 的思路就是 DiffServ 和 TE 结合将流量分为多个类每类设定独立的带宽约束。简单理解DiffServ 管优先级TE 管路径和带宽两者叠加后既能走指定路径又能保证路径上的带宽资源不被其他流量抢走。5. 常见问题与避坑QoS 配置翻车的五个典型现场5.1 现象高优先级队列抢断所有带宽SSH 都连不上一旦给 PQ 的高优先队列配置了过大的带宽且持续有语音或视频流量注入低优先级的运维流量会被完全饿死。有次配完后控制台还能操作远程 SSH 直接超时就是典型的 PQ 饥饿问题。原因是 PQ 的调度机制是严格优先的高优先队列只要非空调度器就不会轮到低优先队列。解决思路有两个一是把运维管理流量放进更高优先级的队列二是改用 LLQ 而不是 PQ。LLQ 在优先发送的同时设置了带宽上限超过上限的语音流量会被转入普通队列这样低优先级流量永远有调度机会。从那以后我只要看到 PQ 就条件反射去看高优先队列的带宽上限。5.2 现象DSCP 标记明明配了下游设备却不认账入方向做了重标记抓包也看到 DSCP 值变成了 EF但下一跳设备的队列统计毫无变化。翻配置才发现下游设备的入方向又做了一次分类匹配的是 IP Precedence 而不是 DSCP两边字段没对齐等于白标。原因是 DiffServ 域跨设备时DSCP 到 PHB 的映射关系没有约定一致。解决方法是把整条链路上所有设备的分类匹配字段统一要么全用 DSCP要么全用 IP Precedence并且在接口的信任模式上保持一致。我通常会在方案文档里画一张“DSCP 传递图”标注每个设备信任哪个字段、重标记在哪一跳发生避免各设备各玩各的。5.3 现象WRED 配置后正常业务也开始丢包某次现网配置 WRED 后业务侧反馈丢包率上升但接口并没有拥塞。查了队列深度发现平均队列长度一直在下限阈值附近波动随机丢弃已经提前开始工作了。原因是 WRED 的下限阈值设得过低低于正常突发时的队列深度。解决方法是先观察一段时间的平均队列深度再设置下限阈值留出至少 20% 的余量。另一个类似问题是丢弃概率设得过高比如默认 50%对 TCP 流来说过于激进。我一般把尽力转发类的丢弃概率控制在 10% 到 20%EF 类直接设置为不参与 WRED 丢弃。5.4 现象GTS 整形后时延反而飙升做了出方向 GTS 整形速率是稳了但视频会议出现了明显卡顿。原因是整形本身引入了缓存报文等待发送的时间变长。GTS 的核心机制是“缓存并平滑”这天然会带来额外的时延对 VoIP 这类实时业务是致命的。解决方法是区分业务类型对实时业务尽量不用整形用 LLQ 队列优先调度对非实时业务再用 GTS 限制速率。如果物理链路本身带宽不足把整形速率调大一些让缓存队列尽量为空。还有一条铁律不要在承载 VoIP 的接口出方向配置过低的 GTS宁可让少量突发打到下游也不要让所有语音报文都排队等待。5.5 现象MPLS 网络跨域后 QoS 全部失效PE 设备上配置了完整的 QoS 策略CE 到 CE 的流量却完全没有优先级保障。逐跳排查后发现MPLS 域内 EXP 值传递正常但在标签弹出那一跳EXP 到 DSCP 的映射表是空的报文恢复成普通 IP 报文后优先级信息丢失。原因是倒数第二跳弹出标签后没有把 EXP 信息回写到 IP 报文的 DSCP 字段。解决方法是检查弹出节点上的 EXP-DSCP 映射配置并确认隧道尾端设备的信任模式。跨运营商或跨 AS 的场景里还要保证双方的 DSCP 与 PHB 映射一致否则报文在边界就可能被重新分类。6. 验证三步法与 QoS 数字地图把白皮书变成可复现的检查清单白皮书读得再熟最终还得落到现网验证上。我每次做完一套 QoS 策略至少要走三个验证动作。第一步是打标验证Linux 下用ping -Q 46 10.1.1.1模拟 DSCP EF 的语音流用ping -Q 0模拟普通尽力转发流然后在设备上执行display qos policy interface查看两类流量分别命中哪个类、进了哪个队列。这一步能抓出分类规则写错、ACL 匹配顺序颠倒这类低级问题。第二步是看统计。display qos car statistics能看出入方向监管丢弃的报文数量display qos queue statistics能看各队列的深度和丢弃情况。如果 EF 类队列的丢弃量持续为 0说明带宽充足LLQ 没被触发如果 AF 类队列深度一直很高说明数据流量比预期大需要重新核算带宽分配比例。统计数字会撒谎的情况也有比如 QoS 策略没有真正应用在物理接口上此时统计里会显示空值优先检查display qos policy interface的生效状态。第三步是压力测试。找一台测试仪或者用 iperf 打满链路同时跑一路语音流观察语音流的时延抖动。没有测试仪的话可以用多台 PC 同时下载大文件制造拥塞再验证语音是否依然清晰。这里顺带提一个我在其他项目里发现的类比ROS2 的 QoS 策略虽然作用在 DDS 层与网络层的 QoS 完全不同但它的 reliability、durability 参数设置思路跟网络侧的队列调度是同一个逻辑——先明确业务对丢失和时延的容忍度再配置相应的优先级策略。最后分享一个我一直在用的方法叫 QoS 数字地图。把每类业务列出一张表对应业务类型、DSCP 值、队列 ID、带宽上限、丢弃优先级五个字段先定业务再定映射。白皮书里的表 2 和表 4 正好可以当起点实际项目再按客户的需求调整。从那以后我每次做 QoS 方案都强制自己先画这份地图再动手敲命令配置翻车的概率低了很多。这份白皮书最大的价值也在这里它不是告诉你某个命令怎么敲而是先把模型、机制、边界讲清楚让你在敲命令之前就知道自己在解决什么问题。希望帮到你。本文还有配套的精品资源点击获取 QoS网络白皮书实战解读：从DSCP标记到拥塞管理配置
简介《QoS网络技术白皮书.docx》是一份面向网络运营商、行业用户及网络工程师的技术参考资料聚焦传统IP网络在VoIP、视频会议等实时业务中的不足系统阐述如何通过区分服务实现网络资源优化分配与关键业务保障。整份资源仅包含1个docx格式文档压缩包大小2.53MB内容组织完整适合作为QoS原理学习与H3C设备部署方案的随身手册。已有110人学习下载。文档从Best-Effort、IntServ与DiffServ三种服务模型讲起详细展开流量分类与标记、拥塞管理CQ、PQ、CBWFQ、拥塞避免RED/WRED、流量监管与整形、链路效率机制及MPLS QoS等关键技术并配有缩略语对照与目录式结构便于快速定位知识点。读者可借此系统建立QoS技术框架掌握从流量识别到队列调度、从拥塞控制到SLA保障的完整实施路径为网络规划与故障排查提供直接参考。1. 从 Best-Effort 到 DiffServ这份 QoS 白皮书解决什么问题前阵子替客户排查一个视频会议卡顿的问题出口带宽明明还有余量可会开到一半画面还是糊成一团。抓包一看语音流和数据流全挤在同一个 FIFO 队列里。这就是传统 IP 网络最典型的毛病——所有报文无差别对待转发设备只负责尽力而为对时延、抖动、丢包率一概不承诺。后来照着这份《QoS 网络技术白皮书》的思路把流量分类、队列调度、拥塞避免逐项配下去问题才算真正解决。这份资源覆盖了 Best-Effort、IntServ、DiffServ 三种服务模型把流量分类标记、拥塞管理、拥塞避免、流量监管与整形、链路效率机制以及 MPLS QoS 全部串成一条可落地的解决方案链。适合做企业网、运营商承载网、VoIP 和视频会议保障的网络工程师也适合刚接触 QoS 想系统梳理知识体系的从业者。2. 流量分类和标记DSCP、IP Precedence、CoS 映射与处理顺序2.1 各 QoS 技术在同一设备上的处理顺序白皮书里有一句话特别关键流量分类和标记是基础是有区别地实施服务的前提。很多人在设备上配置了一堆队列策略却发现不生效回头一查往往是入方向的分类规则就没写对。QoS 各技术在同一条转发路径上的处理顺序是这样的报文从接口进来先做流量分类和标记紧接着是 CAR 流量监管决定是否限制或惩罚超规格流量报文往接口外出时再进入拥塞管理和拥塞避免环节由队列调度决定发送次序由 WRED 决定是否主动丢弃最后如果配置了 GTS 或 LR再在出方向做速率整形和总速率限制。这个顺序直接决定了配置的位置分类和监管作用在接口入方向队列和整形作用在接口出方向。有些工程师习惯把所有 QoS 动作都堆在入方向结果下游设备看到的 DSCP 值是对的但本设备根本没参与队列调度等于忙活半天只帮别人做了标记。白皮书的图把这条链路画得很清楚先分类后监管再排队最后整形每一步的职责边界是分开的。2.2 IPv4、IPv6、以太网三类业务分类位IPv4 报文在 ToS 域里定义了 8 种 IP 优先级从 Routine 到 Network Control数值越大优先级越高。DiffServ 模型则把 ToS 域重新定义成 DSCP 字段一共 64 种取值白皮书列出了典型 PHB 的推荐值EF 是 46对应交互式语音AF41 是 34对应交互式视频AF31 是 26对应视频控制AF2x 是 18、20、22对应事务型交互业务AF1x 是 10、12、14对应批量数据。几个关键映射我整理成了表平时做方案直接照这个表对。表 2-1 典型 DSCP PHB 定义业务类型DSCP PHBDSCP 值十进制网络控制CS756IP 路由CS648交互式语音EF46交互式视频AF4134视频控制AF3126事务型交互AF2x18、20、22批量数据AF1x10、12、14流媒体视频CS44电话信令CS33网络管理CS22尽力转发BE0IPv6 在报头里保留了类似 IPv4 的 ToS 域称为传输级别域 TC同时新增了 20 比特的流标签。白皮书指出IPv6 QoS 可以基于 TC 域做分类和标记流标签则留给后续扩展。以太网这边802.1Q 的 VLAN TAG 里用 3 比特定义 CoS 值一共 8 种业务优先级。同一份白皮书给出的建议是语音业务时延一般要求小于 10 毫秒视频业务小于 100 毫秒网络控制报文要保证低丢包率。这些数字直接决定你后面把不同业务扔进哪个队列。2.3 分类标记配置ACL 匹配与 DSCP 重标记配置流量分类和标记时常见做法是先用 ACL 匹配五元组或网段再定义类和行为最后在接口入方向应用。以 H3C Comware V7 的写法为例system-view # 定义 ACL 3001匹配视频会议终端所在网段发往对端的 UDP 流 acl advanced 3001 rule 0 permit udp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 # 定义流量分类 video关联 ACL 3001 traffic classifier video if-match acl 3001 # 定义流量行为 mark-ef把命中报文的 DSCP 重标记为 EF traffic behavior mark-ef remark dscp ef # 定义策略 video_inbound将分类与行为绑定 qos policy video_inbound classifier video behavior mark-ef # 在入接口应用该策略 interface GigabitEthernet1/0/1 traffic-policy video_inbound inbound这段配置的逻辑是先通过 ACL 圈定目标流量再用 traffic classifier 把它归为一类然后由 traffic behavior 执行动作。remark dscp ef的意思是重标记 DSCP 值为 46也就是 EF 加速转发。注意动作里没有涉及任何队列调度因为分类标记只是给报文打标签真正的优先发送要靠后续的出方向队列来兑现。参数上有两个容易被忽略的地方。一是 ACL 的匹配条件越精确分类覆盖范围越可控但规则数也会膨胀建议按业务网段聚合而不是精确到单个 IP。二是策略应用方向入方向做标记可以确保本设备以及下游设备都能看到统一的 DSCP 值但如果你希望本设备自己也参与队列调度那么出方向也要留意是否缺策略。标记是给下游看的队列才是给自己用的两者不冲突但很多人只做了前者。2.4 IEEE 802.1Q 推荐的 CoS 到队列映射二层交换场景里802.1P 的 CoS 值最终要映射到出端口的不同队列。白皮书给出了 IEEE 802.1Q 推荐的映射关系以常用的 4 队列为例表 2-2 IEEE 802.1Q 推荐的 CoS 与 4 队列映射队列 ID业务类型1Best Effort、Background2Critical Applications、Excellent Effort3Voice、Video4Network Control、Internetwork Control这个映射表直接回答了“标记完了往哪个队列放”的问题。如果你的交换机只有 4 个队列语音视频放队列 3网络控制放队列 4普通上网业务放队列 1数据库这类关键应用放队列 2。实际配置里有些设备支持自定义映射表我一般会基于这个推荐表微调把视频会议这类对时延敏感的业务和普通 VoD 流媒体拆开避免它们互相挤占带宽。3. 拥塞管理队列实战FIFO、PQ、CQ、WFQ、CBWFQ 怎么选怎么配3.1 拥塞是怎么发生的队列又是怎么解决的拥塞的本质是报文到达速度超过接口发送速度。比如局域网是 10M 接入出口串口只有 2M那么路由器串口必然成为瓶颈。此时报文如果直接丢弃应用层会重传进一步加剧拥塞如果全部缓存时延又无法控制。队列技术就是在接口出方向建立缓冲区把报文按类别送入不同队列再通过调度算法决定谁先出队。白皮书对 FIFO 的定义最简单不对报文分类先进先出。它的优点是实现成本低缺点是关键的语音流可能被批量下载的数据堵在后面。FIFO 只适合没有拥塞风险的链路或者作为其他队列机制的兜底。3.2 PQ 和 CQ绝对优先与带宽比例PQ 把所有报文分成最多 4 类分别进入高、中、正常、低四个队列。调度时先发高优先队列发空了再发中队列以此类推。这样做的好处是 VoIP 这类高优先级业务能得到绝对的时延保障坏处是如果高优先队列持续有流量低优先队列可能被饿死。白皮书特别提到一个场景关键业务报文总是被先发送直到暂时没有关键业务的报文才发送普通业务报文。这个“绝对优先”既是优势也是风险后面避坑章节我会专门展开。CQ 的设计则不同它把报文分成最多 16 个队列每个队列按定义的比例占用接口带宽。出队时按字节数轮询比如队列 1 每次取 6000 字节、队列 2 取 2000 字节就能近似实现 60% 和 20% 的带宽分配。CQ 避免了 PQ 的低队列饿死问题但对实时业务来说轮询带来的时延抖动比 PQ 明显。所以 CQ 适合对带宽比例有要求但对时延不极敏感的业务比如给数据库访问分配保证带宽同时给 FTP 设定上限。3.3 WFQ、CBWFQ 与 RTP 优先队列WFQ 是加权公平队列它基于流的优先级和权重来分配带宽。优先级高的流获得更多调度机会同时低优先级流也不会完全得不到带宽。WFQ 的优点是配置简单不需要手工定义分类规则系统自动按会话区分流缺点是难以对特定业务做精细化保障因为它依赖报文中已有的优先级字段。CBWFQ 则在 WFQ 基础上引入了“类”的概念先按自定义规则把流量分类再为每个类单独指定带宽。白皮书的说法是“基于类的加权公平队列”它兼顾了 CQ 的带宽比例能力和 PQ 的优先调度能力。实际工程里还有一个更常用的组合叫 LLQ低时延队列。它在 CBWFQ 的基础上把语音这类对时延极敏感的业务放进一个优先队列其他类仍然按 WFQ 调度。RTP 优先队列则专门针对 RTP 报文识别语音流后直接给予优先发送。三类队列的处理差异用一张表来对比更直观表 3-1 常用队列技术对比队列类型分类能力队列数量是否可能饿死低优先级典型场景FIFO不分类1无优先级概念无拥塞链路PQ支持最多 4是VoIP 绝对优先CQ支持最多 16否按比例分配带宽WFQ自动按流动态否默认公平调度CBWFQ支持自定义视配置语音数据混合RTP 优先队列识别 RTP与队列结合否VoIP 低时延保障3.4 CBWFQ 配置示例语音带宽怎么保证以 H3C Comware V7 为例把语音流放进 LLQ 并保证带宽其他数据流按 AF 类分配带宽的常见配置如下system-view # 定义语音类匹配 DSCP EF 的流量 traffic classifier voice if-match dscp ef # 定义语音行为进入低时延队列保证 512 kbps 带宽 traffic behavior voice-llq queue llq bandwidth 512 # 定义数据类匹配 DSCP AF21 的流量 traffic classifier data if-match dscp af21 # 定义数据行为进入 AF 队列保证 2048 kbps 带宽 traffic behavior>system-view # 入方向匹配 DSCP AF11 的流量限制 CIR 为 4000 kbps acl advanced 3010 rule 0 permit ip traffic classifier af11 if-match dscp af11 traffic behavior car-af11 car cir 4000 cbs 40000 ebs 40000 red-action discard qos policy car-inbound classifier af11 behavior car-af11 interface GigabitEthernet1/0/1 traffic-policy car-inbound inbound # 出方向对接口所有流量整形到 2000 kbps interface Serial1/0 qos gts outbound cir 2000 cbs 20000CAR 参数里cir是承诺信息速率cbs是承诺突发尺寸ebs是超出突发尺寸red-action discard表示超速报文直接丢弃。这里cbs的设置尤其关键它决定你能容忍多大的瞬时突发。如果 cbs 太小即使平均速率没超突发也会被误杀。GTS 参数则简单得多它不丢包只是把超出cir的报文缓存进队列按 2 Mbps 的速率往外发。一个需要留意的副作用是如果入方向持续大于整形速率队列会越积越长时延随之增大。所以 GTS 只适合入向速率略大于出向速率的场景差距过大时要考虑同时配置 CAR 限制入向速率否则整形的缓存就成了延迟的温床。4.5 MPLS 网络里的 QoS 组合白皮书第 3 章单独讲了 MPLS QoS。MPLS DiffServ 的核心是把 DSCP 映射到 MPLS 报文的 EXP 域再由标签交换路径上的每一跳根据 EXP 值执行 PHB。这里有个容易忽略的点在倒数第二跳弹出标签后设备需要把 EXP 信息重新映射回 IP 报文的 DSCP否则 QoS 策略在最后一跳就断了。MPLS-TE 则解决的是带宽资源预留的问题。它通过 RSVP-TE 建立具备带宽约束的隧道把流量引入指定路径。白皮书提到 DS-TE 的思路就是 DiffServ 和 TE 结合将流量分为多个类每类设定独立的带宽约束。简单理解DiffServ 管优先级TE 管路径和带宽两者叠加后既能走指定路径又能保证路径上的带宽资源不被其他流量抢走。5. 常见问题与避坑QoS 配置翻车的五个典型现场5.1 现象高优先级队列抢断所有带宽SSH 都连不上一旦给 PQ 的高优先队列配置了过大的带宽且持续有语音或视频流量注入低优先级的运维流量会被完全饿死。有次配完后控制台还能操作远程 SSH 直接超时就是典型的 PQ 饥饿问题。原因是 PQ 的调度机制是严格优先的高优先队列只要非空调度器就不会轮到低优先队列。解决思路有两个一是把运维管理流量放进更高优先级的队列二是改用 LLQ 而不是 PQ。LLQ 在优先发送的同时设置了带宽上限超过上限的语音流量会被转入普通队列这样低优先级流量永远有调度机会。从那以后我只要看到 PQ 就条件反射去看高优先队列的带宽上限。5.2 现象DSCP 标记明明配了下游设备却不认账入方向做了重标记抓包也看到 DSCP 值变成了 EF但下一跳设备的队列统计毫无变化。翻配置才发现下游设备的入方向又做了一次分类匹配的是 IP Precedence 而不是 DSCP两边字段没对齐等于白标。原因是 DiffServ 域跨设备时DSCP 到 PHB 的映射关系没有约定一致。解决方法是把整条链路上所有设备的分类匹配字段统一要么全用 DSCP要么全用 IP Precedence并且在接口的信任模式上保持一致。我通常会在方案文档里画一张“DSCP 传递图”标注每个设备信任哪个字段、重标记在哪一跳发生避免各设备各玩各的。5.3 现象WRED 配置后正常业务也开始丢包某次现网配置 WRED 后业务侧反馈丢包率上升但接口并没有拥塞。查了队列深度发现平均队列长度一直在下限阈值附近波动随机丢弃已经提前开始工作了。原因是 WRED 的下限阈值设得过低低于正常突发时的队列深度。解决方法是先观察一段时间的平均队列深度再设置下限阈值留出至少 20% 的余量。另一个类似问题是丢弃概率设得过高比如默认 50%对 TCP 流来说过于激进。我一般把尽力转发类的丢弃概率控制在 10% 到 20%EF 类直接设置为不参与 WRED 丢弃。5.4 现象GTS 整形后时延反而飙升做了出方向 GTS 整形速率是稳了但视频会议出现了明显卡顿。原因是整形本身引入了缓存报文等待发送的时间变长。GTS 的核心机制是“缓存并平滑”这天然会带来额外的时延对 VoIP 这类实时业务是致命的。解决方法是区分业务类型对实时业务尽量不用整形用 LLQ 队列优先调度对非实时业务再用 GTS 限制速率。如果物理链路本身带宽不足把整形速率调大一些让缓存队列尽量为空。还有一条铁律不要在承载 VoIP 的接口出方向配置过低的 GTS宁可让少量突发打到下游也不要让所有语音报文都排队等待。5.5 现象MPLS 网络跨域后 QoS 全部失效PE 设备上配置了完整的 QoS 策略CE 到 CE 的流量却完全没有优先级保障。逐跳排查后发现MPLS 域内 EXP 值传递正常但在标签弹出那一跳EXP 到 DSCP 的映射表是空的报文恢复成普通 IP 报文后优先级信息丢失。原因是倒数第二跳弹出标签后没有把 EXP 信息回写到 IP 报文的 DSCP 字段。解决方法是检查弹出节点上的 EXP-DSCP 映射配置并确认隧道尾端设备的信任模式。跨运营商或跨 AS 的场景里还要保证双方的 DSCP 与 PHB 映射一致否则报文在边界就可能被重新分类。6. 验证三步法与 QoS 数字地图把白皮书变成可复现的检查清单白皮书读得再熟最终还得落到现网验证上。我每次做完一套 QoS 策略至少要走三个验证动作。第一步是打标验证Linux 下用ping -Q 46 10.1.1.1模拟 DSCP EF 的语音流用ping -Q 0模拟普通尽力转发流然后在设备上执行display qos policy interface查看两类流量分别命中哪个类、进了哪个队列。这一步能抓出分类规则写错、ACL 匹配顺序颠倒这类低级问题。第二步是看统计。display qos car statistics能看出入方向监管丢弃的报文数量display qos queue statistics能看各队列的深度和丢弃情况。如果 EF 类队列的丢弃量持续为 0说明带宽充足LLQ 没被触发如果 AF 类队列深度一直很高说明数据流量比预期大需要重新核算带宽分配比例。统计数字会撒谎的情况也有比如 QoS 策略没有真正应用在物理接口上此时统计里会显示空值优先检查display qos policy interface的生效状态。第三步是压力测试。找一台测试仪或者用 iperf 打满链路同时跑一路语音流观察语音流的时延抖动。没有测试仪的话可以用多台 PC 同时下载大文件制造拥塞再验证语音是否依然清晰。这里顺带提一个我在其他项目里发现的类比ROS2 的 QoS 策略虽然作用在 DDS 层与网络层的 QoS 完全不同但它的 reliability、durability 参数设置思路跟网络侧的队列调度是同一个逻辑——先明确业务对丢失和时延的容忍度再配置相应的优先级策略。最后分享一个我一直在用的方法叫 QoS 数字地图。把每类业务列出一张表对应业务类型、DSCP 值、队列 ID、带宽上限、丢弃优先级五个字段先定业务再定映射。白皮书里的表 2 和表 4 正好可以当起点实际项目再按客户的需求调整。从那以后我每次做 QoS 方案都强制自己先画这份地图再动手敲命令配置翻车的概率低了很多。这份白皮书最大的价值也在这里它不是告诉你某个命令怎么敲而是先把模型、机制、边界讲清楚让你在敲命令之前就知道自己在解决什么问题。希望帮到你。本文还有配套的精品资源点击获取