这里，我们使用了随机公平队列（sfq），在消耗 CPU 周期较少的情况下，其性能还是可以接受的。其它一些队列规定可能更好，但要占用较多的 CPU 资源。令牌桶过滤器也经常使用。
下面还有一件事要作：告诉内核网络包和类的映射关系。
# tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip dst \
150.151.23.24 flowid 10:200
# tc filter add dev eth0 parent 10:0 protocol ip prio 25 u32 match ip dst \
150.151.0.0/16 flowid 10:100
这里，我们假定 Office 位于防火墙 150.151.23.24 的后面，其它 IP 地址都属于 ISP。 u32 匹配是一种比较简单的匹配，我们可以使用 netfilter
生成更加复杂的匹配规则。
我们已经分配了下载带宽，下面是上载带宽的分配：
# tc qdisc add dev eth1 root handle 20: cbq bandwidth 10Mbit avpkt 1000
# tc class add dev eth1 parent 20:0 classid 20:1 cbq bandwidth 10Mbit rate \
10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000
# tc class add dev eth1 parent 20:1 classid 20:100 cbq bandwidth 10Mbit rate \
8Mbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 1000 \
bounded
# tc class add dev eth1 parent 20:1 classid 20:200 cbq bandwidth 10Mbit rate \
2Mbit allot 1514 weight 200Kbit prio 5 maxburst 20 avpkt 1000 \
bounded
# tc qdisc add dev eth1 parent 20:100 sfq quantum 1514b perturb 15
# tc qdisc add dev eth1 parent 20:200 sfq quantum 1514b perturb 15
# tc filter add dev eth1 parent 20:0 protocol ip prio 100 u32 match ip src \
150.151.23.24 flowid 20:200
# tc filter add dev eth1 parent 20:0 protocol ip prio 25 u32 match ip src \
150.151.0.0/16 flowid 20:100
这与前面的描述基本一致，所以就不做更多的解释了。
注：
在前面的例子中，我们注意到：即使 ISP 客户多数离线，我们的 Office 用户也仍然只 有 2 M 的带宽，这是相当浪费的。我们可以删掉 'bounded'
参数，这样，各类之间就可以相互借用带宽了。
但是，某些类也许不希望向其它类借用带宽；比如，一条线路上的两个互为竞争对手的 ISP 的情况。在这种情况下，我们可以加上关键字 'isolated'。
3. 结束语
目前，Linux 所提供的 QoS（服务质量）是所有操作系统中最复杂、最完善的。另外， BSD 的 ALTQ 应该说也相当不错；但是，在复杂性、
灵活性和可扩展性等方面要落后 Linux 一大截。我不太清楚微软的产品是否提供了这方面的功能。Sun 的 Solaris 提供 了 CBQ 和 RSVP 的功能。
Linux 也支持 IETF diffserv 特征。Linux 在 QoS 方面众多的特征，将极大提升 Linux 的市场占有率。
共2页: 上一页 [1] 2 下一页
|
收藏
推荐
评论(0条)
