我正在尝试在 Linux 服务器上设置一些简单的带宽限制，尽管配置看似简单，但我遇到了一些非常奇怪的事情。
我想将流向特定客户端 IP (10.41.240.240) 的流量限制为 75Kbit/s 的硬最大值。以下是我设置限制的方法：
# tc qdisc add dev eth1 root handle 1: htb default 1 r2q 1
# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 75kbit
# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst
10.41.240.240 flowid 1:10
为了测试，我从所述客户端机器开始通过 HTTP 下载文件，并通过查看 Firefox 中的 Kb/s 来测量最终的速度。
现在，这种行为相当令人费解：下载速度从大约 10Kbyte/s 开始，然后逐渐加快，直到稳定在大约 75Kbytes/s（千字节，而不是配置的千位！）。然后，如果我开始多次并行下载同一个文件，每次下载都会稳定在大约 45Kbytes/s；因此，这些下载的总速度大大超过了配置的最大值。
这是我在探测 tc 的调试信息时得到的结果
[root@kup-gw-02 /]# tc -s qdisc show dev eth1
qdisc htb 1: r2q 1 default 1 direct_packets_stat 1
Sent 17475717 bytes 1334 pkt (dropped 0, overlimits 2782 requeues 0)
rate 0bit 0pps backlog 0b 12p requeues 0
[root@kup-gw-02 /]# tc -s class show dev eth1
class htb 1:1 root rate 75000bit ceil 75000bit burst 1608b cburst 1608b
Sent 14369397 bytes 1124 pkt (dropped 0, overlimits 0 requeues 0)
rate 577896bit 5pps backlog 0b 0p requeues 0
lended: 1 borrowed: 0 giants: 1938
tokens: -205561 ctokens: -205561
class htb 1:10 parent 1:1 prio 0 **rate 75000bit ceil 75000bit** burst 1608b cburst 1608b
Sent 14529077 bytes 1134 pkt (dropped 0, overlimits 0 requeues 0)
**rate 589888bit** 5pps backlog 0b 11p requeues 0
lended: 1123 borrowed: 0 giants: 1938
tokens: -205561 ctokens: -205561
我终生无法理解的是：为什么我使用“速率 75000bit ceil 75000bit”的配置得到“速率 589888bit 5pps”？为什么实际速率比配置的速率高出这么多？我做错了什么？为什么它会这样表现？
请帮忙，我被难住了。谢谢大家。
答案1
我认为我差不多解决了这个问题：我需要将 qdiscs/classes 绑定到 IMQ 设备而不是 ETH 设备。一旦我这样做了，整形器就开始工作了。
然而！
尽管我可以让整形器限制进入机器的流量，但我无法让它公平地分割流量（即使我已将 SFQ 附加到我的 HTB）。
事情是这样的：我开始下载；速度被限制在 75Kbyte/s。现在，当我开始第二次下载时，流量并没有均匀地分配到两个下载会话（35Kbyte/s + 35Kbyte/s），而是只稍微降低了第一个会话的速度，而第二个会话的速度只有微不足道的 500b/s。几分钟后，分配稳定在 65Kbyte/s + 10 Kbyte/s 左右。愤慨地这不公平！ ：）
所以我拆解了我的配置，继续设置 ClearOS 5.2（带有预建防火墙系统的 Linux 发行版），它有一个流量整形器模块。该模块使用 HTB + SFQ 设置，与我手动配置的非常相似。
同样的公平问题！总体限制执行得很好，但没有公平性！- 两个下载共享相同的奇怪比例 65/15 而不是 35/35。
大家有什么想法吗？
答案2
尝试使用这个例子：
# tc qdisc add dev eth1 root handle 1: htb default 10
# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1Kbit ceil 35Kbit
# tc class add dev eth1 parent 1:1 classid 1:20 htb rate 35kbit
# tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10
# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 \
match ip dst 10.41.240.240 flowid 1:20
这将创建一个速率限制为 75Kbit/s 的 htb 存储桶，然后在其下方创建两个 sfq（公平排队 qdisc）。
默认情况下，每个人都会处于第一个队列中，保证速率为 1Kbit，最大速率为 30Kbit。现在，您的 IP 10.41.240.240 将保证 35Kbit，如果使用非选定流量，则最多可以占用 75Kbit。来自 .240 的两个连接应该平均并且每个连接相同，而 .240 和非 .240 之间的连接将以 35:1 的队列比率并行。
我发现这个从四月份就消失了...所以希望这些信息对你仍然有价值。
答案3
这可能与此有关：
从：http://www.shorewall.net/traffic_shaping.htm
对 Xen 用户的警告
如果您在 dom0 中运行流量整形，而流量整形似乎无法正确限制传出流量，则可能是由于 domU 中的“校验和卸载”造成的。检查“shorewall show tc”的输出。以下是该命令输出的摘录：
class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0
Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0)
rate 299288bit 3pps backlog 0b 0p requeues 0
lended: 53963 borrowed: 21361 giants: 90174
tokens: -26688 ctokens: -14783
上面的输出有两个明显的问题：
- 该比率（299288）明显高于上限（230000）。
- 据报道，巨人数量众多（90174）。
通过使用 ethtool 实用程序禁用 domU 中的“校验和卸载”，可以解决此问题。请参阅其中一篇 Xen 文章以获取说明。