我的tomato 原版QOS 设定

da***

1，这是基于远端网络服务端口访问优先级的QOS。这也是偶目前测试过最最最适合多人环境的QOS设定。
它的优点肯定能保证Highest组游戏延迟，在网络繁忙的情况下想保证命中率比如CS感觉还是有点差距(或者可能老了CS水平越来越菜了，同伴都说你整天就会在那叫，就是打不死人，是啊每天一到晚上就打不死人了。。。) 为什么看了下面就知道了。
保证相应服务优先极调度，由于tc的sfq随机公平原则的实现似乎再怎么卡网络也能保证通畅。
每个人都有机会享受100%的下行流量。
你可以同时pps和cs。

不需要设置那么复杂的调度4个分类就足够了。其中_30这组主要针对QQ和MSN的，但是这些端口也适合很多的聊天软件。

tcp_5060,6060_10
udp_5060,6060,27015:27018,27050,27060,27070,27080_10
tcp_53,22,23,123,3389,8123_20
udp_53_20
tcp_80,443,1080,1863,8080,12000,14000_30
udp_4000:4030,8000:8001_30
tcp_20,21,25,1024:65535_40
udp_1024:65535_40

它将以游戏端口udp27080为Highest。                   80%-100% 不要将会产生大量流量的端口划到这组。一般CS上行就5KB/s
dns查询udp53为High                                             70%-100%
From `nvram get wan_ipaddr`为High                    70%-100% 用来解决直接在路由上提供的WEB服务器或者FTP之类的下载（你可能不喜欢它为High调低点吧）                     
web浏览tcp80Medium                                             5%-80%
其它不确定的高端口1024:65535全设定为Low        3%-60%

请注意设定好你的 最大上行带宽 偶这20M的烂光纤1000kbit/s/8 125kb，普通的ADSL应该是520kbit/s/8 65kb左右。这些值一定要根据你实际的上行设定。

http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
TT用的是
2. Link sharing 模型，这个模型很容易导致流量相互覆盖，这也是为什么很多人认为TT QOS不行，其实TT的QOS至少从目前保证游戏延迟方面肯定没任何问题。你所要做的就是精确划分分类流量以及注意分类流量总和而引起的流量覆盖问题。
这是什么意思呢？
我的流量划分原则依然根据60/80原则，上行流量的60%值保证低延迟响应，80%保证流量和延迟的平衡，再高就有点难以忍受了。假如现在同时运行pps和快播，基本上pps占用了Low级，快播有时候看它蛮喜欢连远端tcp8080端口的，那么在某种极端条件下就可能导致60%+80%远远超过你实际可以使用的100%，很多东西并不像书面上写的prio优先级那么简单，并发数量比例也是个很大的影响因素，结果最后发现高优先级的游戏端口还是被p2p流量给淹没了。所以要想办法抑制这种情况的发生。
3. Sharing hierarchy模型，它通过添加一个1:2的分类可以让Medium+Low级之间分类流量互相借用，而且再怎么极端也在80%徘徊。它可以保证高优先级的流量不会被Media+Low流量覆盖。在这个模型极端情况下，你会发现在Highest组的ping延迟在20以内，而在Low组在流量饱合时ping可能接近600ms以上，所以我们只要附加一个简单的脚本通过在service wan restart 时通过修改默认的/etc/qos设置来改变这个设定。
root@Da:/tmp# cat script_wanup.sh
#!/bin/sh
sed '12 a\
$TCA parent 1:1 classid 1:2 htb rate 800kbit ceil 800kbit' -i /etc/qos #注意替换800kbit的值请根据你的实际上行流量1:30处的ceil值来修改
sed -i '23 s/1:1/1:2/' /etc/qos
sed -i '27 s/1:1/1:2/' /etc/qos
/etc/qos stop;/etc/qos start

下面的是原先的2. Link sharing 模型，根据上面的脚本在12后面插入一行，更改23 27处的1:1为1:2就完成了设定。
root@Da:/tmp/etc# cat qos
1 #!/bin/sh
2 I=vlan2
3 TQA="tc qdisc add dev $I"
4 TCA="tc class add dev $I"
5 TFA="tc filter add dev $I"
6 Q="sfq perturb 10"
7
8 case "$1" in
9 start)
10        tc qdisc del dev $I root 2>/dev/null
11        $TQA root handle 1: htb default 40 r2q 10
12        $TCA parent 1: classid 1:1 htb rate 1000kbit ceil 1000kbit
            $TCA parent 1:1 classid 1:2 htb rate 800kbit ceil 800kbit
