Disclaimer: This manual is NOT a Squid tutorial. It does not, for example, take the reader through step-by-step details of Squid installation and configuration. The objective of this manual is to explain, in as much detail as possible, every configuration parameter available in Squid. As such, the reader is required to have prior knowledge of basic Squid installation and configuration. The details presented in this manual are in the nature of reference material.
For a complete tutorial on Squid, please visit http://www.squid-cache.org/
 
 

Table of Contents

  1. Network
     This section explains ALL the network address parameters relevant to a Squid installation. Generally speaking, a Squid instance will need to communicate with:
    • Local or remote web servers
    • Other Cache servers
    • Clients (desktop browsers or gateways)

Squid configuration needs to define the addresses (IP address + port) for every relevant server and gateway This section focuses on communication with clients and web servers. The next section will detail the parameters required for communication with other cache servers in the network.

    A quick note on inter-server communication. Squid listens for TCP or ICP communication on specific ports. It uses TCP to communicate with web servers and clients, and ICP to talk to other cache servers. For every such server (or client), Squid configuration needs to assign a unique port number over which Squid would send requests (TCP or ICP) and listen for responses. An IP address is simply the network address at which the server is running. In short, the complete address for any server-to-server communication is determined by an IP-address+port combination. The following network parameters are relevant to Squid configuration:

  1. Peer cache servers and Squid hierarchy
    The parameters described in this section are relevant when there is a Squid hierarchy in the network (i.e. more than one Squid instance running in the network with well-defined rules regarding which instance talks to which other instance, and so forth). Parameters of interest here are: number of cache servers, type of configuration (which instance communicates with which instance(s)), defining the primary cache server, mapping of specific domains to specific cache server instances, Timeouts, specification of objects that should not be cached locally etc. Relevant parameters covered by this section are:
  1. Cache size 

    2. This section describes parameters related to Cache Memory Size (real memory) as well as Cache Replacement Policy. Squid supports more than one Cache replacement policy. This section also touches briefly on cache interaction with disk, but that subject is covered in greater detail in the next section. Relevant parameters for this section are
  1. Log file path names and cache directories

    2. This section describes parameters for the configuration of cache directories (placement of caches in specific files and directories) AND Log file placement on disk (size, name, path, activity). Log files contain runtime information (relevant "successful" events as well as errors). Log files are used for system level debugging and runtime activity.

    Certain log file management issues, e.g. backups, restore, recycling etc. are not described here. For more information on controlling the log file size, see logfile_rotate directive, Squid command line option (-k rotate) and man page on logrotate in Linux. 
  1. Support for External functions
    Squid has the ability to invoke certain "externally defined' functions that are NOT part of the Squid binary. Such "external" executables (programs) are usually placed in a contrib directory for source code distribution. The most common "external" programs are FTPUser, DNS, Redirectors and Authenticators, and are usually contributed by sources other than Squid.

    External programs are invoked by Squid through the standard fork() and exec(). The number of such fork-able child processes for specific "external" processes can also be defined. Relevant parameters for this section are: 
  1. Tuning the Squid Cache
    This section describes the important parameters that determine Squid cache performance. Notable among them are: Object refresh algorithm, size of the header and body for both reply and request, policy for aborting (server) connections when client closes connection etc. Relevant parameters are described below:
  1. Timeouts 

    2. Timeout parameters in Squid can be based on overall connection timeouts, peer-specific timeouts, site/domain-specific timeouts, request-specific timeouts etc. Proper setting of timeout values is critical to optimal Squid performance. Relevant parameters for timeout settings are listed here.
  1. Access controls

    2. Access control settings are among the most important features of Squid. You can configure Squid to set filters for various entities and at different granularities (e.g. filters for specific protocols, filters for certain types of commands, filters for specific routers, filters for specified domains, etc). The relevant parameters are described below:
  1. Administrative parameters 

    2. The parameters in this section allow the Squid admin to specify, for example, which users and groups have the right to run Squid , what host name should be displayed while displaying errors, which users have the authority to view Cache activity details, etc. 
  1. Options for the cache registration service 

    2. Squid administrators have the option of registering their cache server with http://ircache.nlanr.net/Cache/Tracker/, a service that helps cache sites locate each other in order to create cache hierarchies. Relevant registration parameters are described by:
  1. Httpd-accelerator options

    2. Squid can act as a load balancer or load reducer for a particular webserver. Generally squid not only keeps clients happy but also the web servers by reducing load on server side. Some cache servers can act as web servers (or vice versa). These servers accept requests in both the standard web-request format (where only the path and filename are given), and in the proxy-specific format (where the entire URL is given). The Squid designers have decided not to let Squid to be configured in this way. This avoids various complicated issues, and reduces code complexity, making Squid more reliable. All in all, Squid is a web cache, not a web server.

By adding a translation layer into Squid, we can accept (and understand) web requests, since the format is essentially the same. The additional layer can re-write incoming web requests, changing the destination server and port. This re-written request is then treated as a normal request: the remote server is contacted, the data requested and the results cached. This lets Squid to pretend to be a web server, rewriting requests so that, they are passed on to some other web server. 

For Transparent caching, Squid can be configured to magically intercept outgoing web requests and cache them. Since the outgoing requests are in web-server format, it needs to translate them to cache-format requests. Transparent redirection is prohibited by internet standard #5 "Internet Protocol". And HTTP assumes no transparent redirection is taking place. 

This section allows various configurations related to the accelerator mode and the transparent mode. 

  1. Miscellaneous

    2. As the title suggests, this section covers parameters that could not be explicitly bundled in with any of the previous categories. Examples of features covered here are:
    • Limiting the growth of log fils.
    • Displaying customized information to clients upon error conditions or access denial.
    • Defining memory pools for Squid.
    • Network management by enabling SNMP.
    • Co-ordination with neighbor caches by enabling WCCP and
    • Directing the requests either to the origin server or to the neighbor cache.

    The relevant parameters are:

  1. Delaypool parameters (all require delay_pools compilation options)
    Conceptually, Delay pools are bandwidth limitations - "pools" of bandwidth that drain out as people browse the Web, and fill up at a rate we specify - this can be thought of as a leaky bucket that is continually being filled. This is useful when bandwidth charges are in place, if we want to reduce bandwidth usage for web traffic.

    Delay Pools can do wonders when combined with ACLs. These tags permit us to limit the bandwidth of certain requests, based on any criteria. Delay behavior is selected by ACLs (low and high priority traffic, staff Vs students or student Vs authenticated student or so on). In ISPs, delay pools can be implemented in a particular network to improve the quality of service. To enable this, Squid needs to be configured with the --enable-delay-pools option.

    Relevant parameters are described below: 
     
  1. Glossary
    The Glossary provides a general explanation for various terms used in this guide. 

 

 
 
All rights reserved.
All trademarks used in this document are owned by their respective companies. This document makes no ownership claim of any trademark(s). If you wish to have your trademark removed from this document, please contact the copyright holder. No disrespect is meant by any use of other companies’ trademarks in this document.
Note: The pages on this website cannot be duplicated on to another site. Copying and usage of the contents for personal and corporate purposes is acceptable. In near future, it will be released under the GNU Free Documentation License.
© ViSolve.com 2002 
Created By: squid@visolve.com Date: May 26, 2002
Revision No:0.0 
Modified ByDate