为什么限速100Mbps，却能瞬间跑到500Mbps？——一次运营商QoS误判，彻底理解DPDK rte_meter 与 Token Bucket（上）

一、一次看似QoS失效的客户投诉某运营商部署了一套基于DPDK开发的业务网关。系统主要承载企业专线业务。为了保证不同客户的服务等级SLA每条专线都配置了独立的带宽策略。其中某客户购买的是参数配置值合同带宽CIR100 Mbps峰值带宽PIR200 MbpsQoS算法trTCM实现方式DPDKlibrte_meter系统上线后运行稳定。几天后。客户发来测速截图。测速软件显示最高瞬时速率536 Mbps客户认为不是说限速100Mbps吗为什么还能跑到500MbpsQoS是不是根本没有生效运营商维护人员第一时间也产生了怀疑。如果限速真的失效。不仅会影响带宽公平分配。还可能造成其它业务受到冲击。于是。研发团队开始排查。二、第一轮排查是不是Meter没有生效研发首先检查QoS配置。确认rte_meter_trtcm_profile_config(...)返回成功。继续检查每个Flow对应的Meter实例。发现所有业务流都已经正确关联。随后打印Meter统计信息。Green、Yellow、Red三种颜色的计数器都在正常变化。说明Meter一直在工作。并没有失效。三、第二轮排查是不是限速算法实现错误研发继续怀疑是不是自己调用API的方法有问题重新阅读DPDK官方文档。发现Meter每收到一个数据包。都会调用类似下面的接口完成计量enum rte_color color rte_meter_trtcm_color_blind_check( meter, profile, time, pkt_len);函数返回值只有三种返回值含义Green符合合同流量Yellow超过承诺流量但仍允许转发Red超过峰值流量整个过程。没有任何地方直接修改发送速率。也没有任何地方主动等待。这时。研发团队第一次意识到Meter可能并不是自己一直理解的那个限速器。四、Meter到底在做什么很多开发者第一次接触DPDK QoS。都会把rte_meter理解成限速模块。实际上。这种理解并不准确。Meter真正完成的是流量计量Traffic Metering。它回答的问题只有一个当前这个数据包是否仍然符合合同约定的流量注意。它判断的是是否符合合同。而不是什么时候发送。例如某企业专线合同规定100 MbpsMeter并不会主动把网卡限制到100Mbps。它只是判断这个包属于合同内流量可容忍突发流量严重超速流量。真正决定是否丢弃、是否延迟发送、是否降低优先级属于后面的QoS策略。五、QoS为什么要先计量再处理很多人会问既然目标就是限速。为什么不直接超过100Mbps ↓ 立即丢弃答案是否定的。因为运营商QoS真正遵循的是SLAService Level Agreement服务等级协议。SLA约定的是平均带宽峰值带宽可接受突发丢弃策略。而不是每一毫秒都必须严格保持100Mbps。例如一个企业用户。连续30秒没有任何业务。随后突然上传一个几十MB的设计文件。如果设备立即按照100Mbps硬限制。用户体验会非常差。因此。现代QoS几乎都允许合理突发Burst。这也是Token Bucket诞生的原因。六、Token Bucket到底是什么Token Bucket中文通常翻译为令牌桶算法。很多初学者会认为桶里面装的是数据包。实际上桶里面装的不是数据。而是发送许可Token。可以把它理解成一台不断打印通行证的机器。例如合同带宽100 Mbps系统会按照固定速率。持续向桶中放入Token。每发送一个数据包都必须消耗一定数量的Token。例如发送一个1500 Byte的数据包就需要消耗对应字节数的Token。如果桶中Token充足。数据包就是Green如果Token不足。就进入Yellow。继续发送。最终可能变成Red。整个过程中Token并不会控制网卡。它只是告诉系统这个包是否已经超出了合同约定。七、为什么100Mbps还能跑到500Mbps这是整个案例最关键的问题。假设企业客户已经一分钟没有任何流量。那么Token Bucket会发生什么答案是持续积累Token。例如桶容量配置为CBS 8 MB一分钟后桶已经积累了足够多的Token。此时客户突然开始测速。测速软件会立即发送大量TCP数据。由于桶中已经提前积累了大量Token。前面这一批数据包全部能够正常通过。测速软件看到的结果就是520 Mbps 480 Mbps 560 Mbps客户自然认为QoS失效了。实际上此时Meter完全正常。它只是允许提前积累的额度一次性使用。八、Token为什么允许提前积累很多人第一次看到这里都会产生疑问既然目标是100Mbps为什么不让Token始终保持固定数量原因在于互联网业务本身就是突发的。例如浏览网页。大多数时间几乎没有数据。点击一个链接后瞬间下载几十MB。再例如视频会议。音频和视频数据也不是均匀产生的。如果QoS严格按照每毫秒100Mbps控制。每一次业务突发都会被人为打断。不仅影响吞吐还会显著增加应用时延。因此Token Bucket的设计目标并不是限制瞬时速率。而是保证长期平均速率符合合同要求同时允许一定程度的短时突发。这正是它与硬限速最大的区别。九、DPDK为什么没有自己发明新的Meter算法很多人阅读DPDK源码时会发现。DPDK并没有设计自己的QoS算法。而是直接实现了RFC 2697srTCMRFC 2698trTCMRFC 4115改进型trTCM原因很简单。运营商网络几十年来已经形成统一标准。无论是BRAS、BNG、PE路由器还是5G UPF。流量计量几乎都遵循这些RFC。DPDK作为数据平面开发框架。更关注高性能实现标准算法。而不是重新定义标准。因此理解RFC实际上就是理解DPDKlibrte_meter的设计思想。十、真正的问题开始浮现经过前面的排查。研发团队终于确认QoS配置没有错误Meter工作正常Token Bucket算法也完全符合RFC标准。那么为什么客户看到的测速结果仍然远高于合同带宽真正的答案已经越来越接近问题并不在Meter是否生效而在于大家对带宽这个概念的理解存在偏差。未完待续