Ключевые слова: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)
Date: Wed, 11 Nov 1998 18:08:45 +0200
From: Evaghelos Tsiotsios <email@example.com>
CC: firstname.lastname@example.org, David Luyer
Well, I think that delay pools is one of the most useful features of
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
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
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:
In order to understand the meaning of each parameter I will briefly
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)
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
can have at max that many tokens (bytes) accumulated. Before Squid
page for that host, it looks up the number of tokens (bytes) available
the bucket. Let's call it the current bucket watermark. If there are
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
read, until some tokens (bytes) are available within the bucket. How is
done? This is where the increment level value comes into play:
individual_restore defines the number of tokens (bytes) added to the
bucket watermark level every second.
To further visualise it, think of a real bucket under a faucet: the
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
the bucket with a glass, the available water goes down. If we want to
steady watermark level we must take water with the same rate it is
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
therefore the bucket will continue to have at most 1 litre of water for
At telecomm parlance, this is a variation of the leaky bucket algorithm
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
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
distinction: in class 2 (this is what I use) and class3 the aggregate
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
time. (This could be an additional measure to accommodate bursts for
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
acl hosts src xxx.xxx.xxx.a-xxx.xxx.xxx.b/255.255.255.255
delay_class2_access allow hosts
This defines a block of hosts with IP addresses in the Class C net from
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
individual pools are set.
The individual settings more or less let the host fetch "immediately"
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
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
define the max size of the pool equal to the restore size. (but this is
Right now, you can have only one effective delay pool setting. This
that you cannot set more than one group of users in the same class. I
that David will find the time to extend delay pools in order to handle
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
groups (with different pool settings in each group) its value will be
И еще одна добавка от автора delay pools
Subject: Re: DELAY_POOLS: How to setup
Resent-Date: Wed, 11 Nov 1998 18:27:05 -0800 (PST)
Date: Thu, 12 Nov 1998 09:29:04 +0800
From: David Luyer <email@example.com>
To: Evaghelos Tsiotsios <firstname.lastname@example.org>
CC: email@example.com, firstname.lastname@example.org
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
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
large 'bucket size'). The large bucket size on individual users lets
get a web page "instantly" but if they start downloading a large file it
slow. The small bucket size on the aggregate means that the 64kbps is
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
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,
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).
>===== End cut [/tmp/aaa] =====<
За сим откланиваюсь,
--- QEcho alpha v3.57pl9.1e/FreeBSD * Origin: Любви моей не омрачай согласьем. (2:478/20)