在上一部分为什么限速100Mbps却能瞬间跑到500Mbps——一次运营商QoS误判彻底理解DPDK rte_meter 与 Token Bucket上-CSDN博客我们已经确认rte_meter工作完全正常Token Bucket并没有失效客户看到的500Mbps峰值其实来源于提前积累的Token。但是一个新的问题又出现了。如果允许一直积累Token那是不是用户永远都可以突破带宽限制答案当然不是。真正控制这一切的就是Token Bucket中的几个关键参数。十一、为什么必须限制Bucket容量很多开发者第一次实现Token Bucket时都会写成按照100Mbps不断产生Token这样看起来没有任何问题。但是如果Token能够无限增长。例如一天没有任何流量 ↓ 积累几十GB Token ↓ 第二天 瞬间发送几十GB那么QoS就彻底失去了意义。因此。所有Token Bucket都会规定Bucket容量Bucket Size。超过容量以后新的Token直接丢弃。也就是说Token ↓ Bucket满 ↓ 停止累积这就是Burst 为什么一定是有限的。十二、CBS到底是什么很多人在DPDK里面第一次看到cbs都会理解成缓存。其实不是。CBS全称Committed Burst Size中文通常翻译承诺突发容量。它表示最多允许积累多少合同带宽对应的Token。例如配置CIR 100Mbps CBS 1MB那么一分钟没有业务。Bucket里面也最多只有1MB。不会继续增长。所以。真正允许突发的数据量。不是一分钟积累多少。而是CBS决定。十三、trTCM为什么又多了PIR上一节我们提到DPDK支持srTCM以及trTCM很多人都会问为什么还需要第二种答案就在于运营商真正卖的不是一个带宽。而是两个带宽。例如企业专线。合同保证 100Mbps但是允许峰值200Mbps。于是。QoS就出现两个概念。参数含义CIR保证带宽Committed Information RatePIR峰值带宽Peak Information Rate对应两个BucketCBS、PBS。整个模型如下只有两个Bucket共同工作。才能真正实现运营商合同。十四、Green、Yellow、Red到底怎么来的很多人认为三种颜色是三个速率。其实不是。真正过程例如收到一个1500Byte数据包。第一步检查Peak Bucket。如果Peak Token都不够。立即Red如果Peak足够。继续检查Committed Bucket。如果Committed也足够。就是Green否则就是Yellow整个判断。只有几十条CPU指令。没有任何等待。没有任何Sleep。这也是DPDK能够百万级Flow。仍然高速Meter真正原因。十五、DPDKrte_meter为什么能够做到每包计量很多人第一次阅读librte_mete源码。都会觉得每个包都要更新时间、更新Token、计算颜色。为什么还能100G原因就在于它并没有周期性刷新Token。真正实现采用的是惰性更新Lazy Update。也就是说。不会每1毫秒更新一次。而是收到数据包才计算距离上次过去了多久。例如last_time ↓ 当前时间 ↓ delta ↓ 新增Token ↓ 更新Bucket如果一分钟没有包。CPU什么都不做。下一包到来一次补齐一分钟所有Token。因此。时间复杂度始终O(1)。十六、为什么测速必须持续30秒以上很多客户测速喜欢点击开始。看到第一秒500Mbps。立即截图、投诉。实际上运营商真正验收通常要求持续30秒甚至60秒。原因就在于前几秒消耗的是CBS里面提前积累的Token。随着Bucket逐渐耗尽。系统开始只能按照CIR补充Token。于是测速曲线开始下降。最终稳定100Mbps。真正符合合同。因此QoS验收从来不是看瞬时速率。而是长期平均速率。十七、研发团队最终是如何定位问题的研发团队最终抓取Meter统计信息。发现整个测速过程呈现如下变化时间GreenYellowRed0~2 秒大量少量02~5 秒减少增加少量5 秒以后基本稳定少量稳定增长与此同时。出口平均带宽逐渐稳定101 Mbps这说明Meter始终按照RFC2698正常工作。客户看到的500Mbps只是Burst。而不是长期带宽。十八、DPDK工程实践中的几个误区实际项目中rte_meter使用最容易踩的几个坑包括误区一把Meter当成限速器。rte_meter不会阻塞数据包也不会控制发送节奏它只负责完成流量计量并返回颜色。误区二CBS配置过大。CBS越大允许的突发越大。配置不合理时用户测速会看到很高的瞬时速率从而误认为限速失效。误区三每个数据包都重新初始化Meter。Meter对象必须保存每个业务流的状态Token、时间戳等不能每处理一个包就重新创建否则计量结果完全错误。误区四把Meter和Scheduler混为一谈。Meter负责判定Scheduler负责执行。两者职责完全不同。十九、Meter之后为什么还需要Scheduler到这里很多读者又会产生新的疑问。假设Meter已经返回Green或者Yellow下一步怎么办实际上。Meter根本不会发送。也不会排队。它只是告诉后面的QoS模块这个包是什么颜色。真正决定什么时候发送什么时候丢弃什么时候降优先级全部属于Scheduler。这也是DPDK为什么把QoS拆成两个库。librte_meter负责Traffic Metering。librte_sched负责Traffic Scheduling。二者共同组成完整QoS。二十、写在最后很多开发者第一次接触QoS时都会把限速理解成超过100Mbps立即禁止发送。事实上现代运营商QoS遵循的是SLA思想它关注的是长期平均速率而不是每一个瞬间的发送速度。librte_meter正是这一思想的高性能实现。它依据RFC2697、RFC2698和RFC4115通过Token Bucket模型完成每个数据包的流量计量并返回Green、Yellow、Red三种颜色而不是直接控制发送行为。真正的QoS流程应该理解为Packet │ ▼ Meter计量 │ ▼ ColorGreen / Yellow / Red │ ▼ Scheduler调度 │ ▼ Queue排队 │ ▼ NIC发送因此当客户反馈100Mbps为什么能跑到500Mbps时首先应该分析的是CBS、PBS以及Burst配置而不是怀疑Meter是否失效。