13 # egress 0: 80-100%
14        $TCA parent 1:1 classid 1:10 htb rate 800kbit ceil 1000kbit   prio 1 quantum 1500
15        $TQA parent 1:10 handle 10: $Q
16        $TFA parent 1: prio 10 protocol ip handle 1 fw flowid 1:10
17 # egress 1: 70-100%
18        $TCA parent 1:1 classid 1:20 htb rate 700kbit ceil 1000kbit   prio 2 quantum 1500
19        $TQA parent 1:20 handle 20: $Q
20        $TFA parent 1: prio 20 protocol ip handle 2 fw flowid 1:20
21 # egress 2: 5-80%
22(23) $TCA parent 1:1 classid 1:30 htb rate 50kbit ceil 800kbit   prio 3 quantum 1500
23        $TQA parent 1:30 handle 30: $Q
24        $TFA parent 1: prio 30 protocol ip handle 3 fw flowid 1:30
25 # egress 3: 3-60%
26(27) $TCA parent 1:1 classid 1:40 htb rate 30kbit ceil 600kbit   prio 4 quantum 1500
27        $TQA parent 1:40 handle 40: $Q
28        $TFA parent 1: prio 40 protocol ip handle 4 fw flowid 1:40
:
:
:
esac

它的缺点，并没有像传说中的磊科QOS那么神奇。偶看过论坛一些朋友提供的磊科QOS的效果截图，偶自己也用h218N刷过磊科的235w 236w偶也telnet进入看过它们的一些设定，说实在的磊科的QOS根本没传说中的那么夸张。当然人家提供截图能证明磊科的可以全速下行低流量上行，偶就至今想不出问题在哪。可能用了一个被电信动了手脚的hg266，本身可能存在并发数量的问题。可能20M所谓的光纤却只有135kb/s的上行。但是以我对tc的理解，磊科的QOS设定一点也不简单，关键设定了以后效果还不怎么样。。。真的不怎么样。
20M家用光纤上行135KB/s ，迅雷 下载优先模式 时，CS端口优先游戏延迟，看右下方那条平稳的绿色线。好久没用ADSL，不知道ADSL是否也有此效果。
具体有关跟磊科对比可以看这里的讨论。https://right.com.cn/forum/thread-120964-2-1.html


其它可能用得着的东西
nvram set qos_orules主要是因为偶需要根据wan端口ip变化来设定，所以里面有个变量nvram get wan_ipaddr
nvram set qos_orules="0<<17<d<5060,6060,27015:27018,27050,27060,27070,27080<0<<<<0<udp_10>0<<6<d<5060,6060<0<<<<0<tcp_10>0<<17<d<53<0<<<<1<udp_20>0<<6<d<53,22,23,123,3389,8123<0<<<<1<tcp_20>2<`nvram get wan_ipaddr`<-1<a<<0<<<<1<L_S>0<<17<d<4000:4030,8000:8001<0<<<<2<udp_30>0<<6<d<80,443,1080,1863,8080,12000,14000<0<<<<2<tcp_30>0<<17<d<1024:65535<0<<<<3<udp_40>0<<6<d<20,21,25,1024:65535<0<<<<3<tcp_40"


*2017年01月11日星期三
- 今天有朋友问到如何动态进行流量变换，其实这些东西通过shell脚本进行逻辑处理是非常简单的。
由于手头没有tomato路由系统，我下面只是简单告诉大家如何实现，具体还得靠自己动手。
tomato的qos的相关规则都保存在nvram设定里，所以大家只要在web管理界面设定好不同的流量规则，然后通过nvram show|grep qos 就可以看到规则变化。
#建立流量变化脚本changerate.sh 在路径/tmp下面，注意这里只是演示方便，/tmp目录会重启消失的，最好得懂电脑的相对路径绝对路径吧。
vi /tmp/changerate.sh
#给予可执行权限
chmod +x /tmp/changerate.sh

#/tmp/changerate.sh文件内容 每天的6点或者18点的25分或者50分执行流量变化
25,50 6,18 * * * /tmp/changerate.sh

#简单的演示通过时间变化来改变流量规则，下面的脚本应该是错的，应该还少一个关于总带宽的qos_设定，具体是多少请自己通过nvram show|grep qos来查看
nvram get qos_orules 查看参数
nvram set qos_rules="xx" 设定参数
nvram commit 保存参数

