Hadyai Internet R&D LAB
แหล่งความรู้ => Server => Linux Server System => ข้อความที่เริ่มโดย: admin ที่ 01 มิถุนายน 2008, 11:32:56
-
Ref : http://www.weijl.org/index.php?page=cbq-traffic-shaping
CBQ traffic shaping with Debian
Version 0.1, 2008-03-31
Traffic shaping (also known as "packet shaping") is an attempt to control computer network traffic in order to optimize or guarantee performance, lower latency, and/or increase usable bandwidth by delaying packets that meet a certain criteria. More specifically, traffic shaping is any action on a set of packets (often called a stream or a flow) which imposes additional delay on those packets such that they conform to some predetermined constraint (a contract or traffic profile). Traffic shaping provides a means to control the volume of traffic being sent into and/or from a network in a specified period (bandwidth throttling), or the maximum rate at which the traffic is sent (rate limiting). This control can be accomplished in many ways and for many reasons; however traffic shaping is always achieved by delaying packets.
What I was looking for is a way to 'cap' my connection, so it won't halt when someone is downloading something from (for example) my website. This can be done with traffic shaping, and a package called shaper is going to make this pretty easy. In this document I will discuss what you need in order to start 'capping' and give some examples to get you started.
Table of Contents
What do we need?
Example configurations files
Testing our shaped connection
--------------------------------------------------------------------------------
What do we need?
What we need is a package called shaper, which can be found in the debian repositories. Just apt-get it and we can go to work!
root@hostname# apt-get update
root@hostname# apt-get upgrade
root@hostname# apt-get install shaper
It is possible you do not have some packages it relies on (like iproute), but apt will take care of that for you just fine.
Example configuration files
Now shaper is installed we can create our configuration files for it and start capping that precious bandwidth. But before I start with the examples let's first look at the statements that I will be using. I had trouble to find the documentation, but a friend of mine pointed me to the init script itself.
# DEVICE=<ifname>,<bandwidth>[,<weight>] mandatory
# DEVICE=eth0,10Mbit,1Mbit
#
# <ifname> is the name of the interface you want to control traffic on, e.g. eth0
# <bandwidth> is the physical bandwidth of the device, e.g. for ethernet 10Mbit or 100Mbit,
# for arcnet 2Mbit
# <weight> is tuning parameter that should be proportional to <bandwidth>.
# As a rule of thumb: <weight> = <bandwidth> / 10
#
# When you have more classes on one interface, it is enough to specify <bandwidth>
# [and <weight>] only once, therefore in other files you only need to set DEVICE=<ifname>.
#
# RATE=<speed> mandatory
# RATE=5Mbit
#
# Bandwidth allocated to the class. Traffic going through the class is shaped to conform to
# specified rate. You can use Kbit, Mbit or bps, Kbps and Mbps as suffices. If you don't
# specify any unit, bits/sec are used. Also note that "bps" means "bytes per second", not bits.
#
# WEIGHT=<speed> mandatory
# WEIGHT=500Kbit
#
# Tuning parameter that should be proportional to RATE. As a rule of thumb,
# use WEIGHT ~= RATE / 10.
#
# PRIO=<1-8> optional, default 5
# PRIO=5
#
# Priority of class traffic. The higher the number, the lesser the priority.
# Priority of 5 is just fine.
#
# RULE=[[saddr[/prefix]][:port[/mask]],][daddr[/prefix]][:port[/mask]]
#
# These parameters make up "u32" filter rules that select traffic for each of the classes.
# You can use multiple RULE fields per config.
#
# The optional port mask should only be used by advanced users who
# understand how the u32 filter works.
#
# Some examples:
#
# RULE=10.1.1.0/24:80
# selects traffic going to port 80 in network 10.1.1.0
#
# RULE=10.2.2.5
# selects traffic going to any port on single host 10.2.2.5
#
# RULE=10.2.2.5:20/0xfffe
# selects traffic going to ports 20 and 21 on host 10.2.2.5
#
# RULE=:25,10.2.2.128/26:5000
# selects traffic going from anywhere on port 50 to
# port 5000 in network 10.2.2.128
#
# RULE=10.5.5.5:80,
# selects traffic going from port 80 of single host 10.5.5.5
I only grabbed the statements I am going to use in this document, but if you're curious what else shaper can do, look at the init file located at /etc/init.d/shaper.
Below is an outgoing SMTP example. You should be placed in /etc/shaper, and let's just name it cbq-0020-smtp.
DEVICE=eth0,100Mbit,10Mbit
RATE=512Kbit
WEIGHT=52Kbit
PRIO=4
RULE=,:25
Let's give another example but now on an incoming HTTP connection. For obvious reasons let's call this one cbq-0030-http.
DEVICE=eth0,100Mbit,10Mbit
RATE=512Kbit
WEIGHT=52Kbit
PRIO=4
RULE=:80,
Of course after you have made the configuration files, we need to restart shaper in order for it to work.
root@hostname# /etc/init.d/shaper restart
Both examples should cap the connection to a maximum of 512Kbit or 64Kbyte.
Testing our shaped connection
Just try and download something from your webserver now. Pretty neat huh?! I can imagine you do not want this behaviour for you localnetwork, so we have to create one more config file in order for it to work like we want it! Let us call it cbq-0010.http-localnetwork
DEVICE=eth0,100Mbit,10Mbit
RATE=100Mbit
WEIGHT=10Mbit
PRIO=4
RULE=:80,<network_range/subnet>
This can probably be done more efficiently, but since this worked for me I didn't look any further.