نوشته اصلی توسط
Star-x
Peer Configuration
First, let's look at the squid.conf
options available for hierarchy
configuration. We will then work
through the most common
hierarchy structures, so that you
can see the way that the options
are used.
You use the cache_peer option
to configure the peers that Squid
will communicate with. Other
options are then used to select
which peer to pass a request to.
The cache_peer
Option
When communicating with a
peer, Squid needs some basic
information about how to talk to
the machine; the hostname, what
ports to send queries to, and so
forth. The cache_peer config line
does this. Let's look at an
example line:
Example 7-1. The cache_peer
tag
c a c h e _ p e e r c a c h e . d o m a i n . e x a m p l e p a r e n t 3 1 2 8 3 1 3 0 d e f a u l t
The cache_peer option is split
into five fields. The first field
( cache.domain.example) is the
hostname or IP of the cache that
is to be queried. The second field
indicates the type of relationship,
and must be set to either parent
or sibling or multicast. The third
field sets the HTTP port of the
destination server, while the
fourth sets the ICP (UDP) query
port. The fifth field can contain
more than zero or more
keywords, although we only use
one in the example above; the
keyword default sets that the
cache will be used as the default
path to the outside world. If you
compiled Squid to support HTCP,
your cache will automatically
attempt to connect to TCP port
4827 (there is currently no
option to change this port value).
Cache digests are transferred via
the HTTP port specified on the
cache_peer line.
Here is a summary of the
available cache_peer options:
proxy-only. Data retrieved from
this remote cache will not be
stored locally, but retrieved again
on any subsequent request. By
default Squid will store objects it
retrieves from other caches: by
having the object available locally
it can return the object fast if it's
ever requested again. While this
is good for latency, it can be a
waste of bandwidth, especially if
the other cache is on the same
piece of ethernet. In the
examples section of this chapter,
we use this option when load-
balancing between two cache
servers.
weight. If more than one cache
server has an object (based on
the result of an ICP query), Squid
decides which cache to get the
data from the cache that
responded fastest. If you want to
prefer one cache over another,
you can add a weight value to
the preferred cache's config line.
Larger values are preferred.
Squid times how long each ICP
request takes (in milliseconds),
and divides the time by the
weight value, using the cache
with the smallest result. Your
weight value should thus not be
an unreasonable value.
ttl. This tag is covered in the
multicast section, later in this
chapter.
no-query. Squid will send ICP
requests to all configured caches.
The response time is measured,
and used to decide which parent
to send the HTTP request to.
There is another function of
these requests: if there is no
response to a request, the cache
is marked down. If you are
communicating with a cache that
does not support ICP, you must
use the no-query option: if you
don't, Squid will consider that
cache down, and attempt to go
directly to the destination server.
(If you want, you can set the ICP
port on the config line to point to
the echo port, port 7. Squid will
then use this port to check if the
machine is available. Note that
you will have to configure
inetd.conf to support the UDP
echo port.) This option is
normally used in conjunction
with the default option.
default. This sets the host to be
the proxy of last resort. If no
other cache matches a rule (due
to acl or domain filtering), this
cache is used. If you have only
one way of reaching the outside
world, and it doesn't support ICP,
you can use the default and no-
query options to ensure that all
queries are passed through it. If
this cache is then down, the
client will see an error message
(without these options, Squid
would attempt to route around
the problem.)
round-robin. This option must be
used on more than one
cache_peer line to be useful.
Connections to caches
configured with this options are
spread evenly (round-robined)
among the caches. This can be
used by client caches to
communicate with a group of
loaded parents, so that load is
spread evenly. If you have
multiple Internet connections,
with a parent cache on each side,
you can use this option to do
some basic load-balancing of the
connections.
multicast-responder. This
option is covered in the multicast
section later in this chapter.
closest-only.
no-netdb-exchange. If your
cache was configured to keep
ICMP (ping) timing information
with the --enable-icmp
configure option, your cache will
attempt to retrieve the remote
machine's ICMP timing
information from any peers. If
you don't want this to happen
(or the remote cache doesn't
support it), you can use the no-
netdb-exchange option to stop
Squid from requesting this
information from the cache.
no-delay. Hits from other caches
will normally be included into a
client's delay-pool information. If
you have two caches load-
balancing, you don't want the
hits from the other cache to be
limited. You may also want hits
from caches in a nearby
hierarchy to come down at full
speed, not to be limited as if they
were misses. Use the no-delay
option to ensure that requests
come down at their full speed.
login. Caches can be configured
to use usernames and
passwords on accesses. To
authenticate with a parent cache,
you can enter a username and
password using this tag. Note
that the HTTP protocol makes
authenticating to multiple cache
servers impossible: you cannot
chain together a string of
proxies, each one requiring
authentication. You should only
use this option if this is a
personal proxy.
1سپاس
LinkBack URL
About LinkBacks
