分享一个不到60行但是非常智能的QoS脚本

easyteacher

1. # mark_BULK_DL start
   
2. iptables -t mangle -A mark_BULK_DL -m hashlimit --hashlimit-name BULK_TRAFFIC_DL --hashlimit-mode srcip,srcport,dstip --hashlimit-above ${SPEED_THRESHOLD}kb/second --hashlimit-burst 200k --hashlimit-htable-max 1000000 --hashlimit-htable-expire 10000 --hashlimit-htable-gcinterval 10000 -j DSCP --set-dscp-class cs1
   
3. iptables -t mangle -A mark_BULK_DL -m hashlimit --hashlimit-name BULK_TRAFFIC_DL_PKT --hashlimit-mode srcip,srcport,dstip --hashlimit-above 300/second --hashlimit-burst 30 --hashlimit-htable-max 1000000 --hashlimit-htable-expire 10000 --hashlimit-htable-gcinterval 10000 -j DSCP --set-dscp-class cs1
   
4. # mark_BULK_DL end

复制代码

低带宽环境下可以把THRESHOLD调低，因为有hashlimit-burst的存在，所以正常浏览网页的流量不会被打上CS1标签。
只有加载大的图片、看视频或者下载的流量，burst的令牌用完了，才会被打上CS1标签。

wulishui

easyteacher 发表于 2020-4-6 16:48
调整upto的大小可破，我自己已经限速体验过了，上1下2的时候THRESHOLD调成3效果还可以，正常浏览网页和BT ...

今晚试试看

easyteacher

wulishui 发表于 2020-4-6 17:27
今晚试试看

记得下新的脚本

wulishui

easyteacher 发表于 2020-4-6 17:34
记得下新的脚本

我收拾收拾了下，你看是我的简单效果好还是你的那么复杂效果好。
我这不需要设置iface，自动获取。那些代码哪里来的我都忘了。
limit的通通不要了，因为是累积过程，不能反映瞬态。
cake分为4类总觉得不够，至少得5类。但是却只能3、4、8，4太少8又太多，真特么蛋疼，而且官方文档只字未题8分类该怎么打标，难怪没什么人用。


---------------另外致新手，千万不能这样拿去直接使用，当WAN口状态改变过后是会直接断网的--------------------

沉没的我们

楼上的怎么不是是石像鬼，现在K2这些都有官方的版本石像鬼了，

easyteacher

wulishui 发表于 2020-4-7 14:33
我收拾收拾了下，你看是我的简单效果好还是你的那么复杂效果好。
我这不需要设置iface，自动获取。那些 ...

试了一下，针对BT这种端口都在1024以上的效果确实不错。

1. iptables -t mangle -A cowbqos -p tcp --sport 1024:65535 --dport 1024:65535 -j DSCP --set-dscp-class cs1
   
2. iptables -t mangle -A cowbqos -p udp --sport 1024:65535 --dport 1024:65535 -j DSCP --set-dscp-class cs1

复制代码

这块切的有点狠，游戏、语音通话之类的流量都打cs1了。

1. # iptables -t mangle -A cowbqos -p tcp -m multiport --ports 80,443 -m length --length :256 -j DSCP --set-dscp-class cs6
   
2. # iptables -t mangle -A cowbqos -p udp -m multiport --ports 80,443 -m length --length :256 -j DSCP --set-dscp-class cs6

复制代码

这里设置小包优先的话，可能会把一些视频软件的p2p的流量也包含进去。这里可以加一个发包速度限制，或者用改进的mark_FAST规则把起步流量与大流量隔离开来

1. # mark_FAST start
   
2. iptables -t mangle -A mark_FAST -m hashlimit --hashlimit-name FAST_TRAFFIC --hashlimit-mode srcip,srcport,dstip,dstport --hashlimit-upto 1kb/second --hashlimit-burst 40k --hashlimit-htable-max 1000000 --hashlimit-htable-expire 10000 --hashlimit-htable-gcinterval 10000 -j DSCP --set-dscp-class af31
   
