尧图网页设计 
简介这是一份面向网络工程师、路由器研发人员及网络技术学习者的技术文献。资源为单篇PDF格式论文大小仅199KB内容围绕区分服务Diffserv在高性能路由器中的实现展开重点给出了数据包分类机制、流量控制机制和路由机制的设计思路。方案基于IPv4 ToS字段或IPv6通信类字段设置DSCP值将报文映射至对应PHB转发行为并通过边界节点简单分类、内部节点聚合流处理的方式大幅减少状态记录、提升扩展性。文中还定义了尽力而为BE、奖赏EF与保证AF三类服务质量对比了Diffserv相比Intserv的优势。该实现已依托国家863项目“可扩展到T比特的高性能IPv4/v6路由器基础平台及实验系统”完成测试并取得较好效果对路由器QoS设计与Diffserv落地具有参考价值。目前已有104人学习浏览适合作为信息技术领域参考文献与专业指导。1. 区分服务在现代高性能路由器中为什么仍然值得重新捡起来如果你维护过一台上万台终端的园区网出口或者给数据中心核心交换机调过流量割接窗口大概见过这种场景视频会议的声音断断续续ERP 批量任务把出口带宽占满网管一边抓包一边挠头。传统 QoS 用「尽力而为 拥塞时一刀切」的思路根本没有办法区分「丢了会出大事的语音」和「丢一点也无所谓的下载任务」。区分服务DiffservDifferentiated Services就是为解决这类问题而生的在报文进入网络的边界上打上标记中间每一跳路由器只认这个标记做相应的调度和丢弃处理不需要维护每个流的状态。这篇标题里的「高性能路由器」才是真正的看点——Diffserv 并不难懂难的是在硬件转发的路由器上把它做到线速、做到不拖垮 CPU、做到策略可维护。适合谁来读正在给企业网或数据中心做 QoS 方案选型的人以及看了一堆 Diffserv 理论但不知道在真实设备上怎么落地的工程师。接下来我按从原理到硬件的路径把这个标题拆开讲透。2. Diffserv 的体系拆解从 DSCP 到 PHB分类和标记是怎么决定报文命运的2.1 为什么 Diffserv 比 Intserv 更适合在大规模网络上存活在讨论 Diffserv 的实现之前要先想清楚一个问题为什么不是 Intserv综合服务。Intserv 的思路是端到端为每一个业务流预留资源靠 RSVP 信令逐跳建立状态。这个思路在小规模网络里很优雅带宽充足的时候效果极好但一旦路由器上承载的流数量超过一定规模问题就出现了每一台设备都要保存每条流的状态转发面需要查表、刷新定时器、回收过期流表项。在大规模网络上流表规模、信令风暴、状态同步这三个问题会把控制面压垮。Diffserv 选择了相反的路只在网络边界做复杂的分类和标记核心设备只认标记做转发。这种「边界复杂、核心简单」的哲学正是高性能路由器能在线速转发的前提下承载 Diffserv 的关键。说白了Diffserv 是把 QoS 的处理从「每流」压缩成了「每类」而类别数量被限制在 64 种之内——因为 DSCP 字段只有 6 比特。在一个 100G 端口上每秒要处理上亿个报文如果每个报文还要查流表硬件成本会失控。2.2 DSCP 字段和 PHB6 个比特如何撑起一套 QoS 体系Diffserv 的关键在于改写了 IPv4 头部的 ToS 字节。传统的 ToS 字节有 8 比特其中 3 比特优先级IP Precedence4 比特各标志位1 比特保留。Diffserv 把整个字节重新定义为 Differentiated Services 字段其中高 6 位是 DSCP低 2 位当前保留ECN 实际占用其中两位。DSCP 的值决定了报文属于哪个转发类即 Per-Hop BehaviorPHB。常见的 PHB 有几组部署时基本绕不开。PHB 组DSCP 值十进制典型用途处理思路尽力而为 EFExpedited Forwarding46语音、实时流媒体低延迟、低抖动严格优先调度确保转发 AFAssured Forwarding10/12/14、18/20/22、26/28/30、34/36/38业务数据分级每个 AF 类分三个丢弃优先级拥塞时优先丢低优先级尽力而为 BEBest Effort0默认流量无保障队列有空闲就用EF 是由 RFC 3246 定义的占用 PHB 组的一部分就是 DSCP 46。AF 类由 RFC 2597 定义共 4 个类每类 3 个丢弃优先级。以 AF 类 1 为例DSCP 10 是低丢弃优先级12 是中丢弃优先级14 是高丢弃优先级。在网络拥塞时如果 AF1 队列开始丢包先丢 DSCP 14 的报文最后才丢 DSCP 10 的报文。整个 Diffserv 的调度器设计本质上就是「对 EF 网开一面对 AF 分级处置对 BE 绝不怜惜」。2.3 边界路由器与核心路由器标记在哪做调度在哪做职责不能搞混Diffserv 将网络设备划分为两类角色边界设备和核心设备。边界设备也叫入口设备或边缘路由器承担复杂工作深度报文检测、基于 ACL 或应用识别的分类、流量整形Shaper、DSCP 重标记。核心设备则承担简单工作识别 DSCP、映射到本地队列、执行调度和丢弃策略。这里有个常见误解有人以为核心路由器上也要做深度包检测才能区分业务。实际上不是这样的——DSCP 标记一旦在边界设置好核心设备完全不需要看四层端口号、不需要做 DPI只读 IP 头部的 DSCP 值就能做决策。这意味着核心路由器可以在硬件流水线里只增加一个很小的查找步骤就能实现 Diffserv 的转发决策。高性能路由器之所以能在线速例如 100G 端口下处理 Diffserv就是因为它把复杂的分类限定在了网络的边沿。边界角色和核心角色不一定是两台设备也可以是同一台设备上的不同接口。比如一台路由器上联运营商的接口可以配置成核心方向的服务策略下联接入交换机的接口则配置成边界方向的分类策略。我自己见过不少翻车案例就是因为整台设备所有接口都配了深度的分类策略导致 CPU 被协议报文处理拖垮转发性能直接掉一半。这个后面避坑章节专门讲。3. 高性能路由器上的硬件实现为什么软件队列在 100G 时代撑不住3.1 转发面和服务面的分工Diffserv 必须在「数据通路」里完成高性能路由器的内部架构通常分为控制面Control Plane和转发面Data Plane两大块。控制面由 CPU 运行路由协议负责维护路由表和策略配置转发面由专用芯片完成报文转发。Diffserv 的全部核心操作——DSCP 查找、队列映射、拥塞丢弃、调度——必须放在转发面完成。如果任何一个环节被踢到 CPU 处理报文就会经历「中断上报、CPU 处理、再下发」的过程时延和抖动就会完全失控。在硬件转发芯片里Diffserv 的实现路径大致是这样一条流水线报文进入端口后首先通过 ACL 或三元组源 IP、目的 IP、协议端口判断流量类型打上内部流分类标签然后根据分类结果映射到对应的队列这个队列对应一个出口调度器调度器根据配置的权重或优先级策略选择从哪个队列取报文发送在队列深度达到阈值时丢弃策略通常是 WRED 或尾丢弃开始生效。这条路径全部在芯片内部完成不经过 CPU才能保证硬件转发的线速。3.2 队列数量与队列深度的取舍高性能路由器的 Buffer 为什么是稀缺资源高性能路由器上的 QoS 有一个「不可能三角」带宽利用率、时延、缓存容量。缓存越多越能吸收突发流量但时延越高芯片面积和成本也越高。在硬件芯片里队列数量是有限的——比如常见的企业级中高端路由器每端口可能只有 8 个或 16 个硬件队列。而 Diffserv 定义了几十个 DSCP 值因此必须做映射压缩多个 DSCP 映射到同一个硬件队列。这就是基于类的队列调度CBQClass-Based Queuing与基于硬件的严格优先级调度SPStrict Priority之间的取舍。实际部署中常见做法是把 EF 单独占一个队列把 AF 四个类分别占一个队列BE 占一个队列剩余队列给网络控制报文如 BGP、OSPF、ICMP 等。这样算下来8 个队列恰好够用。如果队列太深比如配到几百毫秒的缓存会出现一个流把整个队列占满、其他流饿死的情况如果队列太浅宽带上跑视频时轻微突发就会丢包。这个参数没有统一答案需要结合链路带宽、业务模型来调整。我一般会先从「按带宽比例分配队列深度」起步再根据实测丢包率细调。3.3 调度算法的硬实现PQ、WRR、WFQ 在芯片里是什么样的执行逻辑调度算法是 Diffserv 实现的核心。硬件芯片上常见的调度算法有三种严格优先级PQ高优先级队列有包就先发低优先级队列可能被饿死。适合 EF 语音但必须给 BE 队列设一个最小带宽保障否则大流量场景下 BE 完全断流。加权轮询WRR每个队列按权重轮流发送不区分优先级。适合多个 AF 类之间共享带宽。加权公平队列WFQ按权重加按需调度兼顾优先级和带宽公平但硬件实现比前两者复杂芯片面积和功耗更高。实际产品中常做的是「PQ WRR 混合调度」EF 队列走严格优先级AF 和 BE 队列走加权轮询。这个架构在多数高性能路由器上都是标配。还有一个容易忽略的点调度并不是只在出口方向存在入口方向也需要做拥塞管理。因为从高速链路进入的流量可能超过出口链路的带宽这时候入口芯片就要决定是先缓存还是先丢弃。很多第一次做 QoS 的人只配了出方向策略入方向拥塞时照样丢包而且丢得毫无章法。3.4 显式拥塞通知配合 Diffserv路由器如何告诉发送端「轻点发」ECN显式拥塞通知和 Diffserv 共用头部的低 2 位。当队列深度超过某个阈值时支持 ECN 的路由器不会直接丢包而是在报文头部打上拥塞标记标记CECongestion Experienced。TCP 的接收端看到 CE 标记后会在 ACK 里反馈给发送端发送端主动降低发送速率。这样可以避免丢包重传对实时业务更友好。ECN 和 Diffserv 配合的典型场景是语音流不启用 ECN因为语音用 UDP收到 CE 标记也不会降速数据流启用 ECN。这里有一个部署时的注意点ECN 需要在端到端的路径上所有设备都支持才有效如果中间某台老交换机不理解 ECN 标记并把它清掉整条链路的 ECN 能力就失效了。所以部署前先确认全网设备型号对 ECN 的支持情况不要只看核心路由器支持就觉得没问题。4. 从零落地一套 Diffserv 策略分类、标记、队列映射、调度参数怎么在真实设备上配置4.1 绘制业务分类表配置 Diffserv 前必须做的一张表动手敲命令之前先把业务分类表画出来。这是我在所有 QoS 项目里的第一个步骤没有这张表直接进设备配参数最后一定是回工单返工。下面是常见的一个企业广域网出口分类表样例。业务类型特征五元组 / 应用DSCP队列丢弃优先级备注语音源端口 10000-20000EF46队列 7最低时延敏感绝不允许丢包视频会议应用识别SIP/RTPAF4134队列 5低可以少量丢包但不能卡ERP 交易HTTP JSON / 数据库协议AF2118队列 3低关键业务数据文件传输FTP / SMB 大流量AF1110队列 2中可延迟可重传默认上网其余所有BE0队列 1高尽力而为表格里的映射关系不是标准答案不同网络有不同优先级。但有个原则必须坚守EF 类流量总数不能超过链路带宽的 30%否则严格优先级队列会饿死其他所有流量。这是我踩过的坑一开始给语音配了 EF 队列结果某些时段视频流量也被识别成了语音EF 队列直接占满 60% 带宽ERP 系统超时告警一片。后来在边界路由器上加上端口范围限制EF 队列只认 UDP 特定端口段的流量问题才解决。4.2 边界路由器上的配置分类和标记的典型命令与参数说明下面以常见的网络设备命令行风格为例不同厂商命令有差异但思路完全一致。边界路由器上要做的第一件事是定义流分类把「长得像语音的」和「长得像文件传输的」区分开。# 创建一个 ACL匹配语音流量源端口 10000-20000UDP acl number 3001 rule 5 permit udp source-port range 10000 20000 rule 10 deny ip# 创建流分类绑定上面的 ACL traffic classifier voice if-match acl 3001第二步是定义流行为和标记动作也就是决定这些流量获得哪些 DSCP 值。# 创建一个流行为为重标记 DSCP traffic behavior mark-ef remark dscp ef # 创建另一个流行为标记 AF21 traffic behavior mark-af21 remark dscp af21第三步是把流分类和流行为串起来形成策略然后下发到接口。这里注意区分入方向和出方向入方向做分类和标记出方向做队列调度。# 创建 QoS 策略应用到接口入方向 qos policy boundary-in classifier voice behavior mark-ef classifier file-transfer behavior mark-af21 interface GigabitEthernet0/0/1 qos apply policy boundary-in inbound参数说明ACL 规则里的 source-port range 用于匹配端口范围优点是精准缺点是只能匹配到端口如果语音流量走的是动态端口就失效了。此时就需要使用应用识别NBAR 或类似功能来辅助分类。remark dscp ef 就是把报文的 DSCP 改为 46注意这个动作发生在转发过程中所以必须同时开启「报文重标记」功能部分设备的默认配置不允许直接修改 DSCP需要先允许 IP 头修改。4.3 核心路由器上的配置只用 DSCP 做调度不碰深度报文检查核心路由器或同一台设备的出方向的配置就简单得多它不需要关心流量是什么应用只认 DSCP。# 创建映射表DSCP 到本地队列 qos map-table dscp-to-queue dscp ef map-queue 7 dscp af41 map-queue 5 dscp af21 map-queue 3 dscp af11 map-queue 2 dscp default map-queue 1 # 创建队列调度模板 qos queue-profile core-queue queue 7 pq queue 5 wrr weight 30 queue 3 wrr weight 20 queue 2 wrr weight 10 queue 1 wrr weight 5 queue 0 pq # 应用到物理接口出方向 interface GigabitEthernet2/0/0 qos queue-profile core-queue qos map-table dscp-to-queue参数说明queue 7 启用 pq严格优先级意思是这个队列只要有包硬件调度器就优先发送它。queue 5 到 queue 1 用 wrr 加权重权重值代表调度器转发该队列报文的相对概率。权重配比要按业务带宽需求来定不是拍脑袋——先统计一周内各业务的实际平均带宽占比再换算成权重而不是凭感觉写 30、20。如果配错了表现就是某个队列带宽超额、另一个队列带宽不足而且 wrr 模式下的超额优先级又不会触发丢包机制导致拥塞时低权重队列被饿死却查不出原因。4.4 设置拥塞管理参数WRED 阈值和 ECN 门限怎么调队列一旦发生拥塞就要靠 WRED加权随机早期检测来决定丢哪些包。WRED 的核心参数有两个最小阈值、最大阈值、丢弃概率。以 AF 类为例标准做法是设置三条不同丢弃优先级的 WRED 曲线让 DSCP 10低丢弃优先级的报文有更高的阈值上限、更低的丢弃率DSCP 14高丢弃优先级的报文更容易被丢。# 配置 WFQ 队列的 WRED 参数以队列 3 为例 interface GigabitEthernet2/0/0 qos queue 3 wred qos queue 3 wred dscp af11 low-threshold 80 high-threshold 120 discard-percent 10 qos queue 3 wred dscp af12 low-threshold 60 high-threshold 100 discard-percent 20 qos queue 3 wred dscp af13 low-threshold 40 high-threshold 80 discard-percent 30参数说明low-threshold 和 high-threshold 的单位通常为报文数或内存百分比不同厂商定义不同配之前一定先查设备手册确认单位。discard-percent 是达到最大阈值时的丢弃概率并非达到阈值就 100% 丢包而是按概率丢弃。注意 WRED 只能用在 TCP 流量上有意义UDP 流量不会对丢包做出反馈所以语音、视频这类 UDP 流量不适合启用 WRED应该使用尾丢弃或其他更温和的策略。4.5 不要忘记控制面协议报文也要进 Diffserv 体系控制面报文包括 OSPF/BGP 协议报文、ICMP、SSH 管理流量等。如果语音流量占满了 EF 队列而 BGP 报文进的是 BE 队列那么 BGP 会话可能因为丢包而反复振荡。正确做法是给控制面报文预留一个独立的队列且优先级高于 EF。在多数设备上这可以通过「控制面 QoS」或「CPU 保护策略」来实现。# 在控制面上应用 QoS 策略示意 control-plane qos policy control-plane-in classifier bgp behavior queue-high参数说明queue-high 是把协议报文映射到高优先级队列但这里不是 EF而是更高等级的网络控制队列。实际设备有专门的优先级定义建议把 BGP、OSPF 这类路由协议的管理报文放在语音之上防止路由振荡引发全网故障。5. 常见配置误区和排错指引Diffserv 上线后遇到流量异常先查这几处5.1 现象配置了 Diffserv 后核心链路的带宽利用率反而下降了现象Diffserv 策略上线后网络总吞吐量下降从 900Mbps 掉到 600Mbps。原因队列调度配置了严格优先级而 EF 队列中混入大量非实时流量高优先级队列占用过多带宽或者队列深度配得太浅突发流量被 WRED 提前丢弃TCP 全局同步导致带宽利用率下降。解决先查 EF 队列的命中计数。如果发现 EF 队列里跑的是大文件传输回到边界设备检查分类规则——八成是 ACL 端口范围写宽了或者应用识别把某些 P2P 流量误判为语音。其次核对队列深度把队列缓存从「默认值」增大到至少 200ms 的链路带宽 x 时延积。具体命令层面用 show qos queue statistics 查看各队列的包计数和丢弃计数对比策略上线前后的数据。5.2 现象语音质量正常但视频会议出现轻微卡顿现象语音清晰视频马赛克但 Ping 网关延迟正常。原因视频会议流量被分配到了低优先级队列而且在拥塞时 WRED 对该队列的丢包率偏高。还有一个隐蔽因素——视频会议报文通常较大接近 MTU同等带宽下报文数少但 WRED 基于报文数计算阈值时大报文占用的缓存空间更大更容易触发丢弃。解决把视频会议升级到 AF41DSCP 34并单独分配一个队列。同时调整 WRED 的阈值单位——如果设备支持按字节计算缓存占用优先选择字节模式。如果视频会议还是卡查一下出接口的调度模式确认是否启用了低延迟队列给视频留了专门通道。5.3 现象策略在核心路由器上不生效DSCP 值没有传到末端现象边界路由器上已经打了 DSCP 标记但核心路由器上的队列映射没起作用。原因路径上有设备清除了 DSCP 字段。很多交换机的默认动作是「不信任」入方向报文的 DSCP 值把它重置为 0。这属于典型的信任边界断裂问题。解决检查整条链路上所有二层交换机确认是否启用了 Diffserv 信任模式trust dscp。如果无法确认在核心路由器入方向做一次「无条件重标记」直接把报文 DSCP 改为预设值避免依赖上游设备的信任配置。用 show qos map-table 查看当前接口的实际映射再用抓包确认报文进入核心前的 DSCP 值——这是最快定位信任边界断点的方法。5.4 现象流量整形后 TCP 传输变慢但 CPU 使用率不高现象在边界设备上做了 shaper 限速但 TCP 长连接传输只能跑到限速值的 70%。原因整形器Shaper的突发尺寸Burst Size配置过小TCP 的突发窗口超出令牌桶容量导致整型器频繁丢包或延迟触发 TCP 拥塞控制。解决增大整型器的突发尺寸通常为带宽 x 往返时延BDP的一半以上。例如链路 100Mbps、RTT 为 20msBDP 约为 250KB那么突发尺寸至少设为 125KB。同时检查整形器的调度模式有些设备整型器不支持借用borrow禁用了整形队列的空闲带宽利用能力导致吞吐下降。5.5 现象逐跳策略都正确但端到端时延仍然抖动剧烈现象所有节点都配了 Diffserv但语音的端到端时延忽高忽低抖动大。原因拥塞不一定发生在路由器转发面也可能是运营商接入链路的物理层问题或者路径上的无线跳数Wi-Fi 接入引起的重传。Diffserv 只解决路由器内的排队延迟无法解决物理层和无线链路的抖动。解决先用 ping 带负载测试逐跳延迟找到抖动最大的那一跳再检查该节点是否存在过度订阅如 10G 带宽接入但只有 1G 出口也就是端口缓冲区不足导致的微突发丢包。如果确认是过度订阅只能通过扩容或调整路由策略分流Diffserv 无能为力。这也是最重要的一条认知——Diffserv 不是万能药它只处理「队列调度」这一层问题物理层的问题必须靠物理层解决。6. 验证 Diffserv 是否真的按预期工作可信测量法、配置复盘清单和经验习惯配置完成后不能只看设备统计就说「生效了」要实测。先把策略应用的接口和队列映射关系打印出来逐个核对。# 查看接口下应用的 QoS 策略示意命令 show qos policy interface GigabitEthernet2/0/0 show qos queue statistics interface GigabitEthernet2/0/0第一行命令检查策略是否成功下发到接口第二行查看每个队列的入包数、出包数、丢弃数。如果某个队列的丢弃计数持续增长而该队列对应的是 BE 流量这是正常现象但如果 EF 队列出现丢弃计数就一定有问题——立即检查分类规则是否误匹配。然后做一次端到端的验证测量。找一个可以产生可控 UDP 流量的测试仪或者用 iperf3 打流分别模拟语音用 UDP 小包和固定码率与文件传输大包、高带宽的混合场景观察在实际拥塞下语音队列的时延和丢包率。可以用下面的命令在客户端发起带 DSCP 标记的测试流量# iperf3 模拟语音流量2Mbps 码率、DSCP EF、UDP iperf3 -c 192.0.2.1 -u -b 2M -l 200 --dscp 46 -t 60参数说明-b 2M 表示发送码率 2Mbps-l 200 表示报文大小 200 字节--dscp 46 设定 DSCP 标记。从测试结果看如果 EF 流的时延抖动在几毫秒内稳定而 BE 流的吞吐明显受限说明调度器按预期执行了。如果没有测试仪也可以用 tcpdump 分端口抓包分析 DSCP 值是否被正确改写——但不如测试仪直观。最后把配置模板作为一种「基础设施」沉淀下来每次新链路开通前复制一份、按实际带宽调整参数。我的习惯是每次做完 QoS 调优把「配置前网络基线数据」「配置后对比数据」「调整了哪些参数、为什么」记录在一个文档里。三个月后再看这些记录比任何配置备份都值钱。Diffserv 不难难的是每一次调整都有据可依、可回退。希望这篇笔记帮你在下一次 QoS 方案设计里少走几条弯路。本文还有配套的精品资源点击获取 Diffserv在高性能路由器中的硬件实现与实战配置指南
简介这是一份面向网络工程师、路由器研发人员及网络技术学习者的技术文献。资源为单篇PDF格式论文大小仅199KB内容围绕区分服务Diffserv在高性能路由器中的实现展开重点给出了数据包分类机制、流量控制机制和路由机制的设计思路。方案基于IPv4 ToS字段或IPv6通信类字段设置DSCP值将报文映射至对应PHB转发行为并通过边界节点简单分类、内部节点聚合流处理的方式大幅减少状态记录、提升扩展性。文中还定义了尽力而为BE、奖赏EF与保证AF三类服务质量对比了Diffserv相比Intserv的优势。该实现已依托国家863项目“可扩展到T比特的高性能IPv4/v6路由器基础平台及实验系统”完成测试并取得较好效果对路由器QoS设计与Diffserv落地具有参考价值。目前已有104人学习浏览适合作为信息技术领域参考文献与专业指导。1. 区分服务在现代高性能路由器中为什么仍然值得重新捡起来如果你维护过一台上万台终端的园区网出口或者给数据中心核心交换机调过流量割接窗口大概见过这种场景视频会议的声音断断续续ERP 批量任务把出口带宽占满网管一边抓包一边挠头。传统 QoS 用「尽力而为 拥塞时一刀切」的思路根本没有办法区分「丢了会出大事的语音」和「丢一点也无所谓的下载任务」。区分服务DiffservDifferentiated Services就是为解决这类问题而生的在报文进入网络的边界上打上标记中间每一跳路由器只认这个标记做相应的调度和丢弃处理不需要维护每个流的状态。这篇标题里的「高性能路由器」才是真正的看点——Diffserv 并不难懂难的是在硬件转发的路由器上把它做到线速、做到不拖垮 CPU、做到策略可维护。适合谁来读正在给企业网或数据中心做 QoS 方案选型的人以及看了一堆 Diffserv 理论但不知道在真实设备上怎么落地的工程师。接下来我按从原理到硬件的路径把这个标题拆开讲透。2. Diffserv 的体系拆解从 DSCP 到 PHB分类和标记是怎么决定报文命运的2.1 为什么 Diffserv 比 Intserv 更适合在大规模网络上存活在讨论 Diffserv 的实现之前要先想清楚一个问题为什么不是 Intserv综合服务。Intserv 的思路是端到端为每一个业务流预留资源靠 RSVP 信令逐跳建立状态。这个思路在小规模网络里很优雅带宽充足的时候效果极好但一旦路由器上承载的流数量超过一定规模问题就出现了每一台设备都要保存每条流的状态转发面需要查表、刷新定时器、回收过期流表项。在大规模网络上流表规模、信令风暴、状态同步这三个问题会把控制面压垮。Diffserv 选择了相反的路只在网络边界做复杂的分类和标记核心设备只认标记做转发。这种「边界复杂、核心简单」的哲学正是高性能路由器能在线速转发的前提下承载 Diffserv 的关键。说白了Diffserv 是把 QoS 的处理从「每流」压缩成了「每类」而类别数量被限制在 64 种之内——因为 DSCP 字段只有 6 比特。在一个 100G 端口上每秒要处理上亿个报文如果每个报文还要查流表硬件成本会失控。2.2 DSCP 字段和 PHB6 个比特如何撑起一套 QoS 体系Diffserv 的关键在于改写了 IPv4 头部的 ToS 字节。传统的 ToS 字节有 8 比特其中 3 比特优先级IP Precedence4 比特各标志位1 比特保留。Diffserv 把整个字节重新定义为 Differentiated Services 字段其中高 6 位是 DSCP低 2 位当前保留ECN 实际占用其中两位。DSCP 的值决定了报文属于哪个转发类即 Per-Hop BehaviorPHB。常见的 PHB 有几组部署时基本绕不开。PHB 组DSCP 值十进制典型用途处理思路尽力而为 EFExpedited Forwarding46语音、实时流媒体低延迟、低抖动严格优先调度确保转发 AFAssured Forwarding10/12/14、18/20/22、26/28/30、34/36/38业务数据分级每个 AF 类分三个丢弃优先级拥塞时优先丢低优先级尽力而为 BEBest Effort0默认流量无保障队列有空闲就用EF 是由 RFC 3246 定义的占用 PHB 组的一部分就是 DSCP 46。AF 类由 RFC 2597 定义共 4 个类每类 3 个丢弃优先级。以 AF 类 1 为例DSCP 10 是低丢弃优先级12 是中丢弃优先级14 是高丢弃优先级。在网络拥塞时如果 AF1 队列开始丢包先丢 DSCP 14 的报文最后才丢 DSCP 10 的报文。整个 Diffserv 的调度器设计本质上就是「对 EF 网开一面对 AF 分级处置对 BE 绝不怜惜」。2.3 边界路由器与核心路由器标记在哪做调度在哪做职责不能搞混Diffserv 将网络设备划分为两类角色边界设备和核心设备。边界设备也叫入口设备或边缘路由器承担复杂工作深度报文检测、基于 ACL 或应用识别的分类、流量整形Shaper、DSCP 重标记。核心设备则承担简单工作识别 DSCP、映射到本地队列、执行调度和丢弃策略。这里有个常见误解有人以为核心路由器上也要做深度包检测才能区分业务。实际上不是这样的——DSCP 标记一旦在边界设置好核心设备完全不需要看四层端口号、不需要做 DPI只读 IP 头部的 DSCP 值就能做决策。这意味着核心路由器可以在硬件流水线里只增加一个很小的查找步骤就能实现 Diffserv 的转发决策。高性能路由器之所以能在线速例如 100G 端口下处理 Diffserv就是因为它把复杂的分类限定在了网络的边沿。边界角色和核心角色不一定是两台设备也可以是同一台设备上的不同接口。比如一台路由器上联运营商的接口可以配置成核心方向的服务策略下联接入交换机的接口则配置成边界方向的分类策略。我自己见过不少翻车案例就是因为整台设备所有接口都配了深度的分类策略导致 CPU 被协议报文处理拖垮转发性能直接掉一半。这个后面避坑章节专门讲。3. 高性能路由器上的硬件实现为什么软件队列在 100G 时代撑不住3.1 转发面和服务面的分工Diffserv 必须在「数据通路」里完成高性能路由器的内部架构通常分为控制面Control Plane和转发面Data Plane两大块。控制面由 CPU 运行路由协议负责维护路由表和策略配置转发面由专用芯片完成报文转发。Diffserv 的全部核心操作——DSCP 查找、队列映射、拥塞丢弃、调度——必须放在转发面完成。如果任何一个环节被踢到 CPU 处理报文就会经历「中断上报、CPU 处理、再下发」的过程时延和抖动就会完全失控。在硬件转发芯片里Diffserv 的实现路径大致是这样一条流水线报文进入端口后首先通过 ACL 或三元组源 IP、目的 IP、协议端口判断流量类型打上内部流分类标签然后根据分类结果映射到对应的队列这个队列对应一个出口调度器调度器根据配置的权重或优先级策略选择从哪个队列取报文发送在队列深度达到阈值时丢弃策略通常是 WRED 或尾丢弃开始生效。这条路径全部在芯片内部完成不经过 CPU才能保证硬件转发的线速。3.2 队列数量与队列深度的取舍高性能路由器的 Buffer 为什么是稀缺资源高性能路由器上的 QoS 有一个「不可能三角」带宽利用率、时延、缓存容量。缓存越多越能吸收突发流量但时延越高芯片面积和成本也越高。在硬件芯片里队列数量是有限的——比如常见的企业级中高端路由器每端口可能只有 8 个或 16 个硬件队列。而 Diffserv 定义了几十个 DSCP 值因此必须做映射压缩多个 DSCP 映射到同一个硬件队列。这就是基于类的队列调度CBQClass-Based Queuing与基于硬件的严格优先级调度SPStrict Priority之间的取舍。实际部署中常见做法是把 EF 单独占一个队列把 AF 四个类分别占一个队列BE 占一个队列剩余队列给网络控制报文如 BGP、OSPF、ICMP 等。这样算下来8 个队列恰好够用。如果队列太深比如配到几百毫秒的缓存会出现一个流把整个队列占满、其他流饿死的情况如果队列太浅宽带上跑视频时轻微突发就会丢包。这个参数没有统一答案需要结合链路带宽、业务模型来调整。我一般会先从「按带宽比例分配队列深度」起步再根据实测丢包率细调。3.3 调度算法的硬实现PQ、WRR、WFQ 在芯片里是什么样的执行逻辑调度算法是 Diffserv 实现的核心。硬件芯片上常见的调度算法有三种严格优先级PQ高优先级队列有包就先发低优先级队列可能被饿死。适合 EF 语音但必须给 BE 队列设一个最小带宽保障否则大流量场景下 BE 完全断流。加权轮询WRR每个队列按权重轮流发送不区分优先级。适合多个 AF 类之间共享带宽。加权公平队列WFQ按权重加按需调度兼顾优先级和带宽公平但硬件实现比前两者复杂芯片面积和功耗更高。实际产品中常做的是「PQ WRR 混合调度」EF 队列走严格优先级AF 和 BE 队列走加权轮询。这个架构在多数高性能路由器上都是标配。还有一个容易忽略的点调度并不是只在出口方向存在入口方向也需要做拥塞管理。因为从高速链路进入的流量可能超过出口链路的带宽这时候入口芯片就要决定是先缓存还是先丢弃。很多第一次做 QoS 的人只配了出方向策略入方向拥塞时照样丢包而且丢得毫无章法。3.4 显式拥塞通知配合 Diffserv路由器如何告诉发送端「轻点发」ECN显式拥塞通知和 Diffserv 共用头部的低 2 位。当队列深度超过某个阈值时支持 ECN 的路由器不会直接丢包而是在报文头部打上拥塞标记标记CECongestion Experienced。TCP 的接收端看到 CE 标记后会在 ACK 里反馈给发送端发送端主动降低发送速率。这样可以避免丢包重传对实时业务更友好。ECN 和 Diffserv 配合的典型场景是语音流不启用 ECN因为语音用 UDP收到 CE 标记也不会降速数据流启用 ECN。这里有一个部署时的注意点ECN 需要在端到端的路径上所有设备都支持才有效如果中间某台老交换机不理解 ECN 标记并把它清掉整条链路的 ECN 能力就失效了。所以部署前先确认全网设备型号对 ECN 的支持情况不要只看核心路由器支持就觉得没问题。4. 从零落地一套 Diffserv 策略分类、标记、队列映射、调度参数怎么在真实设备上配置4.1 绘制业务分类表配置 Diffserv 前必须做的一张表动手敲命令之前先把业务分类表画出来。这是我在所有 QoS 项目里的第一个步骤没有这张表直接进设备配参数最后一定是回工单返工。下面是常见的一个企业广域网出口分类表样例。业务类型特征五元组 / 应用DSCP队列丢弃优先级备注语音源端口 10000-20000EF46队列 7最低时延敏感绝不允许丢包视频会议应用识别SIP/RTPAF4134队列 5低可以少量丢包但不能卡ERP 交易HTTP JSON / 数据库协议AF2118队列 3低关键业务数据文件传输FTP / SMB 大流量AF1110队列 2中可延迟可重传默认上网其余所有BE0队列 1高尽力而为表格里的映射关系不是标准答案不同网络有不同优先级。但有个原则必须坚守EF 类流量总数不能超过链路带宽的 30%否则严格优先级队列会饿死其他所有流量。这是我踩过的坑一开始给语音配了 EF 队列结果某些时段视频流量也被识别成了语音EF 队列直接占满 60% 带宽ERP 系统超时告警一片。后来在边界路由器上加上端口范围限制EF 队列只认 UDP 特定端口段的流量问题才解决。4.2 边界路由器上的配置分类和标记的典型命令与参数说明下面以常见的网络设备命令行风格为例不同厂商命令有差异但思路完全一致。边界路由器上要做的第一件事是定义流分类把「长得像语音的」和「长得像文件传输的」区分开。# 创建一个 ACL匹配语音流量源端口 10000-20000UDP acl number 3001 rule 5 permit udp source-port range 10000 20000 rule 10 deny ip# 创建流分类绑定上面的 ACL traffic classifier voice if-match acl 3001第二步是定义流行为和标记动作也就是决定这些流量获得哪些 DSCP 值。# 创建一个流行为为重标记 DSCP traffic behavior mark-ef remark dscp ef # 创建另一个流行为标记 AF21 traffic behavior mark-af21 remark dscp af21第三步是把流分类和流行为串起来形成策略然后下发到接口。这里注意区分入方向和出方向入方向做分类和标记出方向做队列调度。# 创建 QoS 策略应用到接口入方向 qos policy boundary-in classifier voice behavior mark-ef classifier file-transfer behavior mark-af21 interface GigabitEthernet0/0/1 qos apply policy boundary-in inbound参数说明ACL 规则里的 source-port range 用于匹配端口范围优点是精准缺点是只能匹配到端口如果语音流量走的是动态端口就失效了。此时就需要使用应用识别NBAR 或类似功能来辅助分类。remark dscp ef 就是把报文的 DSCP 改为 46注意这个动作发生在转发过程中所以必须同时开启「报文重标记」功能部分设备的默认配置不允许直接修改 DSCP需要先允许 IP 头修改。4.3 核心路由器上的配置只用 DSCP 做调度不碰深度报文检查核心路由器或同一台设备的出方向的配置就简单得多它不需要关心流量是什么应用只认 DSCP。# 创建映射表DSCP 到本地队列 qos map-table dscp-to-queue dscp ef map-queue 7 dscp af41 map-queue 5 dscp af21 map-queue 3 dscp af11 map-queue 2 dscp default map-queue 1 # 创建队列调度模板 qos queue-profile core-queue queue 7 pq queue 5 wrr weight 30 queue 3 wrr weight 20 queue 2 wrr weight 10 queue 1 wrr weight 5 queue 0 pq # 应用到物理接口出方向 interface GigabitEthernet2/0/0 qos queue-profile core-queue qos map-table dscp-to-queue参数说明queue 7 启用 pq严格优先级意思是这个队列只要有包硬件调度器就优先发送它。queue 5 到 queue 1 用 wrr 加权重权重值代表调度器转发该队列报文的相对概率。权重配比要按业务带宽需求来定不是拍脑袋——先统计一周内各业务的实际平均带宽占比再换算成权重而不是凭感觉写 30、20。如果配错了表现就是某个队列带宽超额、另一个队列带宽不足而且 wrr 模式下的超额优先级又不会触发丢包机制导致拥塞时低权重队列被饿死却查不出原因。4.4 设置拥塞管理参数WRED 阈值和 ECN 门限怎么调队列一旦发生拥塞就要靠 WRED加权随机早期检测来决定丢哪些包。WRED 的核心参数有两个最小阈值、最大阈值、丢弃概率。以 AF 类为例标准做法是设置三条不同丢弃优先级的 WRED 曲线让 DSCP 10低丢弃优先级的报文有更高的阈值上限、更低的丢弃率DSCP 14高丢弃优先级的报文更容易被丢。# 配置 WFQ 队列的 WRED 参数以队列 3 为例 interface GigabitEthernet2/0/0 qos queue 3 wred qos queue 3 wred dscp af11 low-threshold 80 high-threshold 120 discard-percent 10 qos queue 3 wred dscp af12 low-threshold 60 high-threshold 100 discard-percent 20 qos queue 3 wred dscp af13 low-threshold 40 high-threshold 80 discard-percent 30参数说明low-threshold 和 high-threshold 的单位通常为报文数或内存百分比不同厂商定义不同配之前一定先查设备手册确认单位。discard-percent 是达到最大阈值时的丢弃概率并非达到阈值就 100% 丢包而是按概率丢弃。注意 WRED 只能用在 TCP 流量上有意义UDP 流量不会对丢包做出反馈所以语音、视频这类 UDP 流量不适合启用 WRED应该使用尾丢弃或其他更温和的策略。4.5 不要忘记控制面协议报文也要进 Diffserv 体系控制面报文包括 OSPF/BGP 协议报文、ICMP、SSH 管理流量等。如果语音流量占满了 EF 队列而 BGP 报文进的是 BE 队列那么 BGP 会话可能因为丢包而反复振荡。正确做法是给控制面报文预留一个独立的队列且优先级高于 EF。在多数设备上这可以通过「控制面 QoS」或「CPU 保护策略」来实现。# 在控制面上应用 QoS 策略示意 control-plane qos policy control-plane-in classifier bgp behavior queue-high参数说明queue-high 是把协议报文映射到高优先级队列但这里不是 EF而是更高等级的网络控制队列。实际设备有专门的优先级定义建议把 BGP、OSPF 这类路由协议的管理报文放在语音之上防止路由振荡引发全网故障。5. 常见配置误区和排错指引Diffserv 上线后遇到流量异常先查这几处5.1 现象配置了 Diffserv 后核心链路的带宽利用率反而下降了现象Diffserv 策略上线后网络总吞吐量下降从 900Mbps 掉到 600Mbps。原因队列调度配置了严格优先级而 EF 队列中混入大量非实时流量高优先级队列占用过多带宽或者队列深度配得太浅突发流量被 WRED 提前丢弃TCP 全局同步导致带宽利用率下降。解决先查 EF 队列的命中计数。如果发现 EF 队列里跑的是大文件传输回到边界设备检查分类规则——八成是 ACL 端口范围写宽了或者应用识别把某些 P2P 流量误判为语音。其次核对队列深度把队列缓存从「默认值」增大到至少 200ms 的链路带宽 x 时延积。具体命令层面用 show qos queue statistics 查看各队列的包计数和丢弃计数对比策略上线前后的数据。5.2 现象语音质量正常但视频会议出现轻微卡顿现象语音清晰视频马赛克但 Ping 网关延迟正常。原因视频会议流量被分配到了低优先级队列而且在拥塞时 WRED 对该队列的丢包率偏高。还有一个隐蔽因素——视频会议报文通常较大接近 MTU同等带宽下报文数少但 WRED 基于报文数计算阈值时大报文占用的缓存空间更大更容易触发丢弃。解决把视频会议升级到 AF41DSCP 34并单独分配一个队列。同时调整 WRED 的阈值单位——如果设备支持按字节计算缓存占用优先选择字节模式。如果视频会议还是卡查一下出接口的调度模式确认是否启用了低延迟队列给视频留了专门通道。5.3 现象策略在核心路由器上不生效DSCP 值没有传到末端现象边界路由器上已经打了 DSCP 标记但核心路由器上的队列映射没起作用。原因路径上有设备清除了 DSCP 字段。很多交换机的默认动作是「不信任」入方向报文的 DSCP 值把它重置为 0。这属于典型的信任边界断裂问题。解决检查整条链路上所有二层交换机确认是否启用了 Diffserv 信任模式trust dscp。如果无法确认在核心路由器入方向做一次「无条件重标记」直接把报文 DSCP 改为预设值避免依赖上游设备的信任配置。用 show qos map-table 查看当前接口的实际映射再用抓包确认报文进入核心前的 DSCP 值——这是最快定位信任边界断点的方法。5.4 现象流量整形后 TCP 传输变慢但 CPU 使用率不高现象在边界设备上做了 shaper 限速但 TCP 长连接传输只能跑到限速值的 70%。原因整形器Shaper的突发尺寸Burst Size配置过小TCP 的突发窗口超出令牌桶容量导致整型器频繁丢包或延迟触发 TCP 拥塞控制。解决增大整型器的突发尺寸通常为带宽 x 往返时延BDP的一半以上。例如链路 100Mbps、RTT 为 20msBDP 约为 250KB那么突发尺寸至少设为 125KB。同时检查整形器的调度模式有些设备整型器不支持借用borrow禁用了整形队列的空闲带宽利用能力导致吞吐下降。5.5 现象逐跳策略都正确但端到端时延仍然抖动剧烈现象所有节点都配了 Diffserv但语音的端到端时延忽高忽低抖动大。原因拥塞不一定发生在路由器转发面也可能是运营商接入链路的物理层问题或者路径上的无线跳数Wi-Fi 接入引起的重传。Diffserv 只解决路由器内的排队延迟无法解决物理层和无线链路的抖动。解决先用 ping 带负载测试逐跳延迟找到抖动最大的那一跳再检查该节点是否存在过度订阅如 10G 带宽接入但只有 1G 出口也就是端口缓冲区不足导致的微突发丢包。如果确认是过度订阅只能通过扩容或调整路由策略分流Diffserv 无能为力。这也是最重要的一条认知——Diffserv 不是万能药它只处理「队列调度」这一层问题物理层的问题必须靠物理层解决。6. 验证 Diffserv 是否真的按预期工作可信测量法、配置复盘清单和经验习惯配置完成后不能只看设备统计就说「生效了」要实测。先把策略应用的接口和队列映射关系打印出来逐个核对。# 查看接口下应用的 QoS 策略示意命令 show qos policy interface GigabitEthernet2/0/0 show qos queue statistics interface GigabitEthernet2/0/0第一行命令检查策略是否成功下发到接口第二行查看每个队列的入包数、出包数、丢弃数。如果某个队列的丢弃计数持续增长而该队列对应的是 BE 流量这是正常现象但如果 EF 队列出现丢弃计数就一定有问题——立即检查分类规则是否误匹配。然后做一次端到端的验证测量。找一个可以产生可控 UDP 流量的测试仪或者用 iperf3 打流分别模拟语音用 UDP 小包和固定码率与文件传输大包、高带宽的混合场景观察在实际拥塞下语音队列的时延和丢包率。可以用下面的命令在客户端发起带 DSCP 标记的测试流量# iperf3 模拟语音流量2Mbps 码率、DSCP EF、UDP iperf3 -c 192.0.2.1 -u -b 2M -l 200 --dscp 46 -t 60参数说明-b 2M 表示发送码率 2Mbps-l 200 表示报文大小 200 字节--dscp 46 设定 DSCP 标记。从测试结果看如果 EF 流的时延抖动在几毫秒内稳定而 BE 流的吞吐明显受限说明调度器按预期执行了。如果没有测试仪也可以用 tcpdump 分端口抓包分析 DSCP 值是否被正确改写——但不如测试仪直观。最后把配置模板作为一种「基础设施」沉淀下来每次新链路开通前复制一份、按实际带宽调整参数。我的习惯是每次做完 QoS 调优把「配置前网络基线数据」「配置后对比数据」「调整了哪些参数、为什么」记录在一个文档里。三个月后再看这些记录比任何配置备份都值钱。Diffserv 不难难的是每一次调整都有据可依、可回退。希望这篇笔记帮你在下一次 QoS 方案设计里少走几条弯路。本文还有配套的精品资源点击获取