我试图在Linux服务器上设置一些简单的带宽限制，尽pipeconfiguration看起来微不足道，但我却遇到了一些似乎很奇怪的事情。
我想要将到达特定客户端IP（10.41.240.240）的stream量设置为最高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 为了testing，我开始从所述客户端机器通过HTTP下载文件，并通过查看Firefox中的Kb / s来测量所得到的速度。
现在，这个行为是令人费解的：DL从大约10Kbyte / s开始，继续加速直到稳定在大约75Kbytes / s（千字节，而不是像configuration的Kilobits！）。 那么，如果我开始几个同样的文件并行下载，每个下载稳定在大约45K字节/秒; 这些下载的组合速度因此大大超过configuration的最大值。
这是我探测tcdebugging信息时得到的
[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的赛门铁克75000bit”configuration的“速率589888bit 5pps”？ 为什么有效利率远高于configuration的利率呢？ 我究竟做错了什么？ 为什么它的行为是这样的？
请帮忙，我被困住了。 多谢你们。
我想我有点解决了这个问题：我需要将qdiscs / classes绑定到IMQ设备而不是ETH设备。 一旦我做到了，整形器开始工作。
然而！
虽然我可以让整形器限制stream入机器的stream量，但我无法公平地分streamstream量（即使我已经附加了SFQ到我的HTB）。
发生了什么事情是：我开始下载; 它被限制在75Kbyte / s。 现在，当我开始第二次下载，而不是在2个DL会话（35Kbyte / s + 35Kbyte / s）之间平均分配stream量时，它仅仅在会话1上下降了速度，给会话2下了500b / s。 几分钟后，拆分解决了65千字节/秒+ 10千字节/秒。 愤慨这不公平！ 🙂
于是我拆了我的configuration，继续build立了一个拥有stream量整形器模块的ClearOS 5.2（一个带有预置防火墙系统的Linux发行版）。 该模块使用HTB + SFQ设置非常类似于我手动configuration。
同样的公平性问题！ 整体限制执行得很好，但没有公平！ – 两个下载份额在65/15的比例相同，而不是35/35。
任何想法，家伙？
尝试使用这个例子：
# 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
这将创build一个速率限制为75Kbit / s的htb存储桶，然后在其下面创build两个sfq（一个公平排队qdisc）。
默认情况下，每个人都将处于第一个队列，保证速率为1Kbit，最大速率为30Kbit。 现在，你的IP为10.41.240.240将保证35Kbit，如果使用非select的stream量，可能会花费高达75Kbit。 来自.240的两个连接应该是平均的，并且每个连接是相同的，并且在.240和non.240之间的连接将以队列之间的35：1的比率平行。
我发现自从四月份以来这已经死了…所以希望这个信息对你仍然有价值。
这可能与此有关：
来自： http : //www.shorewall.net/traffic_shaping.htm
Xen用户的警告
如果您在dom0中运行stream量整形，并且stream量整形似乎不能正确限制stream量，可能是由于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
上述输出有两个明显的问题：
这个问题将通过使用ethtool实用程序禁用domU中的“校验和卸载”来解决。 请参阅Xen文章中的说明。