DiffServ实现原理详解：从DSCP标记到路由器调度算法

简介：这是一份关于区分服务（DiffServ）在路由器中实现的中文技术文献，面向网络工程师、信息技术研究人员及需要配置QoS策略的运维人员，旨在解决传统尽力而为网络难以按业务类型提供带宽、时延等服务质量保证的问题。资源仅含1个PDF文件，压缩包大小192KB，属于路由器与无线技术领域的专业参考文献。文档从DS域与DSCP出发，说明边缘路由器对分组分类标记、核心路由器依据PHB转发的机制，并给出绝对区分服务中EF与AF两类服务的队列调度实现方法，同时介绍带宽代理（BB）通过SLA协商资源分配的流程。阅读后可理解区分服务相比综合服务的可扩展性优势，掌握从边缘到核心的QoS部署思路。已有103人学习下载，适合具备一定网络基础、希望深入掌握路由器QoS实现的读者。

1. 区分服务与路由器实现：这份1999年的论文为什么到今天还能用

“核心路由器不能为每个流单独保存状态，否则骨干网会直接崩溃”这个结论，放到今天已经是QoS领域的常识，但在IETF刚提出DiffServ模型的1999年，它还是一个需要靠论文讲清楚的设计判断。这份《区分服务在路由器中的实现》来自《现代电信科技》1999年第12期，作者是中科大电子工程与信息科学系的梁军、洪佩琳、李津生，篇幅很短，却把IntServ为什么扛不住、DS域如何重新定义、EF/AF两类绝对区分服务、相对区分服务的三种调度算法以及RIO双RED门限全部讲完了。对准备考研复试、给毕设找QoS理论支撑、或者想弄明白路由器上QoS配置背后逻辑的工程师，这份材料能直接把概念和实现串成一条线。下面按原文章节拆开讲，并补上现代环境的验证与踩坑。

2. 从IntServ到DiffServ：为什么核心路由器不能为每个流保存状态

2.1 IntServ的致命伤：每流状态在骨干网上是天文数字

论文把综合服务（IntServ）和区分服务（DiffServ）放在对立面来讲。IntServ的思路很直观：用户在通信前用RSVP信令，在收发两端沿途的每一个转发节点上做资源预留，这样每个流从源头到目的地都有确定的带宽和时延。问题出在“每一个流”这三个字上。

骨干网上同时存在的流数量是百万级别的，路由器要为每个流保存对应的状态信息，而这些信息要复制到全网各个节点。论文引用了Clark的观点：想找到一个算法完成这种端到端的全局资源分配本身就非常困难，而且这种网络在发生故障时几乎提供不了任何保护。所以在论文的结论里，IntServ的可扩展性和稳定性都不好，而这两点恰恰是因特网继续发展最需要的东西。

把这段逻辑映射到今天的设备上更容易理解。按流状态转发的设备，规模受限于TCAM和内存容量，流表项数量直接决定整机能在多少连接下工作；按聚合类转发的设备，转发路径上只需要查几十种行为，无论背后跑多少个流。DiffServ的取舍，本质上是把QoS复杂度从每个节点收拢到网络入口。

2.2 DS域与DSCP：6个比特如何编码64种转发行为

DiffServ对IP头做的第一件事，是重新定义原来的服务类型（ToS）域。原来的ToS域用3个优先级比特，最多表达8个状态；IETF区分服务工作组把它扩展到6个比特，得到64种可用状态，这6个比特就是DSCP（Differentiated Services Code Point）。每一种DSCP取值对应一种转发处理，也就是每一跳行为（PHB）。

这个表是RFC 2597和RFC 2598给出的标准取值，也是现在绝大多数网络设备上默认的DSCP到PHB映射。注意AF类的规律：数字的十位代表类别编号，个位代表丢弃优先级；丢弃优先级越大，拥塞时被丢得越早。EF只有一个值，因为它在每个节点只对应一种“高优先级优先发送”的严格行为。