#!/bin/sh
if [ $(date +"%H%M") = 0650 ];then
nvram set qos_orules="0<<17<d<5060,6060,27015:27018,27050,27060,27070,27080<0<<<<0<udp_10>0<<6<d<5060,6060<0<<<<0<tcp_10>0<<17<d<53<0<<<<1<udp_20>0<<6<d<53,22,23,123,3389,8123<0<<<<1<tcp_20>2<`nvram get wan_ipaddr`<-1<a<<0<<<<1<L_S>0<<17<d<4000:4030,8000:8001<0<<<<2<udp_30>0<<6<d<80,443,1080,1863,8080,12000,14000<0<<<<2<tcp_30>0<<17<d<1024:65535<0<<<<3<udp_40>0<<6<d<20,21,25,1024:65535<0<<<<3<tcp_40"
sed '17 a\
$TCA parent 1:1 classid 1:2 htb rate 392kbit ceil 392kbit' -i /etc/qos
sed -i '27 s/1:1/1:2/' /etc/qos
sed -i '31 s/1:1/1:2/' /etc/qos
/etc/qos stop;/etc/qos start

elif [ $(date +"%H%M") = 1825 ];then
nvram set qos_orules="0<<17<d<5060,6060,27015:27018,27050,27060,27070,27080<0<<<<0<udp_10>0<<6<d<5060,6060<0<<<<0<tcp_10>0<<17<d<53<0<<<<1<udp_20>0<<6<d<53,22,23,123,3389,8123<0<<<<1<tcp_20>2<`nvram get wan_ipaddr`<-1<a<<0<<<<1<L_S>0<<17<d<4000:4030,8000:8001<0<<<<2<udp_30>0<<6<d<80,443,1080,1863,8080,12000,14000<0<<<<2<tcp_30>0<<17<d<1024:65535<0<<<<3<udp_40>0<<6<d<20,21,25,1024:65535<0<<<<3<tcp_40"
sed '17 a\
$TCA parent 1:1 classid 1:2 htb rate 3920kbit ceil 3920kbit' -i /etc/qos
sed -i '27 s/1:1/1:2/' /etc/qos
sed -i '31 s/1:1/1:2/' /etc/qos
/etc/qos stop;/etc/qos start

else echo err;fi

其它的tc class change命令演示，
#!/bin/sh
a=`grep ort=270 /proc/net/ip_conntrack`;b=`tc -s -d class show dev $UDEV | sed -n '16p' | awk 'BEGIN{ORS=""}{ print $NF}'`
if [ -z "$a" ]; then if [ "$b" != "160000bit" ];then tc class change dev $UDEV parent 1:1 classid 1:20 hfsc sc rate 6kbps ul rate 20kbps;echo "`(date +"%m/%d/%Y %T")` change rate 20kbps successfully_" >> /tmp/log;fi
else if [ "$b" != "64000bit" ];then tc class change dev $UDEV parent 1:1 classid 1:20 hfsc sc rate 6kbps ul rate 8kbps;echo "`(date +"%m/%d/%Y %T")` change rate 8kbps successfully_" >> /tmp/log;fi;fi

*2015年7月7日星期二
- 今天顺便更新一下，主要是前段时间在routeros下观察到的一些流量溢出情况
- QOS这东西越来越觉得难调试了，不同的网络可能有差异。
早些年，对付迅雷一个上行优先级就ok了。可是今年却很难让迅雷和游戏在一根4mbps的线路上共存。迅雷的并发可以直接让家用光纤崩溃，只有一个办法抑制迅雷向外发包的速率才能保证游戏延迟。
原先以为已经解决了 QQ旋风和游戏的共存，可是在下载这几个特殊的链接时才在routeros下面观察到竟然会出现流量严重超出max limit的限制，真不知道这几个dotnetfx链接有什么特别，把文件放在自己vps上又是正常的。现在局端大量应用了缓存设备，都不知道为什么同样的设定在两地的电信线路竟然有那么大的差别。
当然流量是关键，线路越宽qos异常的情况越小。
http:/ /dl.softmgr.qq.com/original/Drivers/dotnetfx35_3.5.exe
http:/ /dl.softmgr.qq.com/original/Drivers/dotnetfx45_full_x86_x64.exe
http:/ /download.microsoft.com/download/b/a/4/ba4a7e71-2906-4b2d-a0e1-80cf16844f5f/dotnetfx45_full_x86_x64.exe

http:/ /dl.softmgr.qq.com/original/Drivers/CUBE_U9GT4_1.03_20121130.zip


