时在使用上海电信2.6MB下行/135KB上行的带宽时，当时没设定了QOS的网络下载迅雷连 路由管理界面都打不开，而设定了QOS则可以正常打开web管理界面至今想不通为什么。
从我的思维我认为在135KB/s的上行都能设定的QOS规则它同样能适合大带宽。前几年在玩优酷路由宝时就注意到浙江电信至少针对 英雄联盟 这个游戏已经做了优先控制，在家里没有使用任何qos的情况，优酷路由宝基本全速上传，lol延迟依然极低，反而一个设定不当的QOS导致lol延迟更高。
在家里的网络设定了一个最简单的根据目的端口设定的qos，并不需要什么复杂的什么L7规则。
# cat /tmp/port.tmp
udp_6060_0x10/0xff
tcp_26241_0x10/0xff
udp_53_0x20/0xff
tcp_22,23,123,3389,8123_0x20/0xff
tcp_80,443,1080,1863,8080,12000,14000_0x30/0xff
udp_500,1701,4000:4030,8000:8001_0x30/0xff
tcp_20,21,25,1024:65535_0x40/0xff
udp_1:65535_0x40/0xff
在135KB/s的低上行场景。qos需要解决流量和延迟的对比关系。上面规则设定了更低延迟要求的voip 6060_0x10，常见的DNS查询 53_0x20，比较直观的网页浏览过程80,443_0x30，以及其它不可归类的p2p流量 1:65535_0x40。这个QOS可以实现0x10的最高优先级的voip获得最低的延迟，0x30的tcp浏览过程优先p2p流量，p2p流量自动避让高优先级流量。所以QOS在网络中可以优先保障高优先级流量，改变上行队列数据包排列顺序，再根据tcp握手特性改变下行的数据包排列递，你说QOS有没有用。这时候0x10的流量分组可以获得<19ms的延迟，而饱和的0x40分组可能接近600ms的延迟。在通过web方式上传文件时，p2p流量全速避让。如果你的网络没有qos，那么web流量跟p2p流量基本处于竞争关系很可能因为连接数的关系抢不过p2p流量。认为有大带宽不需要QOS只是环境没有那么苛刻罢了。如果公司给你1条10M专线，你说你能带多少设备。1台10台还是100台？tplink的很多企业级路由也说能带500ip，可是面对那种可怜的基于ip的限速规则，想带500ip估计得500mbps带宽。
一条计算延迟的计算公式，虽然一直不知道这条公式是否正确，但是它很好说明了流量和延迟的对比关系，延迟跟总带宽有关系，跟剩余带宽有关系。而linux的tc流量分组正可以通过这条公式的理解去解决流量和延迟的问题。
1500 [byte] * 8 [bits/byte] / 512 [kbits/sec] = 23.4375ms
楼主的环境有点夸张，目前用过的最好的企业专线也就20m下行/65m上行，声称能带50终端。从 cat /proc/net/nf_conntrack|wc -l 最高也就6000。并发数做为一种有效的抑制流量的方法，认为tcp连接在超过电信限制上限时会导致tcp连接无法正常握手，所以迅雷这种夸张的瞬间1200并发的软件可能在8M的电信宽带就导致网络异常了。路由也可以通过iptables limit对迅雷实施压制，让其它流量正常。当然随着现在带宽越来越宽，相应的并发也越来越高，能有100mbps上行的线路达到17000+的并发数量也不应该叫家庭宽带了吧。当然并发可能来源于电信的限速，也可能路由的相应优化配置没有设定好，或者干脆就是路由本身的cpu性能达不到大流量的qos要求。
qos当然有用，看你会不会用。公司里10M带宽带了40台pc 100个手机，上行使用简单的目的端口qos，下行实施动态限速。10M的小带宽虽然不一定能保证视频游览，让大家上上网页还是没任何问题的。linux下面的流量控制还是非常不错的，上行标记带到下行标记，通过ifb设备重新映射，用一套QOS规则作用于13个vlan接口。openwrt tomato之类的路由qos绝对不是摆设。
