企业官网建设流程全解析

简介：这是一份关于QoS区分服务（DiffServ）实现原理的专业技术资料，适合网络工程师、运维人员、高校网络方向学生以及对路由器服务质量机制感兴趣的读者。文档聚焦于区分服务在路由器中的落地：先是梳理了DS域的由来——用6比特DSCP取代传统TOS域，形成64种服务类别；接着说明边缘路由器负责分类、标记，核心路由器依据DSCP映射到对应PHB逐跳转发，从而避免为每个流保存状态，提升扩展性。针对需要确定性保证的绝对区分服务，资料重点讲解了EF加速转发和AF保证转发的实现，包括入口速率监控、丢弃策略、队列调度，并提及带宽代理（BB）与服务级别协议（SLA）在资源分配中的作用。资源包仅含1个PDF文件，容量192KB，内容紧凑不庞杂，可直接复制研读。目前已有103人学习下载，适合作为学习区分服务架构、配置路由器QoS策略或撰写相关方案时的参考资料。

1. 区分服务不是概念，是路由器里一组能落地的转发规则

这份PDF虽然发表于 1999 年，但里面讲的区分服务（DiffServ）机制，到今天依然是华为、思科、锐捷路由器上 QoS 配置的理论骨架。你打开商用路由器命令行，看到的dscp、exp、af13、ef这些关键字，都能在这篇论文里找到原始定义。它解决的核心问题是：当视频会议、VoIP、普通网页流量混在一条链路上时，路由器凭什么让前者低时延、后者尽力而为——答案就藏在 IP 头里的 DS 域和路由器为它实现的每一跳行为（PHB）里。这篇笔记会把论文里的 EF、AF、相对区分服务三种模型拆开，对应到具体队列、丢弃门限和调度参数，让你看完能直接照着重现一次。

2. 从 TOS 域到 DSCP：六比特怎么撑起 64 种服务等级

2.1 IP 头里的一个字节，决定了分组在每台路由器里的待遇

区分服务最关键的改动，是把 IP 分组头里原本的 TOS（Type of Service）域重新定义成 DS 域。老 TOS 协议里只有 3 个优先级比特，能表达 8 个优先级状态，但实际网络上几乎没人用它。IETF 在 RFC 2474 里把可用的比特数扩展到 6 个，组成 DSCP（Differentiated Services Code Point），也就是区分服务码点。这 6 个比特能组合出 64 种取值，理论上对应 64 种转发行为，每种取值都映射到路由器内部某一种具体的处理方式，也就是 PHB（Per-Hop Behavior）。

这里要特别注意一个容易混淆的点：DS 域仍然占用 IP 头里那一个字节，只是低 6 位用作 DSCP，高 2 位保留（CU 位）。用抓包工具看的时候，Wireshark 显示的是整个字节的十进制值，但 DSCP 真正生效的是左移两位之后的那 6 个比特。这就是为什么配置时经常会看到 DSCP 值 46 对应 EF 行为——46 的二进制是 101110，左移两位后是 10111000，即十进制的 184。

路由器的处理流程在论文里讲得很清楚：核心路由器不再为每一个流保存状态信息，它只做一件事——读取分组头的 DS 域值，查表找到对应的 PHB，然后执行该 PHB 定义的转发、排队或丢弃动作。边缘路由器则负责更重的工作：分类、标记、监控和整形。这种边缘重、核心轻的设计，是区分服务可扩展性的根本来源。骨干网上可能同时存在几万条流，但 DSCP 取值只有 64 种，核心路由器不需要记住任何一条流的身份。

2.2 边缘与核心的分工：分类标记在哪做，PHB 执行在哪做

用三步建立一套最小的区分服务转发环境：

1. 在边缘路由器入接口上配置分类规则，匹配源地址、目的地址或端口号。
2. 对匹配的流量标记 DSCP 值，例如dscp ef或dscp af13。
3. 在核心路由器出接口上配置 service policy，根据 DSCP 值执行对应的队列调度和丢弃策略。