3. # mark_FAST end

复制代码

用ifb的话下行流量cake没法分类，因为流量是先经过ingress，再经过iptables规则处理。

easyteacher

easyteacher 发表于 2020-4-7 16:38
试了一下，针对BT这种端口都在1024以上的效果确实不错。

继续更新mark_FAST判断规则，增加只有80,443端口的流量才用mark_FAST判断。

wulishui

沉没的我们 发表于 2020-4-7 15:01
楼上的怎么不是是石像鬼，现在K2这些都有官方的版本石像鬼了，

我倒是想试试，但是石像鬼使用imq，现在op直接不支持imq，强行使用也不知后果，要是直接能用，imq就简单很多了。

wulishui

easyteacher 发表于 2020-4-7 16:38
试了一下，针对BT这种端口都在1024以上的效果确实不错。

实际上这个ingress是从sqm里拿来的。
端口控制则是从qos拿来的。这是他们俩的杂交版。下面两张图分别为上行和下行，是可以分类的。

wulishui

easyteacher 发表于 2020-4-7 16:53
继续更新mark_FAST判断规则，增加只有80,443端口的流量才用mark_FAST判断。

这就是一直困扰我的问题，有些app视频直接伪装成http，而且都是小包，没法区分，恨得牙痒痒的。开源的L7又已经归西多年，没得玩。现在很想把微信的语音视频通话能优先上来，但是它端口是随机的，根本没法搞。

wulishui

easyteacher 发表于 2020-4-7 16:38
试了一下，针对BT这种端口都在1024以上的效果确实不错。

你的做法是把它jump出来处理再return回去，造成整个mangle表都是jump来jump去的链，太恐怖了。实际上直接插到需要处理的规则之前就行了，效果一样。我再试试你说的，80，443判断累积流量，小的，大的区分开。同样，1024-65535端口也这样处理。

wulishui

easyteacher 发表于 2020-4-7 16:38
试了一下，针对BT这种端口都在1024以上的效果确实不错。

iptables -t mangle -A cowbqos -p tcp -m connlimit --connlimit-above 100 -j DSCP --set-dscp-class cs1
iptables -t mangle -A cowbqos -m tos --tos Minimize-Delay -j DSCP --set-dscp-class cs6
iptables -t mangle -A cowbqos -p tcp -m multiport --ports 21,22,53 -j DSCP --set-dscp-class cs6
iptables -t mangle -A cowbqos -p udp -m multiport --ports 21,22,53 -j DSCP --set-dscp-class cs6
iptables -t mangle -A cowbqos -p tcp -m multiport --ports 80,443 -m hashlimit --hashlimit-name FAST_TRAFFIC --hashlimit-mode srcip,dstip --hashlimit-upto 1kb/second --hashlimit-burst 40k --hashlimit-htable-max 1000000 --hashlimit-htable-expire 10000 --hashlimit-htable-gcinterval 10000 -j DSCP --set-dscp-class cs6
iptables -t mangle -A cowbqos -p udp -m multiport --ports 80,443 -m hashlimit --hashlimit-name FAST_TRAFFIC --hashlimit-mode srcip,dstip --hashlimit-upto 1kb/second --hashlimit-burst 40k --hashlimit-htable-max 1000000 --hashlimit-htable-expire 10000 --hashlimit-htable-gcinterval 10000 -j DSCP --set-dscp-class cs6
iptables -t mangle -A cowbqos -p tcp -m multiport --ports 80,443 -j DSCP --set-dscp-class af31
iptables -t mangle -A cowbqos -p udp -m multiport --ports 80,443 -j DSCP --set-dscp-class af31
iptables -t mangle -A cowbqos -p tcp -m multiport --ports 20,25,110,143,465,587,993,995,1194 -j DSCP --set-dscp-class af31
iptables -t mangle -A cowbqos -m hashlimit --hashlimit-name FAST_TRAFFIC --hashlimit-mode srcip,dstip --hashlimit-upto 1kb/second --hashlimit-burst 40k --hashlimit-htable-max 1000000 --hashlimit-htable-expire 10000 --hashlimit-htable-gcinterval 10000 -j DSCP --set-dscp-class af31
iptables -t mangle -A cowbqos -p tcp --sport 1024:65535 --dport 1024:65535 -j DSCP --set-dscp-class cs1
iptables -t mangle -A cowbqos -p udp --sport 1024:65535 --dport 1024:65535 -j DSCP --set-dscp-class cs1


