Ключевые слова:squid, delay, howto, (найти похожие документы)
_ RU.UNIX.BSD (2:5077/15.22) _____________________________________ RU.UNIX.BSD _
From : Vad Adamluk 2:478/20 26 Dec 98 09:41:00
Subj : Ограничение трафика на хост в SQUID 2.0
________________________________________________________________________________
Приветствую Вас, Roman!
At 23 Dec 98 20:56:53, Roman Gasteff wrote to All:
AK>> Хочется установить ограничение трафика на хост в SQUID 2.0.
AK>> В конфиге прописал следующее:
AK>> acl comp src XXX.XXX.XXX.XXX/255.255.255.255
AK>> delay_class1_access comp
AK>> delay_class1_aggregate_max 8000
AK>> delay_class1_aggregate_restore 8000i
RG> Аналогичная пpоблема (за исключением того что я пpосто в локалке
RG> экспеpементиpую) , может кто-нибудь pаскажет популяpно, как этим вообще
RG> пользоваться, оно вообще живое, etc ? FreeBSD 2.2.7-R, Squid 2.0 patch2.
>===== Start cut [/tmp/aaa] =====<
Subject: DELAY_POOLS: How to setup
Resent-Date: Wed, 11 Nov 1998 10:09:59 -0800 (PST)
Resent-From: [email protected]
Date: Wed, 11 Nov 1998 18:08:45 +0200
From: Evaghelos Tsiotsios <[email protected]>
To: [email protected]
CC: [email protected], David Luyer
<[email protected]>
Well, I think that delay pools is one of the most useful features of
Squid,
addressed to manageable teams of users, so I will try to give a brief
explanation of how it works. I have not been involved in the
development, so
David please correct me where I am wrong:
Delay pools are meant to provide a way of assigning tokens of bandwidth
allowance to Squid users. Pools are assigned on a host basis (IP), which
basically means that what you restrict is the WAN bandwidth pumped by
Squid
for any individual host accessing the Net through it.
I am beginning from the most general case, which is the allowance for a
group of hosts (a block of IP addresses).
An individual host may be part of a group or be a group in itself.
In delay pools there are four basic parameters to be defined:
1) aggregate_max
2) aggregate_restore
and
3) individual_max
4) individual_restore
In order to understand the meaning of each parameter I will briefly
explain
the concept behind delay pools:
For every host in one group there is one delay pool size descriptor
(individual_max) and one increment level (individual_restore)
associated.
We can think delay pools as a bucket of tokens (bytes). The size of the
bucket (for one host) is individual_max bytes. At any given time, the
bucket
can have at max that many tokens (bytes) accumulated. Before Squid
fetches a
page for that host, it looks up the number of tokens (bytes) available
at
the bucket. Let's call it the current bucket watermark. If there are
enough
tokens in the bucket, Squid gets the tokens it needs, lowers the bucket
watermark accordingly and proceeds to reading a number of bytes from the
connection. If there are no tokens available, Squid is enforced to defer
the
read, until some tokens (bytes) are available within the bucket. How is
this
done? This is where the increment level value comes into play:
individual_restore defines the number of tokens (bytes) added to the
current
bucket watermark level every second.
To further visualise it, think of a real bucket under a faucet: the
bucket
can hold a certain amount of water (e.g. 1 litre). The faucet drops a
certain amount of water each second (for example 10 cl).
We start with the bucket filled of water, but as we start taking water
off
the bucket with a glass, the available water goes down. If we want to
keep a
steady watermark level we must take water with the same rate it is
dropping
from the faucet. If we have a higher rate, the bucket will soon become
empty, and then we will have to wait until the faucet has dropped enough
water in the bucket again.
If we do not use any water for some time the water will overflow the
bucket,
therefore the bucket will continue to have at most 1 litre of water for
immediate use.
At telecomm parlance, this is a variation of the leaky bucket algorithm
(no
wonder why I used the bucket as an example)! It will (?)be used for
bandwidth policing in modern data networks (ATM for example).
How to configure the delay pools in Squid now:
At first decide what kind of grouping you need. If you want all your
users
to have only one bucket then you go for delay_class1.
If you want to have separate buckets for each user then you must opt for
delay_class2 or class3 (depends on your network).
The Aggregate_* settings work almost the same way as the individual with
one
distinction: in class 2 (this is what I use) and class3 the aggregate
delay
pool is used only if no individual pool is defined.
IMHO I think that it would be more efficient if the aggregate delay pool
could provide tokens if an individual pool ran out of tokens at a
certain
time. (This could be an additional measure to accommodate bursts for
some
users).
If you decide that you need class2 then remember to put the statement
acl all src 0.0.0.0/0.0.0.0
delay_class1_access deny all
At present it is needed in order to allow class2/class3.
Assume that you want class2 delay pools. Then you need something like
the
following:
acl hosts src xxx.xxx.xxx.a-xxx.xxx.xxx.b/255.255.255.255
delay_class2_access allow hosts
#delay_class2_aggregate_max 32000
#delay_class2_aggregate_restore 2000
delay_class2_individual_max 24000
delay_class2_individual_restore 1200
This defines a block of hosts with IP addresses in the Class C net from
a to
b (but you can add also other individual hosts to the acl)
that will share the following pool settings:
Maximum pool size 24000 bytes
Increment level 1200 bytes
I don't use the aggregate settings because they do not have any effect
when
individual pools are set.
The individual settings more or less let the host fetch "immediately"
pages
that are slightly larger than 24000 bytes. If the host tries to fetch a
large page then Squid after the initial burst (~24KB) it will slow down
to
the rate defined by the increment value defined by
"delay_class2_individual_restore" (i.e. 1200 bytes/sec).
If you do not want to allow for any burstiness in the delay pool then
simply
define the max size of the pool equal to the restore size. (but this is
already documented).
Right now, you can have only one effective delay pool setting. This
means
that you cannot set more than one group of users in the same class. I
hope
that David will find the time to extend delay pools in order to handle
more
than one type of host groups in one class. In my view this is necessary.
After using delay pools for some time now, I strongly think that it is a
powerful add-on to Squid. I think that if it is extended to handle
multiple
groups (with different pool settings in each group) its value will be
really
leveraged.
Cheers,
Evaghelos.
И еще одна добавка от автора delay pools
Subject: Re: DELAY_POOLS: How to setup
Resent-Date: Wed, 11 Nov 1998 18:27:05 -0800 (PST)
Resent-From: [email protected]
Date: Thu, 12 Nov 1998 09:29:04 +0800
From: David Luyer <[email protected]>
To: Evaghelos Tsiotsios <[email protected]>
CC: [email protected], [email protected]
Thanks to Evaghelos Tsiotsios for his description of delay pools. A few
clarifying comments are below;
> The Aggregate_* settings work almost the same way as the individual with one
> distinction: in class 2 (this is what I use) and class3 the aggregate delay
> pool is used only if no individual pool is defined.
This assumption (and related comments later) is incorrect. (Or if it is
correct it is a coding error.) The aggregate and individual totals both
act to limit the traffic, if either is empty then the request is
delayed.
For example, I run approx 64kbps peak rate (with small 'bucket size') on
one of the delay_class2 pools and then give each user in it approx 8kbps
(with
large 'bucket size'). The large bucket size on individual users lets
each user
get a web page "instantly" but if they start downloading a large file it
is
slow. The small bucket size on the aggregate means that the 64kbps is
the
limit of bandwidth use (modulo overheads) for these users.
Also, I didn't notice any mention of the 'no-delay' tag you can put on
neighbors - this will prevent traffic fetched from that peer from being
'taken out of the bucket'; for example if you have a fast, "free
traffic"
ATM network to local universities but anything further away costs money,
and you peer caches with local universities, you can put the 'no-delay'
tag on these peers cache_host lines.
Regarding class2/3 delay pools:
It could take some time before I'm able to do any work on multiple delay
pools of a given class. How I think it should work is this (sorry,
sparse
documentation on this, but I hope enough to show anyone whose interested
and understands the current system what it means):
delay_pools 3 # 3 delay pools
delay_class 1 1 # pool 1 is class 1
delay_class 2 1 # pool 2 is class 1
delay_class 3 3 # pool 3 is class 3
delay_access 1 allow staff
delay_access 1 deny all
delay_access 2 allow students
delay_access 2 deny all
delay_access 3 allow college
delay_access 3 deny all
delay_parameters 1 640000/640000
delay_parameters 2 64000/64000
delay_parameters 3 64000/64000 32000/64000 6400/32000
# ttl_rest/ttl_max net_rest/net_max ind_rest/ind_max
The acls and delay pool data could then be dynamically allocated. Maybe
once this was done delay pools could be put into squid by default as the
cost of disabled delay pools would be very close to zero (simply a few
checks if delay_pools number was 0).
David.
>===== End cut [/tmp/aaa] =====<
За сим откланиваюсь,
xDM.
--- QEcho alpha v3.57pl9.1e/FreeBSD * Origin: Любви моей не омрачай согласьем. (2:478/20)