interface GigabitEthernet0/0/1 description Edge-Router-Inbound ip address 192.168.1.1 255.255.255.0 // 边缘入接口：先分类，再标记 class-map match-any VOIP-TRAFFIC match ip dscp ef ! policy-map MARK-VOIP class VOIP-TRAFFIC set dscp ef ! service-policy input MARK-VOIP

这段配置展示了边缘标记的核心逻辑。class-map用来定义流量分类条件，match ip dscp ef表示匹配 DSCP 值为 EF（46）的分组；policy-map里的set dscp ef是对匹配分组重新标记。关键在于：边缘设备发出的标记动作决定了流量进入区分服务域之后的待遇，如果入口不标记，核心路由器只能把所有分组当尽力而为处理。

核心路由器上的配置才是真正执行 PHB 的地方：

interface GigabitEthernet0/0/2 description Core-Router-Outbound ip address 10.0.0.1 255.255.255.0 // 核心出接口：按 DSCP 执行每一跳行为 policy-map QOS-OUTBOUND class EF-CLASS priority percent 30 class AF-CLASS bandwidth percent 40 random-detect dscp-based ! service-policy output QOS-OUTBOUND

这里的priority percent 30对应 EF 的加速转发行为——保证 30% 的带宽、低延迟；bandwidth percent 40配合random-detect dscp-based对应 AF 的保证转发行为——保证带宽，同时用加权随机早期检测做拥塞丢弃。配置里注释的位置要留意：接口下吊用策略是在出方向，这是 QoS 最常见的应用方向。

2.3 论文里没讲的 TOS 换算表，配置时绕不开

老工程师们配置 QoS 时经常要在这几个值之间换算：IP 优先级（precedence）、DSCP 十进制值、DSCP 二进制值。论文里只给了 DS 域的位图，没有给换算表，但实际配置时这个表是高频查询对象。

记住这个换算关系有个土办法：AF 类的 DSCP 值 = 类号 × 8 + 丢弃优先级 × 2。AF11 就是 1×8+1×2=10，AF32 就是 3×8+2×2=28。这个规律论文里没有直接写，但对照 RFC 2597 的编码表就能推导出来。配置 ACL 匹配 DSCP 时用的就是十进制值，所以记不住二进制没关系，会换算就行。

3. 绝对区分服务：EF 和 AF 在路由器里的落地方式

3.1 EF 加速转发：低时延的代价是入口必须限速

EF（Expedited Forwarding）是论文里强调的第一种绝对区分服务。它的目标是提供低时延、低抖动、低丢失率、确保带宽的服务，服务质量要接近租用专线。论文给出的实现条件有两个：在任何时刻，路由器转发 EF 数据的速率不低于承诺带宽；边缘路由器保证用户数据到达速率小于承诺带宽。翻译成队列配置就是：EF 流量进最高优先级队列，同时入口做 policing 限速，超过速率的分组直接丢弃。

这两条缺一不可，它们是因果关系。如果只给 EF 最高优先级而不限速，恶意或异常的 EF 流量会占据全部出接口带宽，其他流量全部饿死；如果只限速而不给高优先级，EF 流量依然要和其他流量一起排队，时延无法保证。华为路由器上可以用qos car做流量监管，思科上对应police命令。

interface GigabitEthernet0/0/1 // EF 流量入口限速，防止过量 EF 影响其他服务 qos car ef-car car cir 10240 // 承诺速率 10Mbps car conform-action pass car exceed-action drop

命令的含义是：对进入接口的 EF 流量做速率限制，承诺信息速率（CIR）设为 10Mbps，不超过该速率的分组正常通过，超过的丢弃。这种"入口卡死、出口优先"的组合，就是 EF 在论文里描述的两条保证措施的命令行翻版。参数设置上，CIR 的值要小于或等于该链路为 EF 预留的带宽，否则出接口的优先级队列可能堆积。

3.2 AF 保证转发：RIO 双门限丢弃的工程化

