搞网络的人大概都经历过这种局面：视频会议开着开着突然卡住，语音时断时续，核心链路明明还有余量，可关键业务就是抢不过后台批量任务。很多人第一反应是加带宽，带宽加完问题依旧，最后只能在日志和抓包里来回折腾。真正该看的，其实是报文里的 DSCP 标记到底有没有被正确打上、被中间设备正确识别。DSCP（Differentiated Services Code Point）是差分服务模型里定义的核心流量标识字段，职责是让每一类流量进入网络时就带上一张“身份证”——我是语音、我是视频、我是普通上网，后续所有队列调度、拥塞丢弃都围绕这张身份证展开。这篇文章会把 DSCP 标记的原理、取值、配置、排错一次讲透，适合刚开始接触 QoS 的网工，也适合已经配了 QoS 但总感觉没奏效的运维同学。
为什么把 DSCP 这件事单拎出来写？因为我见过太多配置失败的案例，问题并不出在队列调度，而是出在最前面的“标识”环节。流量没有被正确分类，后面配得再漂亮也是白搭。
1. 先把标记这件事想清楚：DSCP 在 QoS 链路里的位置
1.1 为什么 QoS 要从报文里的几个 bit 说起
任何一台网络设备，要决定“这个包优先转发还是靠后转发”，都必须先回答一个问题：我凭什么知道这个包重要？这个问题的答案，就写在报文头部的某个字段里。IPv4 报文头里曾经有一个 8 bit 的 TOS（Type of Service）字节，早期只用了前 3 bit 做 IP 优先级，也就是 0 到 7 一共 8 个等级。后来标准组织觉得这 3 bit 太粗糙，又把整个字节重定义为 DS 字段（Differentiated Services Field），其中高 6 位就是 DSCP，低 2 位另作他用。所以现在的 DSCP 一共有 64 种取值，表达力远远超过早期的 8 级。
打个比方，DSCP 就像快递包裹上的加急标签。包裹一旦贴上“加急”，转运中心、干线运输、末端网点都只看标签来决定处理顺序，不需要一个个打电话问发件人这是什么货。同样，流量只要在入口被打上 DSCP，中间所有设备都按照这个标签做转发决策，不需要维护复杂的每流状态。
这也解释了为什么 DSCP 要叫“标记”。它做的事就是把策略语义写在报文自己身上，让每一跳都能读取，而不是靠某个中心节点去记忆每一条流的状态。
1.2 DiffServ 和 IntServ：两种思路，DSCP 属于哪种
在 DSCP 出现之前，还有一种更重的方案叫 IntServ（综合服务模型）。它的思路是逐流协商：每条业务流在发送之前，先用信令协议（比如 RSVP）沿途申请带宽，每台设备都要为这条流保留资源并记录状态。粒度很细，服务质量最有保障，但代价是设备要维护海量流状态。放在骨干网、数据中心这种成千上万条流同时跑的环境里，状态表会迅速爆炸，扩展性非常差。
DiffServ（差分服务模型）换了一种思路：不再为每条流单独预留资源，而是先约定少量几个业务类别，在入接口把海量流聚合成这几类，中间设备只针对类别做处理。设备要维护的状态从“百万条流”降到了“几个类”，代价是服务质量是相对的、统计意义上的，不能像 IntServ 那样对单条流做绝对保证。但正是这种取舍，让 DiffServ 成了大规模网络的实际标准。
对比起来更直观：
| 维度 | IntServ | DiffServ |
|---|---|---|
| 资源预留 | 逐流预留，RSVP 信令协商 | 按类聚合，不预留 |
| 设备状态 | 每条流一条状态，规模受限 | 状态少，可扩展 |
| 粒度 | 精细到单流 | 精细到业务类 |
| 典型场景 | 小型网络、企业边缘 | 骨干、园区、数据中心 |
DSCP 就是 DiffServ 模型在报文里的具体载体。没有这个字段，DiffServ 的“按类处理”就无从谈起。
1.3 DSCP 标记的完整工作链路
很多人有个误区，以为在设备上“配了 QoS”就是把 DSCP 配了。实际上 DSCP 标记只是整条链路的第一环，后面至少还跟着分类、调度、拥塞避免、限速这几步。
完整的处理流程一般是这样的：流量从终端进入网络，接入设备识别流量的特征（IP 五元组、端口、报文大小等），决定它属于哪个业务类，然后给报文写上对应的 DSCP 值，这一步叫分类和标记。报文继续往核心走，沿途每台设备读取 DSCP，把报文放进对应的硬件队列，并根据队列的调度参数决定转发顺序，这一步叫拥塞管理。如果某个队列持续拥塞，还要靠 WRED 这类机制选择性丢弃一些低优先级的包，避免所有队列都溢出，这一步叫拥塞避免。
我见过不少项目，只在核心设备上配了队列调度，却忽略了最前面的标记动作。结果是：所有流量进到核心时 DSCP 都是 0，一律当成普通流量处理，队列调度写得再精细也匹配不到任何业务类。所以先有正确的标记，才有后续一切 QoS 行为。
2. 认全 DSCP 家族：EF、AF、CS 与 BE 的取值逻辑
2.1 DS 字段的二进制结构：6 位 DSCP 加 2 位 ECN
DSCP 是 DS 字段的高 6 位，取值范围从 0 到 63。剩下低 2 位是显式拥塞通知（ECN）位，用于在队列快满时给对端“打招呼”，跟 DSCP 本身是两个维度的东西。
这里有个常见的坑：DSCP 是 6 位，但很多配置命令、抓包工具里显示的是整个 DS 字段的十进制数，比如 DSCP 46 对应二进制 101110，整个字节十六进制是 0x2E，十进制是 46。有些老工具显示的字段名还是 TOS 或“IPP”，取值可能只有 0-7，那是因为它只解析了前 3 bit 的旧 IP 优先级。所以网上看到的 DSCP 值、TOS 值、优先级值有时候是对不上的，必须先搞清楚工具读取的是哪个字段。
当初重定义 DS 字段时，旧设备的兼容性也是考虑过的。IP 优先级 0 到 7 分别落在 DSCP 的 CS0 到 CS7 上，取值正好是 0、8、16、24、32、40、48、56。也就是说，如果一个 DSCP 值是 8 的倍数，它大概率就是一个兼容旧 IP 优先级的值。这也是为什么很多网络管理流量直接用 CS 类而非 EF、AF。
2.2 PHB 语义：EF、AF、CS 与 BE 各自代表什么
DSCP 本身只是数值，真正的转发行为由 PHB（Per-Hop Behavior，每跳行为）定义。PHB 描述了设备遇到某个 DSCP 时应该采用的调度和丢弃策略。
EF（Expedited Forwarding，加速转发）是延迟和抖动最敏感的一类，取值为 46。它的设计目标是让流量获得“低延迟、低丢包、低抖动”的服务，典型业务是语音 RTP 流。设备通常把所有 EF 流量放进一个独立的低延迟队列（LLQ），该队列享有绝对优先转发权。EF 为什么偏偏选 46？因为 46 的二进制是 101110，前 3 位是 101，对应旧 IP 优先级 5，兼容老设备的同时又避开了 CS 类常见的 8 的倍数，减少误分类。
AF（Assured Forwarding，确保转发）一共 4 个等级，每个等级再分 3 个丢弃优先级，记为 AFxy，x 是 1 到 4 的等级，y 是 1 到 3 的丢弃优先级。比如 AF41 表示等级 4、丢弃优先级 1。等级决定流量占用的资源权重，等级越高，在拥塞时获得的带宽份额越大；丢弃优先级决定当某个等级出现拥塞时，先丢谁。AF 类典型业务是视频会议、数据流媒体这类“可以容忍一点延迟但不能容忍大量丢包”的流量。
CS（Class Selector，类别选择器）就是兼容旧 IP 优先级的 8 个值，CS0 到 CS7，通常用于网络控制（CS6）、信令（CS5）、管理（CS2）等场景。BE（Best Effort，尽力而为）是 DSCP 0，也就是默认的普通流量，不享受任何特殊保障。
2.3 常用 DSCP 取值与业务对照表
实际项目里不可能 64 个码点全用上，真正频繁出现的就是下面这一小部分：
| DSCP 值 | 名称 | 典型业务 | 理解要点 |
|---|---|---|---|
| 0 | BE | 普通上网、后台任务 | 默认值，没有保障 |
| 46 | EF | 语音 RTP | 最优先，限速保护 |
| 40 | CS5 | 语音信令 | 比 EF 低一点 |
| 32 | CS4 | 实时交互视频 | 低延迟但不绝对优先 |
| 34/36/38 | AF41/AF42/AF43 | 视频会议 | 等级 4，按丢弃优先级区分 |
| 26/28/30 | AF31/AF32/AF33 | 流媒体、批量视频 | 等级 3 |
| 18/20/22 | AF21/AF22/AF23 | 业务数据、存储复制 | 等级 2 |
| 10/12/14 | AF11/AF12/AF13 | 高吞吐数据 | 等级 1 |
| 16 | CS2 | 网络管理、OAM | 确保管理通道 |
| 48 | CS6 | 内部路由协议 | 网络自身通信 |
这里给一个实践建议：业务分类不要贪多，这是我在多个项目里换来的教训。有些团队把每个应用都分一类，结果就是 DSCP 表一长串，中间设备的队列数只有区区的 8 个、16 个，最后全都映射到同一队列，配置复杂度上去了，真实效果却没有提升。
3. 让标记真正落地：信任、分类、重写与调度的配置配合
3.1 先界定信任边界，再谈标记
DSCP 标记的第一个关键问题是：你信不信终端发来的标记？
PC 上的用户可以自己修改报文的 TOS 字段，完全可以把自己的流量标成 EF。如果你无条件信任终端，那么任何一个下载工具都可以伪装成语音流量，把低延迟队列塞满，真正打电话时反而没资源。所以网络里必须有一个“信任边界”，边界以内是可信设备，边界以外是终端。
典型设计是：接入交换机作为信任边界。面向 PC 的端口不信任 DSCP，收到报文后根据 ACL 规则重新分类、重写标记，普通没有策略匹配的流量一律清成 DSCP 0；面向 IP 话机的端口才信任标记，因为话机是受控设备，它的标签可信。
信任边界不是越靠近核心越好。如果所有标记都放在核心层做，那接入和汇聚链路上就分不清流量类型，拥塞可能已经发生在更靠前的链路上了。所以正确做法是让标记尽可能靠近源端，中间设备只做调度，不做重复分类。
3.2 一套完整的配置思路：定义类、定义策略、应用接口
QoS 配置在不同厂商设备上语法差异很大，但整体思路是通用的。下面我用一种常见的类配置风格来说明，具体命令以你使用的设备型号为准。
第一步，定义流量类别，把 DSCP 值映射到业务类：
class-map match-any VOICE match dscp ef class-map match-any VIDEO match dscp af41 af42 af43 class-map match-any SIGNAL match dscp cs5 class-map match-any BULK match dscp af11 af12 af13第二步，定义策略，给每个业务类分配调度行为。EF 进低延迟队列并限速，防止带宽抢占；AF 类分配带宽并启用基于 DSCP 的 WRED；BE 走默认队列：
policy-map WAN-OUT class VOICE priority 512 class VIDEO bandwidth 2000 random-detect dscp-based class SIGNAL bandwidth 64 class BULK bandwidth 200 class class-default fair-queue第三步，把策略应用到实际接口。注意 QoS 出方向生效，所以策略要加在出接口：
interface GigabitEthernet0/0/1 service-policy output WAN-OUT同时，在入接口设置信任或标记行为。如果这个口接的是 PC，通常要清理终端标记，按策略写入 DSCP；如果接的是 IP 话机或者可信设备，直接信任：
interface GigabitEthernet0/0/2 trust dscp整个配置跑通之后，流量进入设备时被打上标记，出接口按标记进入对应队列，这才是 QoS 的完整闭环。
3.3 DSCP 和 802.1p CoS 的映射关系
二层网络里还有另一个标识叫 802.1p CoS，它占用 VLAN Tag 里的 3 bit，值范围是 0 到 7。DSCP 是三层标识，CoS 是二层标识，两者需要联动。
典型场景就是 IP 话机。话机接在交换机端口上，语音 VLAN 已经打上了 802.1p 优先级 5，语音流量的 DSCP 也被标成 46。交换机在收到报文后，会同时参考 CoS 和 DSCP 来决定入队。如果一层的标记和二层的映射不一致，就会出现“链路里 QoS 生效、到终端却识别不了”的尴尬。
一般会在交换机上配一个 DSCP 到 CoS 的映射表，把 EF(46) 映射到 802.1p 5，AF41(34) 映射到 4，CS2(16) 映射到 2，其他默认映射到 0。这样无论报文走到哪一层，都能保持一致的优先级语义。做全网 QoS 规划时，这张 DSCP→CoS 映射表要和 DSCP 分类表并列存在，缺一不可。
4. 端到端保持 DSCP 最容易翻车的几个地方
4.1 隧道封装会把标记“藏起来”
跨站点网络很少是纯二层直连，中间多半有隧道。隧道封装的问题在于：设备看的是外层报文头，如果外层没有继承内层 DSCP，那么核心网络看到的全部是默认值，内层标记得再漂亮也没用。
比如 GRE 隧道，很多实现默认不会自动复制内层的 DSCP 到外层，需要显式配置“隧道 DSCP 继承”。VXLAN 场景也一样，VTEP 负责拆装 VXLAN 头，如果 VXLAN 封装后的外层 IP 头里 DSCP 是 0，那么核心网络根本无法区分业务优先级。加密隧道更特殊，内层被加密后完全不可读，只能在端点之间约定一个统一的外层标记规则，或者对所有加密流量一视同仁。
我处理过一个跨三层组网项目，汇聚到核心之间走了 GRE，接入层明明已经标好 DSCP，核心设备上却怎么都匹配不到流量。后来在隧道端点去抓外层包才发现，外层头 DSCP 全是 0，内层标得再好也没传到核心。开了外层 DSCP 继承之后，调度立刻生效。
所以做隧道组网时，每一条隧道都要单独确认：外层封装的 DSCP 是从哪来的，是继承内层、由端点重写，还是干脆用固定值。
4.2 跨专线、跨云时标记可能被“重新洗牌”
流量一旦穿过运营商专线或接入云环境，DSCP 的语义就不归自己管了。运营商可能只认它自己网络内部的优先级字段，到了入网点被重新映射；也可能为了防止用户抢占高优先级，把所有 DSCP 全部清零再按套餐策略重新标记。
这不是运营商故意为难，而是 DiffServ 模型本身允许逐域设置语义。运营商边界设备和用户侧设备之间的信任关系需要单独协商，通常在 PE（运营商边缘）和 CE（用户边缘）交接点两侧约定一张 DSCP 映射表。如果两边没有达成一致，再完善的内部 QoS 也只是在企业网内部自嗨。
云平台里也类似。虚拟机发出的 DSCP 到达虚拟交换机或宿主机网卡时，底层的默认策略可能直接重写。某些云厂商的 VPC 内网并不支持用户自定义 DSCP 优先级映射，标记在物理出口就被抹掉了。所以在云环境里做 QoS 规划之前，先确认平台方是否透传 DSCP，别等到业务卡顿才回头看。
4.3 无线网络的标记传到空中就变了样
无线又是另一套逻辑。无线接入点通过 CAPWAP 隧道把数据帧封装后发给控制器，封装之后的外层报文 DSCP 不一定等于无线帧里的优先级。同时 802.11 协议本身有一套 QoS 机制，靠 TID（Traffic Identifier）区分业务优先级，TID 又和 DSCP 存在映射关系。
如果无线控制器上没有配好 DSCP→TID 映射，语音流量优先级别不会正确传递到无线空口。即便映射正确，无线信道的重传机制也会抵消一部分优先级效果——信号弱的时候，优先级再高的报文一样会反复重传。这个场景我建议先解决覆盖和干扰，再考虑 QoS 标记，顺序不能反。
不管哪个场景，排查思路是一致的：逐跳抓包，看 DSCP 在哪一跳变值。你只需要把源端、接入、核心、隧道路由器四个点各抓一次，就能定位标记在哪一跳丢失或重写。
5. 排错与验证：确认 DSCP 真的按预期工作
5.1 从抓包开始：查看报文里的 DSCP
排错第一步永远是看报文的实际值，而不是看配置文件。抓包工具里有一个字段专门显示 DSCP，Wireshark 里可以按ip.dsfield.dscp过滤，比如想看所有 DSCP 46 的报文就过滤ip.dsfield.dscp == 46。
命令行抓包同样可以，命令和常见用法如下：
# 抓取指定接口的 ICMP 报文，并以十六进制显示 IP 头 tcpdump -i eth0 icmp -X # 直接按 DSCP 值过滤，这里以 46 为例 tcpdump -i eth0 'ip[1] & 0xfc == 184'第二个命令里的 184 怎么来的？DSCP 46 的二进制是 101110，左移 2 位变成 10111000，也就是 184。ip[1]取的是 IP 头第二个字节，也就是 DS 字段所在字节，& 0xfc表示只看高 6 位。这种过滤方式在老旧命令行环境里非常实用。
抓包要注意抓包点选择。终端本机抓到的包只能证明本机发出了什么标记，经过交换机、路由器之后可能已经被重写。正确做法是同时在终端侧、接入交换机上行口、核心设备入口各抓一次，对比同一会话的 DSCP 值变化。
5.2 设备侧统计：分类匹配数、队列丢弃和拥塞指标
光看单个包还不够，还要看设备内部到底是什么状态。现代设备基本都能查看每个 class-map 的匹配计数，如果某个业务类匹配次数一直是 0，说明你定义的分类条件和实际入包对不上，流量根本没进到这个类。
队列层面的指标同样关键。低延迟队列有没有丢弃？普通队列的 tail drop 数值会不会一直在涨？WRED 的丢弃是集中在高丢弃优先级还是低丢弃优先级？这些计数直接反映了调度行为是否正确。语音是 UDP 流量，丢一个包就能感知；视频虽然能抗一点丢包，但抖动一旦上来立刻起马赛克。所以光看丢包率还不够，要同时关注抖动和时延的分布。
5.3 几个常见问题和对应的排查路径
| 现象 | 可能原因 | 确认方法 | 解决思路 |
|---|---|---|---|
| 视频卡顿但 DSCP=46 的流量占满队列 | 分类策略太宽，视频被标成 EF | 抓包看视频流 DSCP | 接入层重写视频 DSCP 为 AF41，EF 队列加限速 |
| 策略配置没问题但完全没有效果 | 入接口没有设置信任或重写 | 查看入方向配置，对比抓包 | 在入接口加信任/重标记 |
| 跨设备后 DSCP 全部变 0 | 隧道外层未继承内层，或运营商重写 | 隧道两端抓包对比 | 配置外层 DSCP 继承，或协商映射 |
| 匹配计数为 0 | 类定义里 DSCP 值写错 | 核对类配置和实际报文字节 | 修正 DSCP 值或调整过滤条件 |
这里补一个容易忽视的细节：IPv4 分片。分片报文在传输中，只有第一个分片带有完整的四层信息，后续分片不携带端口号。如果分类规则是匹配端口而不是 DSCP，分片报文可能漏分类。DSCP 字段本身在分片时通常被复制到每个分片，但如果设备对分片处理不当，还是可能出现“首片有标记、后续碎片全丢弃”的诡异情况。建议对可能分片的大报文，分类尽量落在 DSCP 上，不要只依赖端口。
6. 我在这套体系里坚持的几点做法
6.1 别让分类数量失控
全网 QoS 我坚持一个原则：业务类别不超过 5 到 6 个。语音一个 EF，视频会议一个 AF（通常 AF41），实时交互和信令一个 CS（CS5 或 CS4），业务数据一个 AF（AF21 或 AF31），管理流量一个 CS2，剩下的全部默认 BE。这样既能满足绝大多数业务诉求，又能在全网设备间保持一致的映射语义。分类太多，每台设备都要维护复杂的映射表，不同厂商默认行为还不一致，排查成本呈指数上升。
6.2 所有设备共用同一张 DSCP 映射表
跨厂商设备之间最容易出问题的就是 DSCP 到内部队列的映射不一致。同一台接入设备把 AF41 当作高优先级，到了核心设备却把它映射到普通队列，前面的标记等于白做。我每接一个项目，第一件事就是做一张统一的映射表，把所有设备需要支持的 DSCP 值、对应队列、WRED 参数、CoS 值全部写进去，然后逐台设备核对配置。这张表也是后续运维排错的第一参考。
上个月刚处理过一个相似案例，某站点视频会议卡顿，核心分析全部正常，最后发现是汇聚设备固件升级后，默认映射表被重置，AF41 落到了默认队列。如果一开始就有映射表并定期抽检，这个问题根本不会拖到业务受影响。
6.3 每月做一次 QoS 专项巡检
别等到业务投诉才检查 QoS。我习惯每个月做一次专项巡检：取核心出接口的队列统计，看各类丢弃是否正常；随机抽几条业务流抓包对比 DSCP 是否还符合预期；检查所有隧道设备外层 DSCP 继承配置是否被变更过；把全网设备上的 DSCP 分类和映射表导出来和基准文件做 diff。
巡检脚本没什么高深的，就是把上面几条命令封装成定时任务，重点比对“DSCP 变化点”和“队列丢弃异常”，一旦出现偏离立刻告警。这套方法帮我解决过不少隐性问题，印象最深的一次：某台接入设备的中继口被人误改了 trust 模式，语音流量持续被重写为 0，当时如果不是队列统计里语音队列长时间无流量，根本发现不了。
最后再分享一个我的个人习惯：把全网 DSCP 映射表和分类基准文件放进版本管理，任何变更都走审批并留记录。上线新业务时优先查表，不在线上协商新的码点。DSCP 本身并不复杂，复杂的是让所有设备长期保持同一套规则，而守住这套规则，比任何单点配置都更重要。
