구차니의 잡동사니 모음

What makes a request hierarchic

The purpose of cache hierarchy is to maximize the chance of finding objects in siblings, so a set of heuristics is applied to try and determine in advance whether an object is likely to be cacheable. A few objects are not cacheable, and are thus not hierarchic. Those are:

• reload requests
• cache validations with non-Squid ICP peers

• requests for HTTP methods other than GET, HEAD or TRACE

• authenticated requests 

2.4 Helper Multiplexer

The helper multiplexer's purpose is to relieve some of the burden Squid has when dealing with slow helpers. It does so by acting as a middleman between squid and the actual helpers, talking to Squid via the multiplexed concurrent variant of the helper protocol and to the helpers via the non-concurrent variant.

Helpers are started on demand, and in theory the muxer can handle up to 1k helpers per instance. It's up to squid to decide how many helpers to start.

The muxer knows nothing about the actual messages being passed around, and as such can't really (yet?) compensate for broken helpers. It is not yet able to manage dying helpers, but it will.

To configure the multiplexer add its binary name (usually /usr/share/libexec/helper-mux.pl) in front of the name of whichever helper is being multiplexed. It takes the helper binary path and parameters as its own command parameters. The concurrency setting already existing in Squid is used to configure how many child helpers it may run.

For example, a traditional configuration is

        url_rewrite_program /your/redirector.sh
        url_rewrite_children 5
   

        url_rewrite_program /usr/share/libexec/helper-mux.pl /your/redirector.sh
        url_rewrite_children 1 concurrency=5
   

Helpers which are already concurrent protocol enabled gain little benefit from the multiplexer on most systems. However on some systems where Squid spawning helpers causes excess memory usage the reduction in direct helper spawned by Squid can result in a great reduction in resource use.

The helper can be controlled using various signals:

• SIGHUP: dump the state of all helpers to STDERR

 # OPTIONS FOR URL REWRITING

# -----------------------------------------------------------------------------

#  TAG: storeurl_rewrite_program
#	Specify the location of the executable for the Store URL rewriter.
#	The Store URL rewriter allows URLs to be "normalised" ; mapping
#	multiple URLs to a single URL representation for cache operations.
#
#	For example, if you request an object at:
#
#	http://srv1.example.com/image.gif
#
#	and a subsequent request for:
#
#	http://srv2.example.com/image.gif
#
#	then Squid will treat these both as different URLs and cache them
#	seperately.
#
#	This is almost the normal case, but an increasing number of sites
#	distribute the same content between multiple frontend hosts.
#	The Store URL rewriter allows you to rewrite these URLs to one URL
#	to use for cache operations, but not -fetches-. Fetches are still
#	made from the original site, but stored with the store URL rewritten
#	URL as the store key.
#
#	For each requested URL rewriter will receive on line with the format
#
#	URL <SP> client_ip "/" fqdn <SP> user <SP> method <SP> urlgroup
#	 [<SP> kvpairs] <NL>
#
#	In the future, the rewriter interface will be extended with
#	key=value pairs ("kvpairs" shown above).  Rewriter programs
#	should be prepared to receive and possibly ignore additional
#	whitespace-separated tokens on each input line.
#
#	And the rewriter may return a rewritten URL. The other components of
#	the request line does not need to be returned (ignored if they are).
#
#	By default, a Store URL rewriter is not used.
#
#	Please note - the normal URL rewriter rewrites Squid's _destination_
#	URL - ie, what it fetches. The Store URL rewriter rewrites Squid's
#	_store_ URL - ie, what it uses to store and retrieve objects.
#
#Default:
# none

#  TAG: url_rewrite_program
#	Specify the location of the executable for the URL rewriter.
#	Since they can perform almost any function there isn't one included.
#
#	For each requested URL rewriter will receive on line with the format
#
#	URL <SP> client_ip "/" fqdn <SP> user <SP> method <SP> urlgroup
#	 [<SP> kvpairs] <NL>
#
#	In the future, the rewriter interface will be extended with
#	key=value pairs ("kvpairs" shown above).  Rewriter programs
#	should be prepared to receive and possibly ignore additional
#	whitespace-separated tokens on each input line.
#
#	And the rewriter may return a rewritten URL. The other components of
#	the request line does not need to be returned (ignored if they are).
#
#	The rewriter can also indicate that a client-side redirect should
#	be performed to the new URL. This is done by prefixing the returned
#	URL with "301:" (moved permanently) or 302: (moved temporarily).
#
#	It can also return a "urlgroup" that can subsequently be matched
#	in cache_peer_access and similar ACL driven rules. An urlgroup is
#	returned by prefixing the returned URL with "!urlgroup!".
#
#	By default, a URL rewriter is not used.
#
#Default: 

# none 

6.7 Squid result codes

The TCP_ codes refer to requests on the HTTP port (usually 3128). The UDP_ codes refer to requests on the ICP port (usually 3130). If ICP logging was disabled using the log_icp_queries option, no ICP replies will be logged.

The following result codes were taken from a Squid-2, compare with the log_tags struct in src/access_log.c:

TCP_HIT

A valid copy of the requested object was in the cache.

TCP_MISS

The requested object was not in the cache.

TCP_IMS_HIT

The client issued an IMS request for an object which was in the cache and fresh.

TCP_SWAPFAIL_MISS

The object was believed to be in the cache, but could not be accessed.

TCP_NEGATIVE_HIT

Request for a negatively cached object, e.g. "404 not found", for which the cache believes to know that it is inaccessible. Also refer to the explainations for negative_ttl in your squid.conf file.

TCP_MEM_HIT

A valid copy of the requested object was in the cache and it was in memory, thus avoiding disk accesses.

TCP_DENIED

Access was denied for this request.

TCP_OFFLINE_HIT

The requested object was retrieved from the cache during offline mode. The offline mode never validates any object, see offline_mode in squid.conf file. 

6.10 Hierarchy Codes

The following hierarchy codes are used with Squid-2:

NONE

For TCP HIT, TCP failures, cachemgr requests and all UDP requests, there is no hierarchy information.

DIRECT

The object was fetched from the origin server.