拓冰网站定制 
简介企业专线带宽有限业务高峰期视频会议卡顿、ERP登录转圈单纯加带宽并不能根除延迟和丢包。QoS网络技术正是解决这类问题的关键它在物理带宽之上建立排队策略通过DiffServ模型对流量分类、标记、调度和丢弃让语音、视频、关键数据获得差异化保障。DSCP优先级映射、令牌桶CIR/CBS参数、LLQ与WRED队列算法都是决定QoS效果的核心要素。掌握这些原理与配置方法不仅适用于10M专线场景也能为后续网络优化提供通用的排错思路。QoS白皮书从模型选型到参数表再到部署与验证输出了一套可落地的完整参考。1. QoS网络技术不是“加带宽”它到底在分配什么资源一条总部到分支的10M专线白天一到业务高峰就卡视频会议马赛克、文件传输排队、ERP登录转圈。很多人的第一反应是给链路加点带宽但预算批下来、速率提上去之后卡顿只是从“每天两小时”变成“每天半小时”。真正把剩余半小时磨掉的往往是QoS网络技术这套资源再分配手段。它不是把路修得更宽而是在路不够宽的时候决定谁先走、谁等一等、谁可以被暂时牺牲。“QoS网络技术白皮书”这个名字容易被当成一套高深理论拆开看其实就是三个问题流量怎么认出来如何打上优先级标记排队和丢弃的规则按什么参数写。这篇笔记按白皮书的思路把背后的模型、参数表和落地顺序讲清楚并附上五条常见翻车记录和一套验证方法。适合刚接手网络优化、需要在方案里给出具体数值的工程师。2. 为什么会在转发路径上排队拥塞、延迟与DiffServ模型2.1 排队是QoS存在的物理前提接口发送速率是固定的。10M专线每秒最多发10Mbit数据当某个瞬间从交换机、终端和服务器到达出接口的数据量超过这个速率多余的包就只能进入接口缓冲队列排队。排队本身不是故障但它会带来三种影响延迟delay、抖动jitter和丢包drop。延迟让交互类操作变得拖沓抖动让语音和视频播放出现断续丢包触发TCP重传最终拉低整体吞吐。QoS在任何时刻都无法减少总数据量它只把有限的出接口能力按业务优先级重新分配。带宽是物理资源QoS是在物理资源上做的排队策略。理解这一点很重要如果链路长期处于满负荷状态无论QoS参数调得多精细延迟和丢包都只能被“有选择地”控制而不是被消除。这也是为什么白皮书开篇先讲拥塞模型——不认清楚排队是怎么发生的后面所有配置都只是盲调。2.2 三种服务模型选型为什么DiffServ是白皮书的主线QoS的三种服务模型经常被混在一起提实际选型差别很大。尽力而为模型BE不区分业务先到先走所有流量共享瓶颈。它适用于对延迟不敏感的普通上网场景但在语音视频和关键业务混跑的链路上基本不可用。资源预留模型IntServ通过RSVP协议端到端预留带宽能提供严格的逐流保障。代价是网络设备需要为每一个流维护状态流量一多内存和CPU开销迅速膨胀在骨干或汇聚层很难扩展所以实际部署范围很窄。区分服务模型DiffServ是当前企业网最主流的选择。它在网络边缘对流量分类打标中间节点只看标记决定转发优先级不维护逐流状态扩展性好得多。白皮书里的队列调度、DSCP映射、拥塞避免全部是围绕DiffServ展开的入方向识别业务打上不同标记出方向根据标记把流量放进不同队列。三种模型的对比可以这样看INT SERV适合小规模内网硬保障DiffServ适合中大规模逐跳部署BE作为兜底模型处理剩余流量。多数园区网和分支互联方案选DiffServ作为主线不会错。2.3 QoS的四个动作分类、标记、调度、丢弃DiffServ模型落到设备上是四个顺序固定的动作。第一步是分类把流量从海量背景中认出来。常用依据是五元组源IP、目的IP、协议、源端口、目的端口、入接口、VLAN或已有的DSCP值。第二步是标记把分类结果写进IP头语音打EF、视频打AF41、关键数据打AF11这一步让后面的设备“一眼认出”业务。第三步是队列调度出接口按队列规则决定谁先出队语音视频走低延迟队列普通数据走加权队列。第四步是拥塞避免队列快满时按概率先丢低优先级流量保护高优先级业务。这四步顺序不能反。先打标再分类是无效的因为标记还没写进去只分类不打标中间设备无法逐跳识别只调度不管弃拥塞峰值一来队列照样溢出。白皮书后面的配置模板全部按“分类→标记→调度→丢弃”这个顺序写部署时也按这个顺序核对能少踩很多坑。3. 白皮书里的核心参数表令牌桶、DSCP映射与队列调度算法3.1 令牌桶参数CIR/CBS/EBS怎么定突发为什么不能粗暴设大令牌桶是最常见的QoS限速模型很多设备上的限速命令都基于它。模型可以理解成一个蓄水池令牌按CIR速率持续落入桶中包要发送必须先消耗等量的令牌。桶满了令牌溢出桶空了包就得等待或丢弃。三个关键参数分别是CIR承诺信息速率单位bps决定令牌注入速度也就是理论上允许的长期平均速率CBS承诺突发尺寸单位字节决定桶的深度也就是一次可以容忍的突发量EBS超额突发尺寸决定超出CBS后还能以何种代价继续放行多少数据。常见误区是把CBS设成“一条带宽那么大”比如10M链路配10MB的CBS后果是限速形同虚设突发窗口长达数秒同链路其他流量被挤爆。CBS的经验算法是让桶至少容纳一个RTT内的突发。公式是CIR×RTT÷8。例如CIR为4Mbps目标RTT为30ms算出来约15KB起步可以给16KB到32KB再根据实际抓包峰值往上调。调的时候看一个指标峰值速率的持续时间。如果应用突发就是几个TCP窗口大小CBS给到几十KB就够如果数据库同步或备份会产生持续数十毫秒的大突发CBS要相应放大。EBS一般保持默认或设为0很多模板把EBS也配得很大等于放行第二波超发流量起不到保护作用。3.2 DSCP标记标准语音视频数据各用什么值信任边界在哪DSCP沿用IP头ToS字段的前6位在DiffServ里承担业务“身份证”的角色。不同设备厂商默认映射可能略有差异但业界有一套通行的取值习惯白皮书里的映射表通常是这个版本流量类型DSCP名称十进制十六进制典型用途语音RTPEF460x2E语音媒体流优先队列语音信令CS3240x18SIP/SCCP信令容错但需低延迟视频会议AF41340x22视频媒体流带丢弃优先级关键数据AF11100x0AERP/交易类低丢包保障网络控制CS6480x30路由协议与网管尽力而为BE00x00普通上网流量注意视频不一定非用AF41部分方案会用CS540但AF类自带三个丢弃优先级可以在拥塞时先丢低优先级帧比CS5更精细。语音信令用CS3而不是EF是因为信令包小但重要把它放进EF队列会和语音RTP竞争带宽CS3配合低延迟队列更稳妥。标记之后紧接着要划定信任边界。接入交换机连接终端设备的端口不应直接信任终端发来的DSCP否则用户只要改了自己网卡上的QoS优先级就能让普通流量插队到语音队列。常见做法是连接终端的端口在入方向做重标记把非标准DSCP改成BE连接路由器或上行汇聚的端口才信任DSCP并执行队列策略。信任边界画在哪里直接决定后面所有策略是否可信。3.3 队列调度算法对比PQ、WRR、WFQ、LLQ的适用场景队列调度算法决定“当多个队列都有包时谁先出接口”。四种算法要分清。FIFO先入先出没有分类能力流量按到达顺序发送一旦拥塞语音视频和数据互相拖累只能在极低负载链路使用。PQ严格优先让高优先级队列清空后才处理低优先级延迟最有保障但如果不加限制低优先级流量会被饿死。WRR加权轮询按权重在各队列间循环服务避免饿死但队列内仍然是FIFO且权重按包数而非字节数计算时小包队列会占便宜。WFQ加权公平按会话数动态分配带宽对TCP流量公平但无法为语音视频提供硬性的低延迟保证。算法调度机制优点缺点适用场景FIFO先到先发实现简单无业务区分低负载链路PQ严格优先延迟最可控低优先级可能饿死需限流的实时业务WRR按权重轮询各队列有带宽队列内FIFO、权重粒度粗数据流量混跑WFQ按会话公平TCP友好延迟不稳定纯数据链路LLQPQCBWFQ实时与公平兼顾需精确配带宽上限语音视频混合链路LLQ实际上是“严格优先带宽上限”的组合方案是语音视频场景里最常见的做法。它对EF队列开一个严格优先通道保证低延迟同时给这个通道设置带宽上限通常是业务需求的1.2倍超出上限的实时流量降级到普通队列避免语音视频把整条链路占死。白皮书里的配置模板如果面向语音视频基本都会落到LLQ上不会只给一个PQ或WRR。3.4 WRED用概率丢弃为TCP拥塞控制服务拥塞避免机制里WRED加权随机早期丢弃是数据流量最常用的方案。它的思路是队列还没满时按不同优先级设定阈值和丢弃概率提前随机丢一部分包让TCP源端感知拥塞、主动降低发送速率避免队列溢出后发生“全局同步”式的丢包风暴。DSCP为AF11的数据包丢弃概率设置得比BE低保证关键任务先保住普通浏览先丢。WRED对TCP类流量效果显著因为TCP会响应丢包降速。但UDP实时流量不会响应拥塞窗口被WRED随机丢弃只会造成花屏和断音。因此语音视频队列里通常关闭WRED依靠LLQ严格优先队列保证延迟而数据队列要开启WRED。常见误用是在所有队列都开WRED然后把高优先级流的丢弃阈值设得和低优先级一样那等于没区分业务配置再复杂也白搭。4. 把白皮书落成配置一个10M专线的QoS部署步骤4.1 部署前先做三件事流量基线、带宽预算、信任边界拿到一份QoS方案先不要急着敲命令。第一件事是抓流量基线用netflow或sFlow在出口观察一到两周确认语音、视频、ERP、普通上网各占多少比例峰值出现在什么时段。第二件事是算带宽预算。以10M专线为例语音预留1Mbps视频会议预留4Mbps关键数据预留1.5Mbps剩下的3.5Mbps给普通业务。这样即使视频会议开到极限ERP也有保障普通流量不至于完全断流。业务类型DSCP预留带宽队列安排语音RTP信令EF/CS31MbpsLLQ严格优先视频会议AF414Mbps加权队列高权重ERP/交易数据AF111.5Mbps加权队列中权重普通上网BE3.5Mbps默认队列第三件事是画信任边界。终端接入端口标记为不可信上行汇聚端口标记为可信中间每一跳都要明确“这个端口是否接受来自对端的DSCP”。三步做完后配置只是把这些数值填进设备而不是边做边猜。4.2 入方向监管与出方向调度的方向性问题QoS的入方向和出方向承担不同职责很多人在这里翻车。入方向的监管Policing负责检查流量是否违约超出CIR的部分直接丢弃或重标记常用于限制用户侧流量。出方向的整形Shaping负责平滑发送速率超出的流量先缓存再按CIR发送常用于适配物理线路带宽。调度队列和拥塞避免则必须作用在出方向因为只有出口才存在真正的发送竞争。动作方向超出CIR处理适用场景监管Policing入方向直接丢包或重标记防止终端骗标、超速整形Shaping出方向缓存排队后再发适配物理链路速率常见错误是把限速命令配在出方向结果超出速率的数据被立即丢弃TCP进入快速重传吞吐反而下降或把队列调度配在入方向但很多设备入方向根本不支持队列调度配置直接不生效。正确顺序是入方向做分类、标记、监管出方向做整形、队列调度、拥塞避免。4.3 六步落地清单从匹配流量到队列参数在支持MQC框架的设备上可以用类图加策略图的方式组织配置逻辑。这是一个通用的六步流程按顺序执行第一步定义流量类。按五元组匹配业务语音信令匹配SIP端口5060语音RTP匹配UDP端口范围视频会议匹配特定IP段ERP匹配服务器地址。第二步在入方向打标。设置DSCP映射表EF给语音、AF41给视频、AF11给ERP、BE给其他。第三步在接入端口做重标记。连接终端的端口把入向流量统一打到BE防止用户私自改优先级。第四步配置入方向监管。对EF队列限速1Mbps对AF41限速4Mbps超出部分重标记为BE。第五步配置出方向队列。EF和CS3进LLQ严格优先队列上限给1.2MbpsAF41走加权队列权重设40%AF11权重设15%BE设35%。第六步开启拥塞避免。数据队列开WRED实时队列关闭WRED。每一步做完都用查看命令确认计数器在增长再做下一步。QoS是逐跳行为中间交换设备如果不认DSCP或直接改写掉了链路末端的配置再完美也没有用需要沿转发路径逐台确认。5. QoS配置常见问题排查五个能让你翻车的坑5.1 限速策略一直不生效方向与接口归属搞错了现象策略配置完流量速率纹丝不动或者小包被丢、大包照常通过。原因通常有两个一是方向配反限速配在出方向但设备出方向不支持监管二是策略挂在了一个不包含该流量的接口或子接口上。解决先在接口上确认策略是否生效绝大多数设备的查看命令能列出接口方向和匹配次数然后把监管确认放在入方向把队列确认放在出方向。子接口场景要注意物理接口策略和子接口策略同时存在时匹配顺序按设备逻辑而定先查子接口覆盖关系。5.2 突发流量被误杀令牌桶的CBS和EBS设得太小现象平时速率正常一到业务整点比如报表生成、数据库备份就出现成片丢包业务报错。原因CIR设得合理但CBS只给了默认值有的设备默认只有8KB一次几MB的突发被桶深卡死包在入方向就被丢弃。解决按CIR×RTT÷8估算CBS再放大到实测峰值具体到10M链路CBS从32KB到128KB逐级试EBS保持默认或0不要把EBS当额外突发通道。验证方式是边打流边看令牌桶漏桶计数器确认丢包集中在突发时段而非持续。5.3 语音视频仍然卡顿信任边界和中间设备重写了DSCP现象QoS配置明明做了语音视频还是卡show policy-map接口上分类匹配计数低得可怜。原因中间交换机在转发时把DSCP改写了或接入端口信任了终端发来的错误标记导致高优先级流量根本没被识别。解决沿转发路径逐台检查DSCP值使用带DSCP的ping或抓包工具确认每个节点收到的标记是否一致把信任边界收敛到接入层终端端口重标记汇聚层以上保持信任。另一个容易被忽略的点是MQC分类的顺序有些设备按“首个匹配生效”如果匹配普通上网的规则写在前语音RTP会先进错队列。5.4 大流量时段低优先级业务全部超时PQ或LLQ没有设置带宽上限现象开启严格优先队列后业务高峰期普通网页和邮件全部超时。原因PQ队列是绝对优先如果语音视频队列里涌入超过实际需求的流量普通队列在拥塞时几乎没有发包机会。解决给严格优先队列设置带宽上限LLQ模式下的标准做法是上限设为业务需求的1.2倍左右超出上限的流量降级到普通队列。配置后要做一次满负载测试同时打满视频和BE流量确认低优先级业务仍然有可用的带宽块。5.5 drop为零但体验依旧差只看丢包不看延迟和抖动现象队列计数表里丢包计数器是0但视频会议依旧卡顿、操作延迟高。原因链路拥塞达到排队临界点时包没有被丢弃但等待时间拉长表现为延迟上升和抖动加剧丢包未发生不代表QoS生效。解决同时看queue depth队列深度和延迟抖动数据队列深度持续攀升说明带宽预算有问题用双向并发流量测试单向延迟和抖动不要把ICMP的RTT当作业务体验的唯一指标。物理链路误码也会导致TCP拥塞窗口塌缩这时QoS无能为力需要检查光模块和线路质量。6. 落地验证技巧用ping、iperf3与show命令确认QoS真的生效6.1 上线前先拍三张快照分类命中、DSCP标记、队列深度QoS上线前后必须各留一套基线。第一张快照看分类命中查看设备上策略图的匹配计数EF、AF41、AF11三类流量都必须有持续增长的数字如果某个计数为0说明匹配条件没覆盖到真实流量。第二张快照看DSCP标记抓包或在设备上确认流经核心接口的包头的DSCP值语音应该是0x2E视频是0x22。第三张快照看队列深度在业务高峰时记录出接口的queue depth如果长期超过队列上限的50%说明带宽预算过紧。6.2 用带DSCP的ping和iperf3验证优先级行为验证QoS是否真的按优先级转发最直接的方法是打两类不同标记的流量做对比。iperf3可以指定DSCP值语音流量打0x2E普通流量打0x00然后观察延迟和丢包差异iperf3 -u -c 192.0.2.1 -b 2M -t 30 --tos 0x2E iperf3 -u -c 192.0.2.1 -b 2M -t 30 --tos 0x00第一组测的是高优先级UDP流第二组测的是普通流量。重点看Jitter和丢包率如果高优先级流在有背景流量冲击时延迟抖动依然平稳低优先级流丢包明显说明队列调度在起作用如果两者表现一致优先检查分类是否命中。Linux下ping也可以带DSCP测试连通性ping -Q 0x2E 目标地址。我自己的习惯是每次调完QoS无论时间多紧都要把三张快照重新拍一遍确认分类、标记、丢包三个维度没有回退再谈下一个参数。这个习惯救过我很多次因为QoS配置不报错、不告警只有对比基线才能看出它是不是真的在工作。希望帮到你。本文还有配套的精品资源点击获取 QoS网络技术核心解析：DiffServ、令牌桶与队列调度实践
简介企业专线带宽有限业务高峰期视频会议卡顿、ERP登录转圈单纯加带宽并不能根除延迟和丢包。QoS网络技术正是解决这类问题的关键它在物理带宽之上建立排队策略通过DiffServ模型对流量分类、标记、调度和丢弃让语音、视频、关键数据获得差异化保障。DSCP优先级映射、令牌桶CIR/CBS参数、LLQ与WRED队列算法都是决定QoS效果的核心要素。掌握这些原理与配置方法不仅适用于10M专线场景也能为后续网络优化提供通用的排错思路。QoS白皮书从模型选型到参数表再到部署与验证输出了一套可落地的完整参考。1. QoS网络技术不是“加带宽”它到底在分配什么资源一条总部到分支的10M专线白天一到业务高峰就卡视频会议马赛克、文件传输排队、ERP登录转圈。很多人的第一反应是给链路加点带宽但预算批下来、速率提上去之后卡顿只是从“每天两小时”变成“每天半小时”。真正把剩余半小时磨掉的往往是QoS网络技术这套资源再分配手段。它不是把路修得更宽而是在路不够宽的时候决定谁先走、谁等一等、谁可以被暂时牺牲。“QoS网络技术白皮书”这个名字容易被当成一套高深理论拆开看其实就是三个问题流量怎么认出来如何打上优先级标记排队和丢弃的规则按什么参数写。这篇笔记按白皮书的思路把背后的模型、参数表和落地顺序讲清楚并附上五条常见翻车记录和一套验证方法。适合刚接手网络优化、需要在方案里给出具体数值的工程师。2. 为什么会在转发路径上排队拥塞、延迟与DiffServ模型2.1 排队是QoS存在的物理前提接口发送速率是固定的。10M专线每秒最多发10Mbit数据当某个瞬间从交换机、终端和服务器到达出接口的数据量超过这个速率多余的包就只能进入接口缓冲队列排队。排队本身不是故障但它会带来三种影响延迟delay、抖动jitter和丢包drop。延迟让交互类操作变得拖沓抖动让语音和视频播放出现断续丢包触发TCP重传最终拉低整体吞吐。QoS在任何时刻都无法减少总数据量它只把有限的出接口能力按业务优先级重新分配。带宽是物理资源QoS是在物理资源上做的排队策略。理解这一点很重要如果链路长期处于满负荷状态无论QoS参数调得多精细延迟和丢包都只能被“有选择地”控制而不是被消除。这也是为什么白皮书开篇先讲拥塞模型——不认清楚排队是怎么发生的后面所有配置都只是盲调。2.2 三种服务模型选型为什么DiffServ是白皮书的主线QoS的三种服务模型经常被混在一起提实际选型差别很大。尽力而为模型BE不区分业务先到先走所有流量共享瓶颈。它适用于对延迟不敏感的普通上网场景但在语音视频和关键业务混跑的链路上基本不可用。资源预留模型IntServ通过RSVP协议端到端预留带宽能提供严格的逐流保障。代价是网络设备需要为每一个流维护状态流量一多内存和CPU开销迅速膨胀在骨干或汇聚层很难扩展所以实际部署范围很窄。区分服务模型DiffServ是当前企业网最主流的选择。它在网络边缘对流量分类打标中间节点只看标记决定转发优先级不维护逐流状态扩展性好得多。白皮书里的队列调度、DSCP映射、拥塞避免全部是围绕DiffServ展开的入方向识别业务打上不同标记出方向根据标记把流量放进不同队列。三种模型的对比可以这样看INT SERV适合小规模内网硬保障DiffServ适合中大规模逐跳部署BE作为兜底模型处理剩余流量。多数园区网和分支互联方案选DiffServ作为主线不会错。2.3 QoS的四个动作分类、标记、调度、丢弃DiffServ模型落到设备上是四个顺序固定的动作。第一步是分类把流量从海量背景中认出来。常用依据是五元组源IP、目的IP、协议、源端口、目的端口、入接口、VLAN或已有的DSCP值。第二步是标记把分类结果写进IP头语音打EF、视频打AF41、关键数据打AF11这一步让后面的设备“一眼认出”业务。第三步是队列调度出接口按队列规则决定谁先出队语音视频走低延迟队列普通数据走加权队列。第四步是拥塞避免队列快满时按概率先丢低优先级流量保护高优先级业务。这四步顺序不能反。先打标再分类是无效的因为标记还没写进去只分类不打标中间设备无法逐跳识别只调度不管弃拥塞峰值一来队列照样溢出。白皮书后面的配置模板全部按“分类→标记→调度→丢弃”这个顺序写部署时也按这个顺序核对能少踩很多坑。3. 白皮书里的核心参数表令牌桶、DSCP映射与队列调度算法3.1 令牌桶参数CIR/CBS/EBS怎么定突发为什么不能粗暴设大令牌桶是最常见的QoS限速模型很多设备上的限速命令都基于它。模型可以理解成一个蓄水池令牌按CIR速率持续落入桶中包要发送必须先消耗等量的令牌。桶满了令牌溢出桶空了包就得等待或丢弃。三个关键参数分别是CIR承诺信息速率单位bps决定令牌注入速度也就是理论上允许的长期平均速率CBS承诺突发尺寸单位字节决定桶的深度也就是一次可以容忍的突发量EBS超额突发尺寸决定超出CBS后还能以何种代价继续放行多少数据。常见误区是把CBS设成“一条带宽那么大”比如10M链路配10MB的CBS后果是限速形同虚设突发窗口长达数秒同链路其他流量被挤爆。CBS的经验算法是让桶至少容纳一个RTT内的突发。公式是CIR×RTT÷8。例如CIR为4Mbps目标RTT为30ms算出来约15KB起步可以给16KB到32KB再根据实际抓包峰值往上调。调的时候看一个指标峰值速率的持续时间。如果应用突发就是几个TCP窗口大小CBS给到几十KB就够如果数据库同步或备份会产生持续数十毫秒的大突发CBS要相应放大。EBS一般保持默认或设为0很多模板把EBS也配得很大等于放行第二波超发流量起不到保护作用。3.2 DSCP标记标准语音视频数据各用什么值信任边界在哪DSCP沿用IP头ToS字段的前6位在DiffServ里承担业务“身份证”的角色。不同设备厂商默认映射可能略有差异但业界有一套通行的取值习惯白皮书里的映射表通常是这个版本流量类型DSCP名称十进制十六进制典型用途语音RTPEF460x2E语音媒体流优先队列语音信令CS3240x18SIP/SCCP信令容错但需低延迟视频会议AF41340x22视频媒体流带丢弃优先级关键数据AF11100x0AERP/交易类低丢包保障网络控制CS6480x30路由协议与网管尽力而为BE00x00普通上网流量注意视频不一定非用AF41部分方案会用CS540但AF类自带三个丢弃优先级可以在拥塞时先丢低优先级帧比CS5更精细。语音信令用CS3而不是EF是因为信令包小但重要把它放进EF队列会和语音RTP竞争带宽CS3配合低延迟队列更稳妥。标记之后紧接着要划定信任边界。接入交换机连接终端设备的端口不应直接信任终端发来的DSCP否则用户只要改了自己网卡上的QoS优先级就能让普通流量插队到语音队列。常见做法是连接终端的端口在入方向做重标记把非标准DSCP改成BE连接路由器或上行汇聚的端口才信任DSCP并执行队列策略。信任边界画在哪里直接决定后面所有策略是否可信。3.3 队列调度算法对比PQ、WRR、WFQ、LLQ的适用场景队列调度算法决定“当多个队列都有包时谁先出接口”。四种算法要分清。FIFO先入先出没有分类能力流量按到达顺序发送一旦拥塞语音视频和数据互相拖累只能在极低负载链路使用。PQ严格优先让高优先级队列清空后才处理低优先级延迟最有保障但如果不加限制低优先级流量会被饿死。WRR加权轮询按权重在各队列间循环服务避免饿死但队列内仍然是FIFO且权重按包数而非字节数计算时小包队列会占便宜。WFQ加权公平按会话数动态分配带宽对TCP流量公平但无法为语音视频提供硬性的低延迟保证。算法调度机制优点缺点适用场景FIFO先到先发实现简单无业务区分低负载链路PQ严格优先延迟最可控低优先级可能饿死需限流的实时业务WRR按权重轮询各队列有带宽队列内FIFO、权重粒度粗数据流量混跑WFQ按会话公平TCP友好延迟不稳定纯数据链路LLQPQCBWFQ实时与公平兼顾需精确配带宽上限语音视频混合链路LLQ实际上是“严格优先带宽上限”的组合方案是语音视频场景里最常见的做法。它对EF队列开一个严格优先通道保证低延迟同时给这个通道设置带宽上限通常是业务需求的1.2倍超出上限的实时流量降级到普通队列避免语音视频把整条链路占死。白皮书里的配置模板如果面向语音视频基本都会落到LLQ上不会只给一个PQ或WRR。3.4 WRED用概率丢弃为TCP拥塞控制服务拥塞避免机制里WRED加权随机早期丢弃是数据流量最常用的方案。它的思路是队列还没满时按不同优先级设定阈值和丢弃概率提前随机丢一部分包让TCP源端感知拥塞、主动降低发送速率避免队列溢出后发生“全局同步”式的丢包风暴。DSCP为AF11的数据包丢弃概率设置得比BE低保证关键任务先保住普通浏览先丢。WRED对TCP类流量效果显著因为TCP会响应丢包降速。但UDP实时流量不会响应拥塞窗口被WRED随机丢弃只会造成花屏和断音。因此语音视频队列里通常关闭WRED依靠LLQ严格优先队列保证延迟而数据队列要开启WRED。常见误用是在所有队列都开WRED然后把高优先级流的丢弃阈值设得和低优先级一样那等于没区分业务配置再复杂也白搭。4. 把白皮书落成配置一个10M专线的QoS部署步骤4.1 部署前先做三件事流量基线、带宽预算、信任边界拿到一份QoS方案先不要急着敲命令。第一件事是抓流量基线用netflow或sFlow在出口观察一到两周确认语音、视频、ERP、普通上网各占多少比例峰值出现在什么时段。第二件事是算带宽预算。以10M专线为例语音预留1Mbps视频会议预留4Mbps关键数据预留1.5Mbps剩下的3.5Mbps给普通业务。这样即使视频会议开到极限ERP也有保障普通流量不至于完全断流。业务类型DSCP预留带宽队列安排语音RTP信令EF/CS31MbpsLLQ严格优先视频会议AF414Mbps加权队列高权重ERP/交易数据AF111.5Mbps加权队列中权重普通上网BE3.5Mbps默认队列第三件事是画信任边界。终端接入端口标记为不可信上行汇聚端口标记为可信中间每一跳都要明确“这个端口是否接受来自对端的DSCP”。三步做完后配置只是把这些数值填进设备而不是边做边猜。4.2 入方向监管与出方向调度的方向性问题QoS的入方向和出方向承担不同职责很多人在这里翻车。入方向的监管Policing负责检查流量是否违约超出CIR的部分直接丢弃或重标记常用于限制用户侧流量。出方向的整形Shaping负责平滑发送速率超出的流量先缓存再按CIR发送常用于适配物理线路带宽。调度队列和拥塞避免则必须作用在出方向因为只有出口才存在真正的发送竞争。动作方向超出CIR处理适用场景监管Policing入方向直接丢包或重标记防止终端骗标、超速整形Shaping出方向缓存排队后再发适配物理链路速率常见错误是把限速命令配在出方向结果超出速率的数据被立即丢弃TCP进入快速重传吞吐反而下降或把队列调度配在入方向但很多设备入方向根本不支持队列调度配置直接不生效。正确顺序是入方向做分类、标记、监管出方向做整形、队列调度、拥塞避免。4.3 六步落地清单从匹配流量到队列参数在支持MQC框架的设备上可以用类图加策略图的方式组织配置逻辑。这是一个通用的六步流程按顺序执行第一步定义流量类。按五元组匹配业务语音信令匹配SIP端口5060语音RTP匹配UDP端口范围视频会议匹配特定IP段ERP匹配服务器地址。第二步在入方向打标。设置DSCP映射表EF给语音、AF41给视频、AF11给ERP、BE给其他。第三步在接入端口做重标记。连接终端的端口把入向流量统一打到BE防止用户私自改优先级。第四步配置入方向监管。对EF队列限速1Mbps对AF41限速4Mbps超出部分重标记为BE。第五步配置出方向队列。EF和CS3进LLQ严格优先队列上限给1.2MbpsAF41走加权队列权重设40%AF11权重设15%BE设35%。第六步开启拥塞避免。数据队列开WRED实时队列关闭WRED。每一步做完都用查看命令确认计数器在增长再做下一步。QoS是逐跳行为中间交换设备如果不认DSCP或直接改写掉了链路末端的配置再完美也没有用需要沿转发路径逐台确认。5. QoS配置常见问题排查五个能让你翻车的坑5.1 限速策略一直不生效方向与接口归属搞错了现象策略配置完流量速率纹丝不动或者小包被丢、大包照常通过。原因通常有两个一是方向配反限速配在出方向但设备出方向不支持监管二是策略挂在了一个不包含该流量的接口或子接口上。解决先在接口上确认策略是否生效绝大多数设备的查看命令能列出接口方向和匹配次数然后把监管确认放在入方向把队列确认放在出方向。子接口场景要注意物理接口策略和子接口策略同时存在时匹配顺序按设备逻辑而定先查子接口覆盖关系。5.2 突发流量被误杀令牌桶的CBS和EBS设得太小现象平时速率正常一到业务整点比如报表生成、数据库备份就出现成片丢包业务报错。原因CIR设得合理但CBS只给了默认值有的设备默认只有8KB一次几MB的突发被桶深卡死包在入方向就被丢弃。解决按CIR×RTT÷8估算CBS再放大到实测峰值具体到10M链路CBS从32KB到128KB逐级试EBS保持默认或0不要把EBS当额外突发通道。验证方式是边打流边看令牌桶漏桶计数器确认丢包集中在突发时段而非持续。5.3 语音视频仍然卡顿信任边界和中间设备重写了DSCP现象QoS配置明明做了语音视频还是卡show policy-map接口上分类匹配计数低得可怜。原因中间交换机在转发时把DSCP改写了或接入端口信任了终端发来的错误标记导致高优先级流量根本没被识别。解决沿转发路径逐台检查DSCP值使用带DSCP的ping或抓包工具确认每个节点收到的标记是否一致把信任边界收敛到接入层终端端口重标记汇聚层以上保持信任。另一个容易被忽略的点是MQC分类的顺序有些设备按“首个匹配生效”如果匹配普通上网的规则写在前语音RTP会先进错队列。5.4 大流量时段低优先级业务全部超时PQ或LLQ没有设置带宽上限现象开启严格优先队列后业务高峰期普通网页和邮件全部超时。原因PQ队列是绝对优先如果语音视频队列里涌入超过实际需求的流量普通队列在拥塞时几乎没有发包机会。解决给严格优先队列设置带宽上限LLQ模式下的标准做法是上限设为业务需求的1.2倍左右超出上限的流量降级到普通队列。配置后要做一次满负载测试同时打满视频和BE流量确认低优先级业务仍然有可用的带宽块。5.5 drop为零但体验依旧差只看丢包不看延迟和抖动现象队列计数表里丢包计数器是0但视频会议依旧卡顿、操作延迟高。原因链路拥塞达到排队临界点时包没有被丢弃但等待时间拉长表现为延迟上升和抖动加剧丢包未发生不代表QoS生效。解决同时看queue depth队列深度和延迟抖动数据队列深度持续攀升说明带宽预算有问题用双向并发流量测试单向延迟和抖动不要把ICMP的RTT当作业务体验的唯一指标。物理链路误码也会导致TCP拥塞窗口塌缩这时QoS无能为力需要检查光模块和线路质量。6. 落地验证技巧用ping、iperf3与show命令确认QoS真的生效6.1 上线前先拍三张快照分类命中、DSCP标记、队列深度QoS上线前后必须各留一套基线。第一张快照看分类命中查看设备上策略图的匹配计数EF、AF41、AF11三类流量都必须有持续增长的数字如果某个计数为0说明匹配条件没覆盖到真实流量。第二张快照看DSCP标记抓包或在设备上确认流经核心接口的包头的DSCP值语音应该是0x2E视频是0x22。第三张快照看队列深度在业务高峰时记录出接口的queue depth如果长期超过队列上限的50%说明带宽预算过紧。6.2 用带DSCP的ping和iperf3验证优先级行为验证QoS是否真的按优先级转发最直接的方法是打两类不同标记的流量做对比。iperf3可以指定DSCP值语音流量打0x2E普通流量打0x00然后观察延迟和丢包差异iperf3 -u -c 192.0.2.1 -b 2M -t 30 --tos 0x2E iperf3 -u -c 192.0.2.1 -b 2M -t 30 --tos 0x00第一组测的是高优先级UDP流第二组测的是普通流量。重点看Jitter和丢包率如果高优先级流在有背景流量冲击时延迟抖动依然平稳低优先级流丢包明显说明队列调度在起作用如果两者表现一致优先检查分类是否命中。Linux下ping也可以带DSCP测试连通性ping -Q 0x2E 目标地址。我自己的习惯是每次调完QoS无论时间多紧都要把三张快照重新拍一遍确认分类、标记、丢包三个维度没有回退再谈下一个参数。这个习惯救过我很多次因为QoS配置不报错、不告警只有对比基线才能看出它是不是真的在工作。希望帮到你。本文还有配套的精品资源点击获取