Docker容器中用TC规则无法精确限流，如何提升带宽整形精度？

我在EC2环境里处理过不少类似的TC带宽整形精度问题，你遇到的10%-20%带宽偏差其实挺常见的，主要和EC2底层网络开销、HTB队列调度器的默认配置有关。以下是几个可以尝试的优化手段：

1. 为HTB类添加ceil参数并调整rate的冗余值 #

你的现有规则里只设置了rate（保证带宽），但HTB默认ceil（最大允许带宽）等于rate，再加上EC2网络栈本身有固定开销（比如TCP/IP封装、ENI处理），实际可通过的流量会被这些开销吃掉一部分。

修改后的规则可以给目标类加上ceil，并稍微调高rate来抵消开销：

tc qdisc add dev eth0 handle 1: root htb default 11
tc class add dev eth0 parent 1: classid 1:1 htb rate 155Mbps ceil 155Mbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 155Mbit ceil 155Mbit
tc qdisc add dev eth0 parent 1:11 handle 10: netem delay 50ms

建议先测试155-160Mbps的设置，根据实际观测值微调，直到接近你的150Mbps目标。

2. 配置HTB的burst和cburst参数 #

HTB的默认burst值很小，会导致流量无法充分利用设定的带宽（尤其是突发流量场景）。burst用于普通队列的突发流量控制，cburst用于HTB内部的高速转发队列，设置合适的值可以让带宽更接近设定值：

# 假设MTU为1500字节，设置适合150Mbps的burst值（约20KB）
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 155Mbit ceil 155Mbit burst 20k cburst 20k

你也可以根据实际的MTU和带宽需求调整这个值，一般建议设置为1-2倍的MTU * 10-20个数据包的大小。

3. 关闭EC2实例的TCP Offloading特性 #

EC2默认开启的TSO（TCP Segmentation Offload）、GRO（Generic Receive Offload）等特性，会让网卡直接处理数据包分段/合并，这可能和TC的流量统计逻辑冲突，导致带宽计算不准。可以关闭这些特性后再测试：

ethtool -K eth0 tso off gro off gso off

测试完成后如果需要恢复，把off改成on即可。

4. 检查EC2实例的网络性能类型 #

如果你的EC2实例是突发型实例（比如t2、t3系列），它的网络带宽是基于信用分（credit）的，当信用分不足时，实际带宽会被限制，这时候TC的整形效果自然会打折扣。建议换成固定带宽型实例（比如m5、c5、r5系列），这类实例的网络带宽是稳定的，更适合做流量整形。

另外，部分实例的ENI有带宽上限，如果你的实例规格本身带宽就接近150Mbps，可能会出现底层限制导致的偏差。

5. 结合FQ_Codel队列调度器优化队列管理 #

HTB主要做流量分类和带宽限制，后续配合FQ_Codel（Fair Queueing Controlled Delay）调度器，可以优化队列拥塞，减少丢包，间接提升带宽利用率。在netem之后添加FQ_Codel：

tc qdisc add dev eth0 parent 1:11 handle 10: netem delay 50ms
tc qdisc add dev eth0 parent 10: fq_codel

FQ_Codel可以自动调整队列长度，避免因为队列满导致的数据包丢失，让流量更稳定地达到设定带宽。

为什么延迟精度高而带宽偏差大？ #

延迟整形是基于数据包的转发时间注入固定延迟，netem的实现是内核级别的，精度很高；而带宽整形需要统计流量速率、控制数据包发送节奏，这会受到宿主机CPU负载、EC2底层网络转发开销、TCP协议本身的拥塞控制等多种因素影响，所以偏差会更大。

内容的提问来源于stack exchange，提问作者shreyas