QoS详解：从队列调度到DSCP标记，解决网络拥塞与延迟抖动

搞网络时间久了的兄弟应该都有这种感觉：带宽明明加到了千兆、万兆，一到业务高峰，视频会议照样卡成PPT，语音断续得没法听，关键业务系统响应慢得像蜗牛。每次排查到最后，发现链路带宽其实没跑满，但体验就是上不去。这时候基本可以断定，问题出在设备对流量“一视同仁”上——所有人挤同一扇门，谁也快不了。

这就是QoS（Quality of Service，服务质量）要解决的核心问题：在网络资源有限的前提下，让关键流量优先通过，让非关键流量给重要业务让路。它不是把带宽变大，而是把有限的带宽用得更聪明。这篇文章我打算从QoS的底层原理讲到队列调度算法，再给出可直接抄作业的配置思路和排障方法，适合刚接触网络技术的同学，也适合被QoS配置折磨过的运维老手。

1. 网络拥塞的本质与QoS的定位

1.1 为什么带宽够了还是卡

很多人有个误区，觉得网络卡就是带宽不够，加带宽就完事了。但实际上，网络设备的转发是“排队”的——数据包到达设备后，不会被瞬间转发出去，而是要进入队列等待处理，就像高速路收费站，车道再多，出口闸机就那几个，车流一多必然排队。

排队产生的最直接后果就是延迟和抖动。延迟指数据包从源到目的耗费的时间，抖动则是延迟的变化幅度。语音和视频这类实时业务对抖动极其敏感，哪怕平均延迟只有50ms，但中间某几秒延迟突然跳到300ms，通话就会撕心裂肺地卡顿。排队排到极端情况，队列缓存溢出，数据包被直接丢弃，这就是丢包。对TCP流量而言，丢包还会触发重传，进一步加剧拥塞，形成恶性循环。

QoS的本质，就是管理这种排队行为。它不改变链路的总容量，但能决定谁在队列里排前面、谁排后面、谁转走别的通道。生活里很好理解：急诊室一定优先处理危重病人，VIP通道不需要和普通旅客挤安检口。网络世界里，QoS就是给数据包划分三六九等的“分诊系统”。

1.2 需要QoS的典型场景

哪些业务真正需要QoS？我做运维这些年，见的比较多的有三类。

一是VoIP语音和视频会议。这类业务的实时性要求极高，单向延迟超过150ms就能感觉到明显延迟，抖动超过30ms就能听到回声或断续。更重要的是，语音流量通常包很小、速率不高，大量突发流量一挤，语音包就丢了。如果没有QoS，哪怕只有几百Kbps的语音流量，也可能被大流量下载完全淹没。

二是关键业务系统的交互流量。比如某公司的ERP系统、数据库查询、交易请求，这些流量本身不大，但对延迟敏感。一个订单提交请求，可能就几十KB的数据，但路上走个几秒钟，用户就崩了。尤其在带宽被视频下载占满的时候，不加QoS你根本控制不了体验。

三是多业务融合的网络。比如某公司一条专线里同时跑了办公上网、视频监控、文件备份、云服务等多类业务。监控流和备份流占带宽大，办公交互流量小但对体验要求高。没有QoS做差异化调度，就只能是大家一起卡，然后互相甩锅。

QoS适合谁？我觉得只要是网络里有两种以上不同重要程度的业务，都值得做QoS。尤其是出口带宽有限的分支机构、园区网汇聚点、数据中心出口这些链路收敛点，QoS的价值体现得最明显。

1.3 QoS的四个关键指标

衡量QoS效果，通常看四个指标：带宽、延迟、抖动、丢包率。

带宽不用多说，是一切的基础。但QoS里的带宽不仅仅是链路带宽，还包括“承诺带宽”——给某类业务承诺的最低保证值，以及“最大带宽”——允许某类业务突破到的高峰值。延迟是数据从一端到另一端的时间总和，包括处理延迟、队列延迟、传输延迟。抖动就是延迟的变化幅度，对实时业务的影响甚至超过延迟本身。丢包率是单位时间内丢包的比例，TCP业务对丢包敏感，UDP实时业务对丢包也有一定容忍上限。