AF（Assured Forwarding）在论文里的实现方式是 RIO 算法——同时运行两个 RED（Random Early Detection）算法，一个针对遵守协定的分组，另一个针对超出速率的分组。每个队列有两个门限：最小门限和最大门限。队列长度小于最小门限时不丢弃；在最小和最大门限之间时，随机丢弃超出速率的分组；超过最大门限时，所有分组都被随机丢弃，但超出速率的分组被丢弃的概率更高。

这个机制在路由器上的配置对应random-detect dscp-based。现代路由器对 AF 的丢弃参数细化到了每个 DSCP 值，也就是说 AF11、AF12、AF13 可以分别设置不同的最小门限和最大门限。以思科设备为例：

policy-map AF-CLASS class AF-CLASS bandwidth percent 40 random-detect dscp-based // AF11 低丢弃优先级，门限最高 random-detect dscp 10 40 80 10 // AF12 中丢弃优先级，门限居中 random-detect dscp 12 28 60 10 // AF13 高丢弃优先级，门限最低 random-detect dscp 14 20 40 20

参数格式是random-detect dscp 值 最小门限 最大门限 标记概率分母。AF11 的最小门限 40、最大门限 80，表示队列深度没到 40 个分组时全部放行；40 到 80 之间开始随机丢弃，标记概率是 1/10；超过 80 后所有 AF11 分组都可能被丢弃。AF13 的最小门限只有 20，意味着它比 AF11 更早进入丢弃状态——这就是论文里说的"高优先级分组被丢弃概率小于低优先级分组"的具体参数实现。

RIO 值得注意的工程约束是：同一类别（Class）的分组必须放进同一个队列，否则会出现乱序。论文原文明确说"为了避免乱序传送，所有属于同一类别的分组不论优先级如何都被放进一个队列内处理"。这意味着 AF11、AF12、AF13 共享同一个带宽队列，区别只在丢弃门限，不在队列数量。很多人初次配置时会把 AF 三个丢弃优先级配成三个独立队列，结果同一类流量被分发到不同队列，产生严重的乱序，TCP 性能急剧下降。

3.3 绝对区分服务的隐藏问题：路径绑定是推广拦路虎

论文在结语部分点出了一个尖锐的问题：绝对区分服务能否提供端到端的服务质量保证，是存疑的。为了达到较好效果，需要把用户数据和路径进行绑定（route pinning），而路径绑定要求网络上所有节点都感知这条流的路径并保持一致性——这恰恰破坏了区分服务"核心节点无状态"的核心优势。这意味着你只能在边缘到边缘的单一自治系统内做绝对区分服务，跨域的端到端保证基本做不到。

4. 相对区分服务：三种调度算法的对比与选型逻辑

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

相对区分服务和绝对区分服务的差别在于：不承诺具体的带宽、时延数值，只承诺服务级别 i 的质量不低于服务级别 i-1。论文给出的第一种实现是严格优先级调度——高级别分组总是优先发送，只有没有高级别分组时才轮到低级别。

interface GigabitEthernet0/0/2 // PQ：四个队列，严格按优先级从高到低调度 qos pq // 这是最简化的示意，实际要用 MQC 分四个 class

严格优先级的好处是配置直观、高级别流量的时延极低；坏处也很明显——论文明确警告，如果高级别分组太多，低级别分组可能很长一段时间得不到服务，这就是"饿死"现象。工程上的经验法则是：严格优先级只适合 EF 这类有入口限速的流量，因为 EF 的速率已经被 policing 限制死了，不会无限挤占带宽。如果对没有限速的 AF 类流量也用严格优先级，拥塞时低级别的 TCP 会整体被饿到超时重传。

4.2 WFQ 加权公平队列：能按比例分配，但瞬时一致性不达标

WFQ（Weighted Fair Queuing）的做法是按权重把链路带宽分配给各个服务级别。论文里的公式是：级别 i 和级别 j 的服务量之比等于它们的权重之比。每个级别有个带宽参数 p，级别越高 p 值越大，这样高级别流量得到的服务量就多。运营商可以通过调整 p 来调节各级别的服务质量差距。

