深入分析QOS带宽控制，如何用好QOS的方法

Tomato是我非常喜欢的路由软件，基于嵌入式Linux系统，硬件平台性价比高，TC、IPTABLES、DNSMASQ等传统功能本身就很强大，又有众多MOD，从原版发展到现在，不断地完善发展。我看到有很多用户抱怨QOS无法很好工作的问题，因此我觉得我需要写以下这些内容来引导大家：

一、上网卡是什么原因造成的？

简单来说，卡是因为带宽不足导致的，当我们的上传或下载超出了营运商设定的速率后，数据包会进入营运商网关的队列，这时会发生延迟，当数据超出了队列容量，就会发生丢包。游戏、语音等即时应用，延迟能感觉到，一旦出现丢包，游戏、语音、网页等会因为丢包而发生卡顿。无论是上传或下载的瞬间满载，都会造成延迟或丢包。

二、我们能精确控制上传，不能精确控制下载

由于数据在发送之前进入了路由器，所以我们可以通过路由器的QOS来精确控制上传队列，确保重要应用的上传延迟和丢包，但我们不是黑客，不能控制营运商对我们发出数据包，所以下载是不可直接控制的，在QOS里，对下载的控制，也仅仅是在数据到达路由器后按约定速率转发给客户端，路由器不能对营运商发送队列进行直接控制。一句话：上传的延迟和丢包是绝对可控的。

三、通过上传控制下载

既然上传可控，下载不可控，而下载的瞬间满载又会带来延迟和丢包，那怎么办？好吧，其实大部分情况下我们是客户端，而下载的数据其实是我们请求回来的，据观察，大部分请求数据的包最小为40Byte，平均大小为70Byte，而返回的包，最大不超过MTU设置的1450Byte，平均大小约1000Byte，换算起来，10Kbps的上传，能够获取150Kbps的下载，为了不让下载满载，我们可以通过调整一些应用的上传带宽来达到目的。举个例子：ADSL 4M/512K，你设置10KB的最高上传，游戏设置为最高级，那你瞬间的下载最高能到达10240B/40B*1450B=37120KB，你怎么都不会卡！当然这样会极度浪费上传带宽了。

四、让QOS有效运作，最重要是正确设置“上传带宽”

到这里，思路已经有了，为了让QOS运作起来，最重要就是确定上传带宽，这可不是营运商告诉你的512Kbps……因为满载的上传，你会获得超过1000ms的延迟，哪怕你优先给你的游戏数据进行发送，那你游戏里也会卡到死。那该如何设置？首先设置好上传带宽（ADSL一般是45K-50K），在QOS里把ICMP设置为最高优先级，一直PING着你的网关或DNS，然后到测速网站speedtest.net测速，在上传测试的时候，能够让PING保持非常低延迟，而上传又达到最高的吞吐率，这个就是能让你QOS系统生效的上传带宽设置了，一句话：QOS上传带宽是极低延迟下的最高上传吞吐率。

五、很关键的分级系统

TOMATO里的上传控制是基于HTB队列树的，简单来说，只要上传带宽设置正确，各级别队列在不超出该级别保留带宽的情况下，都可以无延迟发送出去。原则上，通过IP、端口来判断应用，对双向数据量少的低延迟应用给予最高级（例如：DNS请求、游戏数据），对会产生下载瞬间满载的应用，控制其上传带宽（例如：HTTP、FTP、P2P）。但很可惜的是，目前TOMATO的HTB树无法满足要求，要么把整个QOS上传设置到很低，否则下载的突发传输就无法解决，还会这就是为什么很多人还会卡的原因！不卡的，大多是把上传设定得很小，或者自己另写脚本解决。

六、下载带宽控制是否管用？

既然下载本身不能控制，那限制下载是否有用？有点用，很简单，数据请求一般是连续性，过程是“发送-》接收-》发送-》接收”不断循环，所以一般情况下，下载也会一定程度影响上传，会避免持续的满载，但假如下载超出了队列被丢弃，又得重传，这就会造成带宽浪费，我认为比较好的办法是加大下载转发队列的长度，允许更大的延迟，更小的丢包来达到目的，最好还能通过HTB树来确保高优先级数据的优先转发。但由于目前DualWan（其实是绝大多数路由系统）的QOS设计并没有考虑到这部分，所以还得靠自己写脚本来加以控制。http://www.luyouqiwang.com/15394/ 

对目前DualWan的QOS，我有一些自己的个人看法，最优化跟通用性是矛盾的，但我希望能对大家提供一些思路：

一、QOS本身没有计算路由器数据

据我所观察，QOS本身通过虚拟IMQ设备来统计FORWARD的传出数据，但对于路由器本身的OUTPUT数据并不计算，这部分的数据很明显有一部分要走WAN流量的，例如：远程管理、DNS解释请求、VPN的流量等，我自己是通过脚本来处理此问题的。

二、小包优先，是否可取

如果没有较为精确的分级系统，小包优先其实是会破坏QOS系统的，一个P2P视频软件，会瞬间发送500pps的小包（80Byte左右），请求回来500pps的大包（1000Byte左右），这些未分级的小包假如进入高优先级队列，瞬间的上传是40KBps、下载是500KBps，极容易出现下载满载导致卡机。最好还是通过地址和端口来进行分类，而不使用小包优先。

三、目前的QOS缺陷

HTB队列树设计可以改进，其实我们最需要限制的，是一些上传小包产生下载大包的应用，例如WEB、P2P等，通过换算来限制它们的最高上传带宽，避免下载瞬间满载，目前只能通过脚本做；另外下载的队列也需要自行设计。TOMATO内核并没有提供象RouterOS的PCQ队列（相当于全自动IP限速），这个在1.28 DualWan的SmartQos里有这样的初步设计，后来12.x就没了，是个开发思路。 

（作者：ICE-WR 面王帝国）