*2015年6月4日星期四
- 这根4mbps的光纤按以前的设置依然无法和qq旋风和迅雷极速模式共存，表现为高优先级的延迟在180-300ms左右，非常得高
- 在2012年写这文档时，虽然有人提到迅雷喜欢连80端口，但那时都是udp80，所以感觉以前的设置也没什么问题。
- 前段时间为了解决在openwrt下面，qq旋风导致的延迟问题，主要还是通过对总流量进行80-90%比例的控制， 可以把延迟控制在30ms左右。但这基本是以带宽换延迟了。
- 今天仅仅是设置QoS/Basic  Settings/Inbound Rates/Limits Highest 20%-100% Medium 80-95% 结果使用imq0队列以后qq旋风下载时，高优先级的延迟掉到13ms左右，非常平稳。

- 但是按上面的设置依然无法解决迅雷的问题，通过tcpview查看迅雷确实发起了很多tcp 80的连接，怪就怪在如果通过tt的界面显示，不管是上行还是下行都有非常多的剩余流量空间，可是高优先级的延迟依然高达180-300ms左右，通过cat /proc/net/nf_conntrack|wc -l查看，单机使用QQ旋风时并发数量在300以下，而用迅雷时刷的500以上最高接近1200。现在没有其它企业网络环境无法验证，我总觉得不是qos设置上的问题，可能是电信上面有并发限制，无从验证，但今天至少解决了qq旋风。
- 使用了iptables limit对不同端口启用reject丢弃，延迟开始回落。太小看迅雷的并发了，平时用迅雷都是用后就删的，没想到破坏力如此巨大，解决的办法也许只有通过对特定ip并发数进行限制。但是由于这种方法在 原版QOS 里并没有可以设置的地方，所以无从讨论。


*2015年6月3日星期三
- 今天重新对这个qos设置进行了测试。 非常得令人失望。
- 我注意到有部分朋友关注了一下这帖，然后就转投其它帖子，我只能自己去重新测试看到底怎么回事。
- 原先的测试环境是上海电信20mbps光纤，有135kb/s上行，而且这帖子留有一张当时跟磊科的讨论图片，就是那张显示玩counter-strike 1.6时的延迟图片，这张图片里显示的ping延迟优先级是仅次于highest又高于high的，很平稳甚至没超过50ms。顶部显示在用迅雷极速模式时下载速度在2.63mb/s，底部的绿色条纹都能很准确的反应出qos是有效果的，而且连带tt里显示的上行都很好的充满了80%的上行带宽。没错看起来很有效。
可是今天在温州电信4mbps光纤，应该有500-540kb/s下行，100-140kb/s上行，设备还是那个h218n由它负责pppoe拔号，除了两跟线路速率不一样，光纤猫不一样20mbps光纤前面用的蜂火hg266，现在4mbps光纤用的ZXHN F660，用的是有线环境，用迅雷极速模式时甚至只有500kb/s不到的速度。上行更不用说看tt内部显示连50kb/s都没。也就是上下行都还有一定的剩余带宽，可是高优先级的延迟竟然夸张到300ms左右。而且连带网页都很难打开，有明显的延迟。我不清楚为什么，因为这个结果基本把这帖所有的结论都推翻了。崩溃，不多想了，以后不再说这个QOS有多NB了。。。。

- 其实真的是这个qos失效了吗?
根据最近在4mbps线路上实施的一些经验。QOS导致的延迟是双向的，上行因为拥塞导致延迟，下行过堵同样也会有该问题。问题当然是多种多样的，比如这4mbps线路从speedtest.net测得的速度是570kb/s，而web单线程下载实际稳定在540kb/s，而今天反复下载一个资源竟然只有480kb-500kb之间的波动。假如你有两台电脑，一台迅雷，一台玩游戏。通过对迅雷的电脑做基于ip的下行限制腾出一定的下行流量（20kb）给游戏的电脑，那延迟应该还是有保障的。至于单机按目前的测试情况是没办法达成的。也不知道以前的那截图怎么回事。。。  带宽和延迟的关系都是可以计算出来的，按说应该不至于有如此差距的，难道是因为设备有并发限制吗?不知道如何测试。


*2013年2月25日星期一
路由更新了Tomato Firmware 1.28.0000 MIPSR1-106 K26 MiniIPv6,原有的shibby tomato QOS脚本位置有点变化
sed '17 a\
$TCA parent 1:1 classid 1:2 htb rate 392kbit ceil 392kbit' -i /etc/qos
sed -i '27 s/1:1/1:2/' /etc/qos
sed -i '31 s/1:1/1:2/' /etc/qos
/etc/qos stop;/etc/qos start