但论文对 WFQ 的批评很到位：它不能根据网络实际负荷动态调整。如果某个短时间段内高级别流量突发到达，占用大量带宽，而 WFQ 的权重是预先固定配置的，那么低级别流量在这段时间内可能会得到比高级别还差的待遇——这违反了相对区分服务的一致性要求。论文明确指出：考察一致性要着重在短时间间隔内，WFQ 在这种场景下是不达标的。

4.3 WRP 等待时间优先级：动态调整的野心与未竟之题

WRP（Wait-time Priority）算法是论文里最有价值的贡献之一。它的核心公式是 P(t) = w × c，即发送优先级等于分组在队列中的等待时间乘以该级别的服务质量区分参数 c。级别越高，c 越大，分组的发送优先级增长越快。这意味着一个低级别的分组如果排队时间足够长，它的优先级会逐渐上升，最终得到服务——动态防止饿死。

实现 WRP 需要的不是固定的优先级队列，而是能动态按优先级排序的调度器。论文指出：如果某级别的到达速率远超服务速率，该级别分组的等待时间会持续增长，优先级也随之提高，自动驱使调度器为该级别分配更多服务。这种反馈机制是 WRP 相比 WFQ 的本质优势。仿真结果表明，在网络负荷较重时，即使较短时间片内，WRP 为每个级别分配的带宽也近似与区分参数成正比，而 WFQ 在这个指标上差得多。

WRP 在论文里也留了尾巴：只考虑了排队时延，没考虑丢包率；对 TCP 流能提供什么样的性能还有待研究。实际上 WRP 在商用路由器上并没有大规模落地，原因是动态维护有序队列的开销远高于固定 WFQ，而且 WRED 的丢包行为与 WRP 的调度行为叠加后建模困难。

5. 区分服务配置避坑：五个翻车现场与排查路径

5.1 打标打在入方向还是出方向，分不清导致策略静默失效

现象：配置了 policy-map 并在接口上吊用了 service-policy，但抓包发现 DSCP 值还是 0，流量没有按预期被标记。

原因：set dscp动作所在的 policy-map 被应用在出方向，但分类匹配的是入方向的 DSCP 值。如果入口流量本身没被打标，出方向的策略里 match 永远匹配不到。另一个常见原因是在物理接口和子接口上同时吊用了策略，子接口的策略覆盖了物理接口的策略。

解决：标记类策略应该放在离源最近的入口接口上，且用service-policy input调用。核查时用display traffic policy applied-record查看策略应用记录，确认方向和接口匹配。

5.2 DSCP 十进制值记错，46 当成了 46 没问题，可 10 被写成 8

现象：配置了match ip dscp 10想匹配 AF11，但实际流量 DSCP 是二进制 001010（十进制 10），部分平台配置时写成了 8（二进制 001000），导致匹配不到。

原因：AF11 的 DSCP 编码有多个别名，RFC 2597 定义的 AF11 是 001010，但有些老文档写的是 001010 的十进制形式 10，有些平台同时支持别名af11。手动换算时把 8 和 10 搞混是高频错误。

解决：直接使用 DSCP 名称别名，例如match ip dscp af11，不要让设备重新计算十进制。如果必须用数字，用前面给的换算表验证：类号 ×8 + 丢弃优先级 ×2。

5.3 EF 流量给了最高优先级队列但没做入口限速

现象：VoIP 通话质量虽然好，但同一链路上的文件传输变得极慢，甚至网页打不开。更严重时路由器的 CPU 升高。

原因：EF 流量在出接口进入 PQ（严格优先级队列），所有其他流量只能在 EF 空闲时才能发送。如果 VoIP 网关配置错误或受到攻击，产生大量 EF 流量，会占据全部带宽。论文里明确写了 EF 必须配合入口限速。

解决：在边缘入接口对 EF 做 policing，把速率限制在承诺带宽以内。同时开启接口的 qos car 统计，观察exceed packets的计数。如果 exceed 计数持续增加，说明对方发来的 EF 流量超过了协定速率，需要进一步限制或拒绝。