在Linux上验证DSCP标记时，我的习惯是先配一条最简单的iptables规则，给特定UDP流打上EF标记：

# 对本机发出的UDP 5004端口流量设置DSCP 46（EF） iptables -t mangle -A OUTPUT -p udp --dport 5004 -j DSCP --set-dscp 46

这里放在OUTPUT链，是因为我们模拟的是本机产生的流量；如果要验证透传场景，规则要放在PREROUTING链，对转发流量生效。DSCP target只能用在mangle表，放进filter表不会生效，这是新手最容易踩的规则位置问题。

2.3 边缘与核心的分工：复杂度堆在边界，核心只做差分

论文把DiffServ的工作分成了三块：边缘设备、核心路由器、带宽代理（BB）。边缘设备负责对每个分组进行分类、标记DS域，并且做监控和整形；核心路由器根据DS域的值选择对应的转发处理；带宽代理配置管理规则，通过服务级别协定（SLA）与客户协商资源，向用户提供服务质量保证。

这张表能直接看出这套架构的核心思想：把贵的操作全部放在网络入口，让核心路由器只做查表和转发。论文原话是“核心路由器所需进行的操作相对简单”，所以它能以极高的速度转发分组。这也是为什么DiffServ最终能在实际网络里大面积部署，而IntServ一直停留在实验室和小规模专网的原因。

3. 绝对区分服务的落地实现：EF、AF与RIO算法的完整拆解

3.1 EF加速转发：想模拟租用线路，先解决排队条件

论文把EF描述成“和租用线路相近的服务质量”：低时延、低时延抖动、低丢失率、确保带宽。要实现这个目标，路由器里存放EF数据的队列长度必须很小。只有当数据到达速率大于离开速率时，分组才会排队；换句话说，只要在每个节点保证用户数据的到达速率小于该节点转发这种数据的速率，队列就不会持续堆积。

论文给出了两个保证条件。第一，在任何时刻，路由器转发EF数据的速率不低于要确保的带宽。第二，边缘路由器保证用户数据的到达速率小于确保带宽。第一点靠调度实现，第二点靠入口监控实现，两者缺一不可。

具体到路由器内部，常见做法是把EF分组的优先级设为最高，只有EF分组发送完毕后才发送其他分组。因为入口已经用SLA限速了，所以不用担心EF流量占用全部带宽导致其他分组饿死。这里必须强调“入口限速”这一步。如果只在核心设备上调高优先级，却没有在入口做监管，一个突发20Mbps的EF流就能把链路打满，挤占所有AF和BE流量，同时造成EF自身丢包。

在Linux上用tc模拟这种“确保带宽+高优先级”的组合，我常用的模板如下：

# 根队列HTB，默认类30 tc qdisc add dev eth0 root handle 1: htb default 30 # 总带宽100Mbps tc class add dev eth0 parent 1: classid 1:10 htb rate 100mbit # EF类：锁定10Mbps，不允许借用，优先级0最高 tc class add dev eth0 parent 1:10 classid 1:11 htb rate 10mbit ceil 10mbit prio 0 # AF类：保证5Mbps，允许借用，优先级2 tc class add dev eth0 parent 1:10 classid 1:12 htb rate 5mbit ceil 100mbit prio 2 # 按防火墙mark 46映射到EF类 tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 46 fw classid 1:11

rate是保证速率，ceil是上限。EF类ceil也设成10Mbps，表示它最多只能用10M，这就是“转发速率不低于确保带宽”与“到达速率不高于确保带宽”两个条件在实现上的结合。AF类ceil放开到100M，表示它可以借用剩余带宽，但前提是EF的10M先被满足。

配合前面那条iptables的DSCP标记，还需要把DSCP再转成MARK才能被fw分类器识别：

iptables -t mangle -A OUTPUT -p udp --dport 5004 -j DSCP --set-dscp 46 iptables -t mangle -A OUTPUT -p udp --dport 5004 -j MARK --set-mark 46

