linux下使用TC流量控制总结

wysilly

测试环境和规则.

一起看看不就知道了.

platinum

原帖由 wysilly 于 2007-7-2 11:52 发表于 31楼  
测试环境和规则.

一起看看不就知道了.

测试环境和规则前面都说过了，看了半天也没弄明白要知道什么，没有你说的那么简单
假设一条 2Mbps 的线路，你保障某个应用 1.5Mbps 带宽，而外来主推流量多达 1Mbps（可视为无效流量）
试问：那个你要保障的应用最高能跑到多少？

wysilly

原帖由 platinum 于 2007-7-2 12:07 发表于 32楼  

测试环境和规则前面都说过了，看了半天也没弄明白要知道什么，没有你说的那么简单
假设一条 2Mbps 的线路，你保障某个应用 1.5Mbps 带宽，而外来主推流量多达 1Mbps（可视为无效流量）
试问：那个你要保障的 ...

呵呵,你想的太多了．
如果规则定义就是为了区分上行和下行两部分．那么到了最后最严格的方法就是对每ip定义规则了,否则没有两全的解决途径了．

platinum

原帖由 wysilly 于 2007-7-2 12:44 发表于 33楼  

呵呵,你想的太多了．
如果规则定义就是为了区分上行和下行两部分．那么到了最后最严格的方法就是对每ip定义规则了,否则没有两全的解决途径了．

不，你错了，我想的并不多，这是网络里一个很普遍的现象
当你使用 P2P 软件时，会招惹来外网流量的主动推送，从而堵塞你的 ISP 链路

liuzhuan23

1. 过滤器的优先级：“优先对谁分类”，就是一个顺序的问题，比如，你有IP匹配 prio 1，port匹配 prio 2，那一定是先匹配IP了

2. 分类的优先级：谁先入队，谁先出队的问题，比如，http prio 1，ftp prio 2，那http数据应该是先入队，先出队

3. 多线程下载以及P2P的问题：

我的下行链路最大3M，这边按bit计流量，所以我的实际下行链路最大为300多k

tc qdisc add dev imq0 root handle 1: htb default 255

tc class add dev imq0 parent 1: classid 1:1 htb rate 300kbps

tc class add dev imq0 parent 1:1 classid 1:10 htb rate 50kbps ceil 80kbps prio 1
tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 5

tc class add dev imq0 parent 1:1 classid 1:255 htb rate 20kbps ceil 30kbps prio 2
tc qdisc add dev imq0 parent 1:255 handle 255: sfq perturb 5

tc filter add dev imq0 protocol ip parent 1:0 u32 match ip sport 80 0xffff flowid 1:10

子类的ceil不要设置为接近物理带宽，本着 ceil-rate=借用带宽 的原则即可

classid 1:10使用http下载，6个连接数，保持在80k左右，平稳
classid 1:255使用ppstream（我这没有BT，不好意思），具体流量我没有估算出来，但20k-30k的流量应该是看不了ppstream的，结果也正是这样，不停的缓冲，如果去掉classid 1:255队列管制，ppstream很流畅

platinum

300KB = 300 * 8 = 2400Mbps（1 Byte = 8 bits）
你的带宽是 3Mbps，里外里损失了 600Kbps 哦
不过，这样的带宽压制，对于保障来说效果是非常好的，但是有一定的损失（600Kbps，约等于 75KB/s）

liuzhuan23

总体来讲，要对父类的rate设置一个合理值，大概接近物理带宽即可，父类就不要再去设置ceil了，父类是不可能借用带宽的

举例来讲，我有如下设计：

tc qdisc add dev imq0 root handle 1: htb default 255

tc class add dev imq0 parent 1: classid 1:1 htb rate 100kbps ceil 120kbps

tc class add dev imq0 parent 1:1 classid 1:10 htb rate 50kbps ceil 80kbps prio 1
tc qdisc add dev imq0 parent 1:10 handle 10: sfq perturb 5

tc class add dev imq0 parent 1:1 classid 1:255 htb rate 20kbps ceil 30kbps prio 2
tc qdisc add dev imq0 parent 1:255 handle 255: sfq perturb 5

我希望 classid 1:10 借用30k，到达80k，classid 1:255 借用10k，到达30k

当 classid 1:10 单独跑的时候，平稳80k

当 classid 1:255 单独跑的时候，平稳19k-28k

当 classid 1:10 与 classid 1:255 同时跑的时候，80k+30k=110k，超出父类的rate值，但我希望可以从父类的ceil借到10k，以保持2者的速率，但结果并不是这样的；

classid 1:255 被保持在自身的rate值范围内，而 classid 1:10 的 prio 1 保证了 classid 1:10 先出队（也即 classid 1:10 可以优先占用，借用带宽），在这里，体现出父类的借用带宽是无效的；

可以这么讲：

1。（子类的rate之和 > 父类rate），或者 （子类的ceil之和 > 父类rate ）这种设计是无效的

2。如果每个子类都到达了ceil的峰值，并且这个峰值之和超出了父类的rate，此时，低优先级子类的带宽被压榨，被保持在他们的rate值范围之内，高优先级子类则可以正常的向父类借用带宽，以保证 子类的ceil之和 <= 父类rate

所以，结果是：classid 1:10 80k左右，classid 1:255 11k-20k之间

yuio654

又学到了不少东西，呵呵

ssmarine

看前辈之间讨论就是爽，MARK一下。

iamshiyu

原帖由 platinum 于 2007-7-2 13:08 发表于 34楼  

不，你错了，我想的并不多，这是网络里一个很普遍的现象
当你使用 P2P 软件时，会招惹来外网流量的主动推送，从而堵塞你的 ISP 链路

按照lartc里的介绍：
然而，Internet主要依靠TCP/IP，它的一些特性很有用。因为TCP/IP没办法知道两个主机之间的网络容量，所以它会试图越来越快地发送数据(所谓的“慢起技术”) ，当因为网络容量不够而开始丢失数据时，再放慢速度。实际情况要比这种方法更聪明……
这个推送应该能够在一段时间后达到稳定值啊……即便它们到达了你的接受端interface，但由于发送端还是会drop掉，认证机制还是会认为这次传输失败了，然后慢慢减速回到稳定状态吧？