5.4 AF 三类丢弃优先级配成三个队列，流量严重乱序

现象：开启 AF 策略后，TCP 文件传输吞吐量反而下降，抓包看到同一个 TCP 流的包序列号乱跳，对端大量重传。

原因：AF11、AF12、AF13 被配置成了三个独立队列。同一分类内的分组被哈希到不同的队列缓存，在出接口上被调度器交错发送，出厂顺序被打乱。论文原文强调同一类别的所有分组必须放一个队列。

解决：把 AF 三类合并到一个 class 里，只做随机丢弃门限区分，不做多个带宽队列。也就是配置random-detect dscp-based而不是分别建三个 class 并各自分配 bandwidth。

5.5 核心路由器不识别入向 DSCP 值，信任边界设错

现象：核心路由器明明配了匹配 DSCP 的策略，但计数始终为零，而边缘路由器上标记计数正常。

原因：多数企业路由器默认在入方向改写 DSCP 值（例如思科默认根据 IP 优先级映射，华为部分平台默认不信任 DSCP）。从边缘过来的 DSCP 标记被核心入口直接重写了，导致后续匹配失败。

解决：在核心路由器入接口显式配置信任 DSCP，华为用trust dscp，思科用mls qos trust dscp。这属于信任边界的设定——只在网络边缘信任分类结果，核心节点不重新标记。排查时用display qos policy interface看接口下的统计，确认分类的匹配次数在增长。

6. 用这套老理论验证新配置：从抓包到队列统计的三步闭环

配置完 QoS 后，验证往往比配置更费时间。把那篇 1999 年论文的理论框架当作验证蓝图，从三个层面做闭环确认。第一层是链路层验证：对比启用 QoS 前后的时延、抖动、丢包率。第二层是队列层验证：查看各队列的丢弃计数和带宽占用，确认 AF 的分级丢弃确实在工作。第三层是标记层验证：抓包看 DSCP 值是否正确传递了整个转发路径。

验证 DSCP 标记是否生效，最直接的方式是抓包，也就是热搜词里"分析 ip 数据转发报文 arp 协议"那一类操作的进阶版：

# 在边缘路由器的出接口抓包，过滤 VoIP 流量，查看 DS Field 值 tcpdump -i eth0 -vvv -n host 192.168.1.100 # 如果接口在 Linux 环境，用 tshark 按 DSCP 过滤 tshark -r capture.pcap -Y "ip.dsfield.dscp == 46" -T fields -e ip.src -e ip.dst

抓包验证的要点是：必须先确认边缘标记已生效，再检查核心转发。如果抓包看到 DSCP 是 46（EF），说明打标正确。如果源头 DSCP 是 46，到了核心路由器变成 0，问题就出在核心入接口的信任配置上。

队列统计层面的验证用设备自带命令，华为是display qos queue statistics interface GigabitEthernet0/0/2，思科是show policy-map interface。阅读这些统计时有个经验：不要只看当前值，要看增量。写一个脚本每 5 秒采集一次队列丢弃计数，对比突发流量前后的变化。

# 每 5 秒采集一次队列丢弃统计，观察拥塞时的丢弃行为 while true; do date >> qos_stats.log display qos queue statistics interface GigabitEthernet0/0/2 >> qos_stats.log sleep 5 done

以一个真实的 AF 验证场景收尾：我曾在一条 100Mbps 链路上给 AF 类流量配了 40% 带宽和 RIO 双门限，射入 50Mbps 的 AF13 流量和 10Mbps 的 AF11 流量，模拟拥塞。队列统计里 AF13 的丢弃计数明显上升，AF11 只有少量丢弃，同期 TCP 吞吐没有出现悬崖式下降——这基本说明 RIO 的分级丢弃在按预期工作，同一队列内的乱序问题也没有出现。从那以后，我每次做 QoS 配置验收都会强制走一遍"边缘打标抓包验证、核心队列统计、突发流量压测"这三步，任何一步不过都不签字上线。希望这篇拆解能帮你在自己的网络里少踩几个坑。

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