Before we describe Squid features for hierarchical caching, we first
briefly explain the neighbour selection process, aspects of which have
motivated features described in the following section.
First, what does ``neighbour selection process'' refer to?
When Squid is unable to satisfy a request from the cache (i.e.
its a cache miss), Squid must decide where to forward the request
next. There are basically three choices: a parent cache, a sibling
cache, or the origin server. Squid uses ICP to make this decision.
Squid sends an ICP query message to its neighbours (both parents and
siblings). The ICP query includes the requested URL and is sent
in a UDP packet. Squid remembers how many queries it sends for a
Each neighbour receives its ICP query and looks up the URL in its own cache.
If a valid copy of the URL exists, the cache sends ICP_HIT, otherwise
an ICP_MISS message.
The querying cache now collects the ICP replies from its peers. If the
cache receives an ICP_HIT reply from a peer, it immediately forwards
the HTTP request to that peer. If the cache does not receive an ICP_HIT reply,
then all replies will be ICP_MISS. Squid waits until it receives all replies,
up to two seconds. If one of the ICP_MISS replies comes from a parent,
Squid forwards the request to the parent whose reply was the first to arrive.
We call this reply the FIRST_PARENT_MISS. If there is no ICP_MISS from a parent
cache, Squid forwards the request to the origin server.
We have described the basic algorithm, to which Squid offers numerous
possible modifications, including mechanisms to:
Send ICP queries to some neighbours and not to others.
Include the origin server in the ICP ``pinging'' so that if the
origin server reply arrives before any ICP_HITs, the request is
forwarded there directly.
Disallow or require the use of some peers for certain requests.