两条规则都挂在OUTPUT链上，顺序建议让MARK紧跟DSCP，避免后续filter看到未标记状态。实际部署时还要注意：DSCP标记和MARK标记都只能作用在mangle表，如果漏了第二条MARK规则，tc filter的fw分类器匹配不到任何包，表现为队列统计里EF类始终没有流量。

3.2 AF保证转发：RIO双RED算法与门限参数设计

AF的目标和EF完全不同。EF是严格保证带宽和时延，AF则是把流量分成若干类别，路由器为每个类别提供一定的转发资源（缓存、带宽），每个类别再分成几个丢弃级别，高优先级分组被丢弃的概率小于低优先级分组。

这里有一个很容易踩的细节：论文特别强调，所有属于同一类别的分组，不论优先级如何，都必须放进同一个队列处理，目的是避免乱序。优先级差异只体现在丢弃概率上，不体现在队列划分上。乱序对TCP的杀伤力远大于轻微丢包，这个取舍在真实网络里非常重要。

RIO算法正是为了实现“同类别、不同丢弃概率”设计的。RIO实际上是同时运行两个RED（Random Early Detection）算法：一个针对遵守协定的分组（in-profile），另一个针对超出约定速率的分组（out-profile）。每个队列维护两组门限，分别对应两条丢弃曲线。

上面这组是典型起始值，不是RFC强制的绝对值。核心逻辑是：out-profile曲线的min_th更小、max_p更大，所以在同一队列长度下，不守规矩的分组先被随机丢弃；守规矩的分组即使拥塞，被丢弃的概率也控制在很低水平。

RIO的行为可以概括成三段。队列长度小于min_th时，什么都不丢。队列长度在min_th和max_th之间时，随机丢弃out-profile分组，in-profile基本不动。队列长度超过max_th，说明已经发生拥塞，所有分组都被随机丢弃，但out-profile被丢得更狠。这样，只要用户自己的流量遵守SLA，拥塞时也能拿到可靠服务；多发出去的那部分，网络不承诺。

论文也点出了绝对区分服务的代价：端到端服务质量能不能保证，需要在“保证服务质量、提高网络利用率、数据聚类精度”之间做折中。为了让路径固定，可能需要做route pinning，而路径绑定本身会阻碍绝对区分服务的大规模推广。这是1999年就写清楚的边界，今天看依然成立。

3.3 入口监管器：违反SLA之后的流量去哪了

无论是EF还是AF，入口路由器的监控都是整套机制的起点。论文的说法是“违反服务级别协定的流量会被丢弃”，但在实际设备上，处理方式不止“丢弃”这一种，通常按流量超出的程度分三档处理。

第一档，速率在SLA允许范围内，直接放行并标记为in-profile。第二档，速率超过约定值但还在可容忍范围内，在AF场景下做降级处理，把超出部分标记为out-profile，拥塞时优先丢弃；在EF场景下，由于EF本身不允许超出，入口会直接丢弃超出的部分。第三档，速率严重超额（比如超过约定速率的两倍），无论EF还是AF都直接丢，避免个别用户拖垮整个出口。

这种分级处理在Linux上用tc的police就能轻松模拟：

# 在EF类上做10Mbps监管，突发2M，超速的直接丢 tc qdisc add dev eth0 parent 1:11 handle 20: police rate 10mbit burst 2m drop

police和rate/ceil的区别一定要分清：rate/ceil决定队列的长期服务速率，police则是对瞬间到达速率做判断。EF入口上police是必须的，否则任何一次突发都会直接放大到出口队列，违背“到达速率小于转发速率”的前提。

4. 相对区分服务的三种调度算法：严格优先级、WFQ与WRP怎么选