这四个指标相互影响，比如队列调度就是拿延迟和抖动换带宽，拿丢包换优先权。做QoS配置时，心里必须有这笔账：你想保什么、愿意牺牲什么。

2. QoS的核心机制：分类、标记与队列调度

2.1 流量分类与标记：数据包的“身份标签”

QoS的第一步是识别流量。你得先告诉设备哪些流量是VIP，哪些流量是普通人，它才知道怎么调度。这就是分类与标记。

分类最基础的方式是五元组匹配：源IP、目的IP、源端口、目的端口、协议号。比如你要识别所有到某台服务器3389端口的RDP流量，或者所有UDP端口范围在16384-32767之间的语音流量，都可以用ACL或class-map来完成匹配。这种方式精确，但配置量大、扩展性差，适合在小规模场景兜底使用。

更有扩展性的做法是信任标记。二层的802.1p优先级（也叫CoS）用了3个比特，取值范围0-7；三层的IP优先级用了TOS字段的前3个比特，取值范围0-7；而现代的IP DSCP值则使用TOS字段的前6个比特，取值范围0-63。DSCP是目前最主流的标记方式，它把流量分成EF（加速转发）、AF（确保转发）、CS（类别选择）等几个PHB（逐跳行为）类。EF一般给语音，AF41/AF42这类给视频，CS3这类给关键业务数据，Best-Effort（也就是DSCP 0）给普通上网流量。

标记动作发生在信任边界。也就是说，你需要在网络的边缘接入位置决定：进来的流量带着什么标记，我信不信它。如果入口交换机不信任数据包的DSCP值，就必须重新标记，否则后面所有QoS策略都是空谈。这条“信任边界”的规划，是QoS部署中最容易被忽略、但影响最大的一个环节。

2.2 队列调度算法：数据包的“排队规则”

标记完就得进队列了，这部分的算法选择和参数配置直接影响QoS的效果。我先把主流算法讲清楚，再说怎么选。

FIFO（先入先出队列）是最基本的排队方式，数据按到达顺序排队，没有任何优先级概念。它简单到几乎不消耗设备资源，但也是对拥塞最无能为力的算法。默认情况下很多设备接口走的就是FIFO。

PQ（优先队列）是个性化十足的算法。它把队列分成高、中、普通、低四个级别，数据包依据优先级进入对应队列，调度器会先把高优先级队列清空，再去处理下一个级别的队列。PQ的优点是高优先级流量延迟极低，缺点也很致命——一旦高优先级流量持续存在，低优先级队列可能永远得不到服务，这叫“饿死”。生产环境下基本不会单独用PQ，除非你对低优先级流量完全无所谓。

CQ（自定义队列）就是为了解决PQ饿死问题而生的。它按权重循环服务每个队列，每个队列在每轮调度中可以发送一定字节数的数据。比如队列1可以发4000字节，队列2发2000字节，队列3发1000字节，这样低优先级的流量也能分到带宽，只是分少一点。CQ是字节数权重的公平，但不做“流”级别的公平。

WFQ（加权公平队列）则是真正端到端的公平调度算法。它会根据流的数量动态计算每一条流对应的权重，带宽按权重比例分配。流量越少的流，获得带宽的优先级反而越高。WFQ对小流量、交互式流量友好，但它按“流”来调度，几百上千条流的时候计算开销大，而且它无法对某类业务设置绝对优先。

CBWFQ（基于类的加权公平队列）是目前企业网络中应用最广泛的调度算法。你可以把流量分成多个类，为每个类指定带宽占比或者绝对带宽值，再搭配WFQ做类内部的公平调度。比如给语音类分配16Mbps，给视频类分配32Mbps，给默认类分配剩余带宽。CBWFQ解决了“按类保证带宽”的问题，但它的本质还是加权公平，不是严格优先。

LLQ（低延迟队列）是CBWFQ的增强版，专门为语音、视频这类实时业务设计的。它允许你在CBWFQ里设置一个优先队列（Priority Queue），调度器会优先处理这个队列中的流量，同时通过“严格优先级+管制器”的配合，防止优先队列占满全部带宽饿死其他队列。LLQ是目前语音视频QoS的事实标准，几乎所有厂商的设备都支持。

2.3 拥塞避免与流量整形：提前动手的艺术

队列调度是拥塞发生后的处理手段，而拥塞避免和流量整形则是拥塞发生前的预防手段。