* 2013年02月24日星期日
-按照这篇文档的设定的话。因为默认的优先权设定为low，在网络极端拥挤的情况下，那么low组的延迟很高，而且由于tcp握手问题也会同时影响到下行部分。 主要像qq远程桌面，语音之类的端口都在随机变化，对于这类应用就很头疼无从设定，当然如果你有经验的话可以针对IP采取优先权，但是这个也是无奈下的选择。

今天根据 http://www.polarcloud.com/tomato ... lain_how_the_qos_ru 的建议
QOS设置/基本设置/优先权默认为(等级)由low改为Medium
然后将udp_40,tcp_40组增加100kb+的累计传输。情景也就连接所有不确定的端口时当传输流量少于100kb时优先级为默认的Medium，一旦流量超过100kb那就降级为low。跟先前的那种设置，感觉能充分的使用1:2组的总的80%上行流量，而不像原先的可能有80%-60%的剩余。因为这个100kb+而导致的Medium到low的变化从快播的下行来看似乎优于原先的设定，但是不知道如何建立有效的测试方法。仅记录下今天的改动变化。


        udp dpts:1024:65535 connbytes 102400:4294967295 bytes direction both CONNMARK set-return 0xa00104/0xff
   83 36769 CONNMARK   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

        multiport dports 20,21,25,1024:65535 connbytes 102400:4294967295 bytes direction both CONNMARK set-return 0xb00104/0xff
523K  121M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0
        CONNMARK set-return 0xff00003


* 2013年9月29日星期一
- 增加20M家用光纤135KB上行时，迅雷 下载优先时 CS游戏延迟效果

* 2012年10月01日星期一
- 这次有点太早给ADSL线路下结论,用nw618 55kb/s总上行low组占55%延迟还可以接受，而且下行对延迟波动也非常的明显，似乎也只能控制在65%左右这样太浪费带宽了。所以"肯定能保证Highest组游戏延迟"的结论还是很有问题。也许该换上RTN16看看，是否CPU性能也有影响

* 2012年09月29日星期六
- 当时写这文档时实践部分其实是在一个dlink600 b2 ddwrt build 14311版本上实现的。当时线路是20M光纤上行有135kb/s左右
- 玩CS同一服务器网络空闲时延迟在6ms左右，网络繁忙时基本在24ms-30ms之间。也是很郁闷的感觉一到晚上就打不死人
- 回家终于有机会用家里的itv线路ADSL4M上行有55kb/s进行测试，一个nw618 cpu主频240MHZ tomato-K26-1.28.RT-MIPSR1-101-MiniIPv6.trx
玩CS同一服务器网络空闲 时延迟在27ms左右，在low全速占用时延迟在47ms之间。但是发现启用itv时悲剧发生了，延迟很难看。itv部分没办法只能使用内置的pppoe拔号，尝试使用DHCP结果发现很多频道都出现等待信号的问题。启用ITV时线路速率会变化的。而且基本在一个特定的值，最低的时候下行才125kb/s，最高的时候下行才200kb/s，显然这itv猜想可能局端有特殊的设备对itv pppoe拔号过程进行侦测并动态的对ADSL线路进行QOS调整，又或者这个home plusplus 500性能不行（手里没ADSL modem感觉也不大是它的问题）。偶没测在itv时上行变化情况。肯定比原有的55kb/s小很多，从tc的1:1 rate来看大概只有33KB左右了。此时发现CS的延迟已经600ms左右了，因为原有的55kb/s已经不适合在itv时的情况了，郁闷不知道如何对itv线路状态进行侦测，无法动态调整这个上行值。杯具啊。。。
- 试图在itv时限制总上行带宽值为33kb/s，结果使用web方式向QQ中转站上传东西，medium组占用了184.32kbit/s基本占用了上行组，但是CS延迟没变化。使用pps时延迟就到600ms以上了。以前用的20M光纤因为这样那样的问题，没大可能全速下行的。但是ADSL上的itv由于下行只有125kb/s左右，结果下行又再次对游戏延迟进行了影响。有机会测试一下光纤是否也有该问题存在。

* 2012年09月17日星期一
- 初始化文档

YG***

很认真说,但很复杂.....

hunt***

qos设置  学习

2827***

你好，我是联通6Ｍ的宽带　　 ”#注意替换800kbit的值请根据你的实际上行流量1:30处的ceil值来修改　“　这里需要什么修改？