绝对区分服务给用户确定性承诺，但那份承诺要靠SLA协商、入口监管、route pinning一系列机制撑着。论文后半部分讨论另一种思路——相对区分服务。它不承诺端到端带宽或时延，只保证服务级别i得到的服务质量不低于级别i-1，最后用哪个级别由用户自己选。

这种模型下，路由器不需要端到端资源预留，不需要接纳控制，只需要保证“高级别数据得到更好的服务”。论文指出实现上要满足两个特性：一致性，即任何时刻高级别都要得到更好的服务；可控性，即ISP能调整各级别之间的服务差别，用来做差异化运营。下面三种调度算法就是在这个框架下做的取舍。

4.1 严格优先级：实现最简单，但低级别可能饿死

严格优先级调度的规则一句话就能说清：只要队列里有高级别分组，低级别人一律靠边。只有高级别分组全部发完，低级别才有机会被服务。所以在任何链路负荷下，高级别分组得到的服务质量一定比低级别好，一致性天然满足。

代价也很直接：运营商没有任何调整余地，而且一旦高级别流量持续存在，低级别分组可能在很长一段时间内完全得不到服务。真实网络里几乎没有人在公网接口上直接跑严格优先级，也是这个原因。它适合的场景是控制面和数据面分离，比如路由协议报文走最高优先级的控制队列，那部分流量极小，不需要担心饿死问题。

4.2 WFQ：按比例分带宽，短期一致性会崩

WFQ的思路是按比例给每个级别分配带宽。论文给出了服务量相等的条件：任意两个级别在相同时间区间内接受的服务量，除以各自权重，结果相等。实现时先估计每个级别的到达速率Ai，再为级别i选取服务速率，使级别越高、服务速率与到达速率的比值越大，这样高级别自然拿得多。

用现代设备上的术语说，这对应CBWFQ或者按权重分配的队列调度。它比严格优先级灵活，运营商可以调节权重来控制各级别之间的服务质量差距，可控性有了。

但WFQ有个先天问题，论文直接点破了：WFQ的比例是长期平均意义上的。如果在一段很短的时间内观察，各级别分组的时延和这段时间内每个级别的到达负荷强相关。某个瞬间高级别流量突发，低级别分组就会在短时间内得不到应有的服务比例——一致性在短时间尺度上不成立。如果你的业务对时延抖动敏感，WFQ在突发场景下会很难看。

4.3 WRP：用等待时间驱动调度，动态跟随负荷

WRP是论文引用的比例区分服务调度方案，思路比WFQ更聪明。它不再用固定权重分配带宽，而是给每个分组算一个发送优先级值，这个值和两个因素有关：该级别预设的服务质量区分参数c，以及这个分组已经在队列里等待的时间w(t)。用公式表达就是P(t) = c × w(t)，P值最大的分组先被发送。

几个级别的c从小到大排，高级别取更大的c。当一个高级别分组的等待时间增长时，它的P值增长得比低级别快得多，于是它会很快被提上来优先发送。反过来，如果某个级别的到达速率远大于服务速率，它的分组平均等待时间会持续增大，P值也持续增大，调度器就会给这个级别更多的服务机会。

这正是WFQ缺的那块：WRP能根据链路负荷动态调整为每个级别服务的速率，不需要外部测量动作。论文引用的仿真结果显示，在网络负荷较重时，即使观察窗口很短，WRP为每个级别分配的带宽也近似与c成正比，而WFQ在这种情况下表现差得多。

代价同样写在论文里：WRP只考虑了排队时延，没有把丢包率放进服务质量定义；它对TCP流的表现还需要进一步研究。如果网络里全是UDP或RTP流，时延区分能成立；一旦混入大量TCP，丢包和拥塞窗口的变化会让“时延比例”变得很难维持。

4.4 三种算法怎么选