拥塞避免最主流的技术是WRED（加权随机早期检测）。它的思路是在队列还没满的时候就随机丢弃部分低优先级的数据包，让源端感受到拥塞从而降低发送速率。为什么要随机丢而不是等队列满了再丢？因为TCP有拥塞控制机制，你提前丢几个包，TCP就会减半发送速率，反而避免了大面积丢包导致的重传风暴。这就是“惩罚轻的，保护重的”的智慧。

流量整形（Shaping）和流量监管（Policing）则是控制发送速率的两种手段。流量监管是“硬伤”——超出速率的数据包直接丢弃或降级，就像高速路限速摄像头，超速就拍。流量整形是“软磨”——超出速率的数据包先放到缓冲区里排队，慢慢发，就像堵车时交警分批放行，不罚款但你要等。整形适合对延迟容忍度高的业务，监管适合对超限流量零容忍的场景。

2.4 令牌桶：速率控制的底层算法

无论是整形还是监管，底层都离不开令牌桶算法。这里我稍微展开讲一下，因为理解了令牌桶，你就理解了QoS里所有涉及速率的配置参数。

令牌桶的核心思想是：系统按一定速率向桶里投放令牌，数据包要发送必须拿令牌，有多少令牌就发多少数据。桶的容量是有限的（即突发尺寸Bc），如果桶满了，多余令牌直接溢出丢弃；如果数据包来太多，令牌不够就发不出去。

关键参数是CIR（承诺信息速率）、Bc（正常突发尺寸）、Be（最大突发尺寸）。CIR决定平均发送速率，Bc决定单次可以突发的最大数据量。设Tc为时间间隔，它们的关系是Tr = Bc / CIR。举个例子：某业务运营商承诺CIR为512kbps，配置Bc为6400字节。那么Tr = 6400 * 8 / 512000 = 0.1秒，也就是每100ms补充一批令牌。如果实际突发速率超过CIR，超出部分必须靠Be撑住，Be花完就得等下一轮令牌补充。

这个计算的意义在于：合理的Bc值决定突发容忍度。Bc设小了，稍微有点突发就被削峰，业务看起来速率不达标；Bc设大了，突发流量可能长时间抢占带宽，影响其他业务。我见过不少工程师在配置CIR时只填了速率，Bc参数随便填或留空，结果整形效果和预期差一大截。令牌桶参数之间是联动的，不是孤立配置。

3. 主流的QoS架构与端到端部署思路

3.1 IntServ与DiffServ架构对比

QoS的架构设计，目前主流有两种思路：IntServ（综合服务体系）和DiffServ（区分服务体系）。

IntServ走的是“先申请后使用”的路子。应用在发包之前，先通过RSVP信令向沿途所有设备申请带宽资源，每个设备预留好位置，然后应用再发送流量。这就像你订餐厅包间，提前打电话确认有位子，才带人过去。IntServ可以为单独一条流提供精确的端到端保障，但代价是每个设备都要保存每条流的状态，扩展性极差。别说大网络，几百条并发流都能把路由器状态表撑爆，所以目前只在特定场景（比如MPLS TE的部分功能）里用。

DiffServ走的是“分门别类”的路子。它不为单条流预留资源，而是在网络入口把流量打上DSCP标记，沿途每个设备就按标记执行对应的PHB行为——加速转发、保证转发或者尽力而为。DiffServ不需要设备保存流状态，扩展性好，是目前企业网络QoS的事实标准。但它的保障是“相对的”——同一类里的流量多了，整体体验还是会下降，只是比普通流量好一些。

生产环境里，我基本只推荐DiffServ。原因很简单：可扩展、易维护、厂商生态成熟。RSVP那套东西，大多数场景都是自找麻烦。

3.2 信任边界与端到端策略的规划

部署DiffServ架构的QoS，第一个要决策的就是信任边界设在哪里。

打个比方，你公司出口路由器和运营商对接，运营商把你的干线限了速。你给语音包打了EF标记，但如果入口交换机不信任这个标记，直接清零，那到出口路由的时候所有包都变成0，QoS策略全白搭。所以信任边界必须设在可信的终端接入层——比如IP话机直连的接入交换机、公司内网终端接入的汇聚交换机。边界往下，是“不信任区”，进来的流量必须打上设备指定的标记；边界往上，是“信任区”，流量原有标记原样传递。