da***

282782182 发表于 2012-9-18 11:10
你好，我是联通6Ｍ的宽带　　 ”#注意替换800kbit的值请根据你的实际上行流量1:30处的ceil值来修改　“　这 ...

因为不同的宽带上行不一样，所以一般情况你要在路由没启用QOS的情况，而且确定你电脑上没有p2p程序占用上行带宽，然后可以试试
http://www.speedtest.net
比如我看到的upload speed为0.44mbps 那么上行就是0.44*1024=450.56kbit/s 。由于不能填小数点。telnet 到路由里，这个值就相应的变成360kbit。
root@Da:/tmp/etc# cat qos|grep 1:30
        $TCA parent 1:1 classid 1:30 htb rate 22kbit ceil 360kbit   prio 3 quant
um 1500
        $TQA parent 1:30 handle 30: $Q
        $TFA parent 1: prio 30 protocol ip handle 3 fw flowid 1:30


可在这里换算kbps的结果就是你的总上行
http://www.zhongguosou.com/computer_question_tools/data_rate_caculator.html

chao***

看到你说原版，我就笑了。。。

huiro***

概念看了不是太懂
第3. Sharing hierarchy模型说的是流量整形么

da***

这里有篇中文版的，
http://www.360doc.com/content/07/0606/14/26398_541923.shtml
在这个例子里之所以更改这样的层次极别最主要的还是避免，Media+Low远远超过实际可以使用的100%，当然你也可以限制Media 20% Low %60这样总共也就80%还有浮动的20%用于高优先级的。但是就是因为这可怜的上行tcp连接问题，太少吗又导致缓冲问题，所以所以感觉还是增加个1:2好点，让它们自行借用，又不会超过80%的上限。

dm***

学习了，今晚我在DDWRT下试试效果。

dm***

DD下用脚本试了下，2M的ADSL，要保证延时比较小还得保留10%-20%的带宽，有点浪费了。

da***

ADSL是不可能全速上传的，全速上传的结果就会导致下行突降。65*.2 13KB根本没什么，很多时候更关心的是下行。也许把80比例改成70延迟更好点。

W_***

看了你发的图，发现tt原版的qos与cfosspeed的原理一致，都是通过把特定端口通过优先级分类来达到目的。因为我没有用过tt，不知道实际效果如何，cfosspeed在带宽达到上限的80-90%还是比较有效果的，不过具体延迟波动我不太记得了，当时我朋友用0.5m adsl满速下载时，延迟在1-100ms波动。我现在用的磊科的qos，设置也比较方便，在带宽达到上限的80%，单ip连接数限制为300，延迟波动在20ms内跳动。

其实，我在想，为什么不直接通过带宽使用率来划分优先级，游戏占用在1-10kb之内，网页在1-100k或者设为带宽的50%之内，其余的一律默认为最低优先级。这样设置起来明显方便的多

da***

偶只是根据以前人家的对流量和延迟的对比关系，做了一个60/80的实现说明。
真正的TT最初版本的作者使用的设定，如果不采取1:2组，则仍然会在极端情况下出现多线程用户和单线程用户对上行带宽的抢夺，最终可能远远超过适当的延迟比例80%甚至100%而导致延迟无效情况。
shiiby tomato对这个原版QOS的设定则像你提出的根据分类应用划定了特定的流量比例。因为QOS这块从原先的基于IP限速级到现在的基于端口访问应用优先实现。其实我也很确定1:10 1:20组的流量本身都很小的。这只是个应用的例子说明，很多TC文档都指出一点不应设计过于复杂的分类，是的看tc的向导文档就4个分类调度图解就已经复杂成那样，如果直接采用shiiby tomato的设定。偶在ADSL上试了试shiiby的设定游戏延迟有一定保障，可是pps之类的缓冲就很恐怖了。所以做了这么一个实现的操作步骤。这其实是对于iptables+tc的相互调用的实现，如果你经常写QOS脚本你就发现确实没必要根据软件来写一个分类，只要把必要的端口归在一起就可以了。所以我觉得这个模型已经是我能想到的最最简单的了。而为什么1:10 1:20还是有100%的流量比例，那是因为这只是个例子，有时候我更喜欢特殊的IP或者路由的web服务器下载可以全速，只是这些内容没在这个实现里出现而己。
另外一个可行的方法就是使用cron用shell脚本对游戏时的端口进行侦测再使用tc change来动态改变流量比例。

haox***

看起来很复杂

sn***

好文章。虽然老了点。但还是有用的。