如果是自己搭实验环境验证这三个算法，最简单的做法是用tc分别模拟：prio qdisc近似严格优先级，HTB的类权重近似WFQ，而WRP没有现成的qdisc，需要写成离散事件仿真来验证。另外还有一个容易被忽略的点：相对区分服务里用户关心的不是单个路由器内部的行为，而是整个区分服务域内，无论负荷和路径如何变化，高级别数据是否始终端到端更好。论文明确指出，上述方法是否能在多节点组成的域内满足这个要求，当时“还有待进一步研究”。也就是说，单节点调度算法做得再好，跨节点的差分质量也没人打保票。设计实验方案时至少要有两个节点串联验证，别只在一个路由器上测出结果就下结论。

5. 复现DiffServ的常见问题排查：五个容易翻车的现场

下面这些坑是我把论文思路搬到eNSP和Linux环境里复现时真实遇到过的，按“现象→原因→解决”写清楚。

5.1 抓包永远看不到DSCP：IP头里ToS字段一直是0

现象：用iptables打了DSCP标记，在接口上用tcpdump抓包，过滤出来的分组IP头第二个字节还是0，Wireshark里看不到任何DSCP值。

原因：最常见的是接口不信任分组的DSCP。在华为AR路由器上，接口默认不信任DSCP或IP优先级，即使报文带着标记，转发时也会被重写；Linux这边，如果iptables规则挂在POSTROUTING而流量走的是转发路径，或者规则的匹配条件（比如端口）没对上，标记动作根本没有执行。

解决：Linux上先看规则命中计数，iptables -t mangle -L -v，重点看每行规则前面的计数器是不是在增长。计数不动就检查匹配条件和链位置。华为AR上配置trust dscp让接口信任报文自带的DSCP，再做下一跳的队列映射。确认信任关系以后再去抓包，不要一上来就怀疑设备坏了。

5.2 AF同类别分组乱序，TCP性能反而下降

现象：配置了AF队列，同类别分组应该进同一个队列，但抓包发现同一个流的分组到达顺序错乱，TCP吞吐掉得很厉害。

原因：RIO的“同类别同队列”只是逻辑层面的要求，物理实现里有好几道坎。第一，等价多路径（ECMP）按五元组hash时，同一流的包可能因为hash字段变化被分到不同路径，时延差造成乱序。第二，某些设备的WRED把同一类分组散到多个内部队列处理。

解决：检查出接口是否启用了ECMP，尽量让同一流的hash键固定。仿真环境里用GNS3或eNSP时，如果有多条链路，先把AF业务固定绑定到一条链路上验证RIO本身的行为；等RIO行为验证通过后，再单独测试ECMP对乱序的影响。注意：RIO本身不解决多路径带来的乱序，它解决的只是单节点内队列分布问题。

5.3 EF只调了优先级，没做入口限速，一条流打穿链路

现象：EF流量确实被优先转发了，但一个持续UDP流把整条100Mbps链路打满，AF和BE全部饿死，EF自己也出现丢包，时延并没有变好。

原因：这正是论文强调的第一个条件被忽略——边缘路由器必须保证用户数据的到达速率小于确保带宽。核心设备把EF优先级拉满只能保证“EF的包永远先发”，但这个包如果不受控，高优先级反而成了放大故障的工具。

解决：在所有EF入口接口上做监管，速率设成SLA协商值的90%左右，burst设成几个TCP MSS的量级。Linux上配合tc police或者HTB的rate/ceil双限制都能达到这个效果。我一般会在测试机上把入口限制按10Mbps、burst 2Mbps写死，EF任何时刻都不能超过这个数字，然后再谈调度优先级。

5.4 WFQ在突发流量下时延抖动超过低级别预期

现象：跑WFQ时，长时间看带宽比例是符合权重的，但压入一个视频突发流后，低级别流的时延出现几百毫秒的尖峰，甚至比BE还差。

原因：WFQ的比例保证是长期平均的，短期一致性差。论文里明确指出了这一点，只是实验时容易被“比例正确”的表象骗过去。