一种常见的做法是：接入交换机上，对连接IP话机的接口做“电话端口信任”，自动识别语音VLAN并打上EF；对连接PC的接口做“数据端口限速+重标记”，把PC发出的所有流量统一打成BE。然后把接入交换机上行口设为信任，汇聚和核心交换机就只管按标记调度。

端到端策略的规划顺序，我建议从下往上推：先确定业务分类和DSCP映射表，再确定每类流量的队列调度策略，再确定信任边界和重标记点，最后在关键链路上做限速整形。先纸上谈兵画清楚拓扑和数据流，再动手敲配置，能少踩很多坑。

3.3 三层到二层：QoS需要分层协同

很多工程师做QoS只关注三层路由器的策略，忘了二层交换机的调度，结果哑火了。实际上，数据从终端到服务器要穿过好多台交换机，每一台交换机的拥塞点都可能成为瓶颈。三层设备上的QoS只解决三层转发部分的调度，二层接口上的出向队列同样需要配置。

例如某台接入交换机的一个千兆口接了一台PC，这个PC在跑大流量下载，拥塞点在接入交换机的出接口，如果这个接口不配置出向队列，大流量照样挤压语音流量。所以在主流厂商的交换机上，你需要在接口配置“trust dscp” + 优先级队列调度，让二层也聪明地转发。

QoS从来不是一个单点功能，而是一条链路上的协同动作：终端打标记，接入交换机标记或重写，汇聚和核心执行调度，出口做限速整形。任何一环掉了链子，整个QoS的效果都会打折扣。

4. 基于企业典型场景的QoS配置实战

4.1 场景需求与设计原则

我拿一个自己做过多次的企业分支网络场景来举例。某公司有三条业务线：视频会议（语音+RTP视频）、ERP系统、普通办公上网。出口是一条200Mbps的专线，没有做QoS时，一到下午业务高峰，视频会议卡得没法开，ERP页面频繁超时，IT部门每天被投诉。

梳理需求后发现，真实痛点有两个：一是视频会议流量需要在拥塞时绝对优先通过，二是ERP的交互流量需要保证基本带宽，同时办公下载不能把链路挤死。

定下的QoS设计原则有三条：

第一，语音永远最高优先级，因为它的延迟和抖动容忍度最低。第二，ERP会话流量给到保证带宽，确保基础可用性，但允许它在有空余带宽时突破保证值。第三，普通办公和文件下载只能使用剩余带宽，但也不能让它们完全饿死。

4.2 配置指令逐条拆解

我以思科IOS设备为例来讲配置过程。核心分三步：定义类、定义策略、应用策略。

第一步，定义流量类。用class-map把DSCP值为EF的语音流量、AF41的视频流量、以及发往ERP服务器的流量分别匹配出来。

class-map match-all VOICE match dscp ef class-map match-all VIDEO match dscp af41 class-map match-all ERP_TRAFFIC match access-group name ERP_ACL

这里要注意match-all和match-any的区别。match-all表示所有match条件都必须满足才归入这个类，match-any则是只要有一个match条件满足就算。多个match条件同时存在时，这俩区别很大，容易配错。

第二步，定义策略映射。语音类走LLQ优先队列，带宽给足；视频类走CBWFQ，拥有保证带宽；ERP类也走CBWFQ，给一个保证带宽；默认类用fair-queue来公平分配剩余带宽。

policy-map WAN_EDGE_QOS class VOICE priority 20000 class VIDEO bandwidth 50000 class ERP_TRAFFIC bandwidth 30000 class class-default fair-queue

语音类的priority 20000意味着LLQ严格优先队列最大可以占用20Mbps。这个数值要等于或略大于语音业务实际最高速率，太大可能挤占其他业务的带宽，太小则语音在峰值时会被丢弃。视频和ERP的bandwidth值则根据实际业务用量和合同带宽综合分配。

第三步，把策略应用到接口出方向。

interface GigabitEthernet0/1 description WAN_Uplink service-policy output WAN_EDGE_QOS

出向的service-policy才有实际意义，入向只能做标记和分类。很多人刚接触时把policy挂到入方向，折腾半天没效果，就是这个原因。

