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

一、一次看似"QoS失效"的客户投诉

某运营商部署了一套基于DPDK开发的业务网关。

系统主要承载企业专线业务。

为了保证不同客户的服务等级（SLA），每条专线都配置了独立的带宽策略。

其中某客户购买的是：

系统上线后运行稳定。

几天后。

客户发来测速截图。

测速软件显示：

最高瞬时速率：536 Mbps

客户认为：

不是说限速100Mbps吗？

为什么还能跑到500Mbps？

QoS是不是根本没有生效？

运营商维护人员第一时间也产生了怀疑。

如果限速真的失效。

不仅会影响带宽公平分配。

还可能造成其它业务受到冲击。

于是。

研发团队开始排查。

二、第一轮排查：是不是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);

函数返回值只有三种：

整个过程。

没有任何地方直接修改发送速率。

也没有任何地方主动等待。

这时。

研发团队第一次意识到：

Meter可能并不是自己一直理解的那个"限速器"。

四、Meter到底在做什么？

很多开发者第一次接触DPDK QoS。

都会把：

rte_meter

理解成：

限速模块。

实际上。

这种理解并不准确。

Meter真正完成的是：

流量计量（Traffic Metering）。

它回答的问题只有一个：

当前这个数据包，是否仍然符合合同约定的流量？

注意。

它判断的是：是否符合合同。

而不是：什么时候发送。

例如：

某企业专线合同规定：

100 Mbps

Meter并不会主动把网卡限制到100Mbps。

它只是判断：

这个包属于：

• 合同内流量；
• 可容忍突发流量；
• 严重超速流量。

真正决定是否丢弃、是否延迟发送、是否降低优先级，属于后面的QoS策略。

五、QoS为什么要先"计量"再"处理"？

很多人会问：既然目标就是限速。

为什么不直接：

超过100Mbps ↓ 立即丢弃

答案是否定的。

因为运营商QoS真正遵循的是：SLA（Service 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 2697（srTCM）
• RFC 2698（trTCM）
• RFC 4115（改进型trTCM）

原因很简单。

运营商网络几十年来已经形成统一标准。

无论是BRAS、BNG、PE路由器，还是5G UPF。

流量计量几乎都遵循这些RFC。

DPDK作为数据平面开发框架。

更关注：高性能实现标准算法。

而不是重新定义标准。

因此，理解RFC，实际上就是理解DPDKlibrte_meter的设计思想。

十、真正的问题开始浮现

经过前面的排查。

研发团队终于确认：

• QoS配置没有错误；
• Meter工作正常；
• Token Bucket算法也完全符合RFC标准。

那么为什么客户看到的测速结果仍然远高于合同带宽？

真正的答案已经越来越接近：

问题并不在Meter是否生效，而在于大家对"带宽"这个概念的理解存在偏差。

（未完待续）