这样来试试。不用jump出来的，直接插在前面就ok啦cs值这样不算合理，只是试验能不能分类，所以说4类是不够的，8类又太多。

dato

讨论了这么多天，真是走向深渊，迷途不知返。

在没有cake之前，测试SQM一遍，这次测试导致再也对SQM提不起兴趣，当然有人说被我这个评测误导了SQM cake的效果。那时候cake还没生出来。就这帖的讨论，看来除了开发者，普通用户是洞察不到cake的神秘，无法用tc的流量分组来理解cake。

openwrt SQM
https://www.right.com.cn/forum/thread-164281-1-1.html

1,openwrt不具备DSCP标记，无法精确分类命中，当然讨论中已经产生这种蹩脚的标记
2,带宽无故损耗，早就认识到根本无需做一个20%的预留。关键即便不预留，SQM也自动预留了根本没修改的机会
3,不具备connmark结构，导致每包CPU命中路由负载非常高，动不动就建议用户去买更好的硬件
4,fq_codel在游戏中有飘移，掉帧的明显感觉?

新手建议还是从tomato /etc/qos学起
1,拥有真正的小包arp/icmp/ack/syn/fin/rst tc u32匹配器，可不是ros概念里的iptables length
2,prio优先级控制
3,精确的流量控制
4,高效的connmakr，包标记到连接标记，减少对cpu性能的消耗
5,因为有了connmark第一次发现原来上行标记同样会作用于下行标记，这说上行的标记就能同时作用于上/下两个方向

我的tomato 原版QOS 设定
https://www.right.com.cn/forum/thread-102891-1-1.html
建立了一个60/80的模型说明

6,ifb解决了以前每个vlan都要建立一套针对特定接口的qos规则，目前用的三层交换静态路由也用不着ifb。
7,脚本的魅力，终有一天会创造出自己的一套动态QOS

openwrt下面的qos-scripts也是比较接近tomato qos，可惜用了一个资料更少的hfsc算法。相对于SQM能更精确的控制流量。看起来SQM仍然没有像传说中的可以普遍保持大流量/低延迟。不然也不会搞得这么麻烦，设置了N多规则仍然没效果。。。

至于并发抑制，一般是针对并发数少的线路。真正的QOS是不会用这种方式的。

easyteacher

wulishui 发表于 2020-4-7 17:50
你的做法是把它jump出来处理再return回去，造成整个mangle表都是jump来jump去的链，太恐怖了。实际上直接 ...

jump来回是为了规则好看一点，几个jump性能影响也没那么大

easyteacher

dato 发表于 2020-4-7 22:23
讨论了这么多天，真是走向深渊，迷途不知返。

在没有cake之前，测试SQM一遍，这次测试导致再也对SQM提不 ...

• fq_codel确实会造成游戏里面移动漂移，换成cake就好了。
• 用connmark给连接中所有的包打标，容易造成误杀，没有太好的办法。
• mt7628的配置，跑30Mbps差不多占用70%的CPU，对网速要求不太高的环境下已经很够用了，网速高了的话QoS作用也没那么大了。
• 我的想法是不以端口号作为判断依据（80,443除外），实现大流量和游戏流量的区分。端口号是最容易造成误判的。
  

二楼更新了一下效果对比