4.3 入口标注与接口信任

标签的写入动作通常在边缘接口的入方向完成。以接入交换机为例，可以让PC接口统一把VLAN内的流量标记为CS3或者AF32，语音IP话机接口把语音流量标记为EF，摄像头接口把视频流标记为AF41。

interface GigabitEthernet0/1 description PC_Access switchport access vlan 100 mls qos trust cos mls qos cos 3

有经验的老哥应该知道，直接把信任关掉、统一重写标记是最稳妥的做法。如果终端设备自己会打DSCP，而你又不能完全信任终端，最安全的方式就是不信任并重新标记。这个开关位置极其重要，我之前见过某公司内部BYOD设备打得DSCP标记杂乱无章，导致队列调度逻辑直接失灵。

4.4 验证与效果确认

配置做完必须验证，不能配完就拍屁股走人。思科设备上可以这样查：

show policy-map interface GigabitEthernet0/1 show mls qos interface GigabitEthernet0/1 show mls qos ip dscp

查看policy-map的统计，重点看每个类的分类命中包数、队列丢弃包数，以及LLQ优先队列的丢包计数。如果语音类丢包不为0，说明priority给小了，或者匹配粒度有问题。如果默认类丢弃很高，说明带宽分配比例失衡。

做验证时，我一般会同时起两个抓包：一个在客户端看RTP流的延迟和丢包率，一个在服务器侧看TCP重传率。再配合设备上的计数，三个数据互相印证，才能确定QoS真的生效了，而不只是“看起来配了”。

5. 常见问题与排障经验实录

5.1 典型坑位与排查思路

搞QoS这些年，我总结出几个高频翻车现场，每个都值得单独说道说道。

第一，QoS策略没生效，最典型的原因是信任边界配错了。比如你看着各队列都配了，但入口交换机不信任DSCP标记，所有包进队列时都是0（BE），调度器当然不区分优先级。遇到这种问题，别急着改策略，先show mls qos ips dscp看看实际流量带的是什么标记。真实标记和预期不一致，就去追信任配置。

第二，LLQ优先级设置过大，导致其他类饿死。语音的priority给了50Mbps，但语音实际只用5Mbps，其余的45Mbps直接空闲浪费。同时视频和ERP的保证带宽又被挤占，整体体验反而变糟。正确做法是给priority一个略高于实际峰值速率的保守值，而不是按链路带宽的50%拍脑袋。

第三，整形和监管的位置搞反。你在一台核心设备的出接口做了shaping，但真正瓶颈在运营商侧边缘设备，这时候shaping只让数据在本地排队，不仅没加快端到端速度，反而因为排队增加了延迟。正确做法是：在靠近瓶颈的“上游设备”做整形，让拥塞点之前就平滑流量。

第四，令牌桶参数不匹配。CIR设了10Mbps，但Bc还在默认的8000字节，算下来Tr只有6.4毫秒，突发稍微大一点就被削波。配置整形时必须根据CIR和预期突发需求计算Bc值，不能只填速率。

5.2 实战排障清单速查表

我整理一张实战排障速查表，遇到问题先按表排查，基本能覆盖80%的坑：

5.3 从运维角度说两句体己话

最后聊点不是书上的经验。QoS的部署效果，很大程度上取决于你对业务的了解程度，而不是对命令的熟练度。很多工程师第一次做QoS时，拿着厂商的配置模板套上去，发现没效果，就怀疑设备是不是有问题。其实大概率是业务流量特征没摸清楚：语音用的DSCP是不是EF？视频是不是AF41？ERP走的是哪几个端口？这些搞不清楚，QoS就是盲人摸象。

做QoS之前，老老实实抓包看一周流量特征，比什么配置手册都管用。我的习惯是：先抓流量、画数据流矩阵，再定分类和标记规范，最后才动手配设备。这个顺序倒过来的人，基本都返工过。

另外，QoS不是一次性的项目，而是一个持续调优的过程。业务上线新应用，流量模型变了，你之前配的队列比例可能又失衡了。保持定期review配置的习惯，比追求一份“永久完美”的配置实在得多。配置这东西，只有最合适的，没有最优的。每个网络都有自己的脾气，参数得结合现场慢慢磨，磨出来的配置才真正可靠。