解决：如果业务有实时性要求，不要单独依赖WFQ。把EF或LLQ拿出来给实时应用锁定带宽和优先级，剩余流量再交给WFQ按权重分配。这样实时业务的突发不会渗入WFQ权重池，低级别的时延尖峰自然被压住。说到底，WFQ适合的是“相对公平”，不适合“有硬时延需求的服务”。

5.5 RIO门限参数拍脑袋，入圈分组也被大批丢弃

现象：按默认RED参数配了RIO，拥塞测试时in-profile分组丢弃概率远超预期，SLA用户投诉服务质量不达标。

原因：min_th设得太低。队列长度在正常情况下就会超过min_th，于是随机丢弃一直在发生；或者in-profile和out-profile两条RED曲线的max_p没有拉开差距，出圈分组没有得到“先死”的惩罚，入圈分组被连带误伤。

解决：先摸清队列的真实深度。用设备上的queue统计观察平均队列长度，把in-profile的min_th放在平均队列深度的150%左右开始介入，max_p压到0.02量级；out-profile的min_th放在平均队列长度附近，max_p可以放到0.1。记住RIO的设计意图是“入圈分组容忍短暂突发，出圈分组承担主要代价”，两条曲线的门限必须拉开足够间距，这个间距就是为容忍突发预留的缓冲。

6. 验证技巧：用抓包与tc确认DSCP和队列行为

6.1 三步验证DSCP注入与转发链路

第一步，验证标记点确实打了值。用Wireshark加一列ip.dsfield.dscp，或者直接在tcpdump里过滤非零DSCP：

# 只抓带DSCP标记的IP包，0xfc掩码取ToS字段的高6位 tcpdump -i any 'ip[1] & 0xfc != 0'

过滤条件里ip[1]取的是IP头第二个字节，也就是ToS字段；0xfc对应二进制11111100，把低2位（ECN）屏蔽掉，剩下就是DSCP。看到非零值说明标记链路是通的；如果全零，先检查iptables规则命中和设备接口的trust配置。

第二步，验证中间节点是否按DSCP执行了预期行为。在核心设备上做端口镜像，或者用tcpdump在入接口和出接口各抓一把，对比同一个DSCP值进出方向都能看到。中间节点如果改写了DSCP，就要查重标记策略和信任模式。

第三步，验证队列行为。用tc的class统计看哪些类有流量，再用iperf3灌流确认EF类被锁在既定速率：

# 查看eth0根队列上各分类的收发统计 tc -s class show dev eth0

看每个class统计里的rate和dropped计数。EF类应该稳定在rate附近，超出部分被丢；AF类可以借用带宽，但上限不超过ceil；BE类只在低优先级剩余带宽里活动。这套统计比抓包更直接，能确认调度器到底按配置跑了没有。

6.2 用iperf3验证限速是否生效

先用UDP灌一个高带宽流，验证EF类的硬顶：

# 服务端 iperf3 -s -p 5004 # 客户端，打8Mbps的UDP流，--tos 184即0xB8，对应EF标记 iperf3 -c 127.0.0.1 -p 5004 -u -b 8m -t 30 --tos 184

--tos 184对应十进制的0xB8，也就是EF标记，和iptables设置DSCP 46效果等价。如果tc里EF类限速10Mbps，把iperf3的发送速率调到20Mbps，接收端应该只有10Mbps左右的实际带宽，而且丢包计数会明显上升。大量丢包就是监管器在工作的直接证据，也是整套DiffServ配置最终生效的标志。

从那以后我每次做QoS实验，都强制先走一遍“DSCP注入→接口信任→队列统计”这条链，确认每个环节有数据支撑再调参数，而不是直接在设备上拍门限值。这份1999年的论文扫描版虽然队列门限和PHB定义后来被RFC更新过，但“边缘分类、核心区别转发、相对区分服务的一致性”这套骨架一直没变，值得完整读一遍原稿，尤其是RIO和WRP的推导段落。希望帮到你。

本文还有配套的精品资源，点击获取