Squid_ The Definitive Guide - Duane Wessels [71]
First of all, if your Squid is lightly used (say, less than five requests per second), the default ufs storage scheme should be sufficient. You probably won't see a noticeable performance improvement from the other schemes at this low request rate.
If you are trying to decide which scheme to try, your operating system may be a determining factor. For example, aufs runs well on Linux and Solaris but seems to have problems on other systems. The coss code uses functions that aren't available on certain operating systems (e.g., NetBSD) at this time.
It seems to me that higher-performing storage schemes are also more susceptible to data loss in the event of a system crash. This is the tradeoff for better performance. For many people, however, cached data is of relatively low value. If Squid's cache becomes corrupted due to a crash, you may find it easier to simply newfs the disk partition and let the cache fill back up from scratch. If you find it difficult or expensive to replace the contents of Squid's cache, you probably want to use one of the slow, but reliable, filesystems and storage schemes.
Squid certainly allows you to use different filesystems and storage schemes for each cache_dir. In practice, however, this is uncommon. You'll probably have fewer hassles if all cache directories are approximately the same size and use the same storage scheme.
Exercises
Try to compile all possible storage schemes on your system.
Run Squid with a separate cache_dir for each storage scheme you can get to compile.
Run Squid with one or more diskd cache_dirs. Then run the ipcs -o command.
Chapter 9. Interception Caching
Interception caching is a popular technique for getting traffic to Squid without configuring any clients. Instead, you configure a router or switch to divert HTTP connections to the machine on which Squid is running. Squid's operating system is configured to accept the foreign packets and deliver them to the Squid process. To make HTTP interception work, you need to configure three separate components: a network device, Squid's operating system, and Squid itself.
This chapter begins with an overview of HTTP interception. I'll explain how it all works and define some terms so that the remaining sections make sense. I also explain the tradeoffs involved with HTTP interception.
Following that, I'll discuss your options for devices and configurations that can intercept client traffic. In particular, I cover Cisco policy routing, Cisco's WCCP, layer four switches, and running Squid on a host that also functions as a router or bridge.
Next, I'll show how to configure the operating system to handle the intercepted connections. This functionality is a feature of the IP packet filtering software, which varies from system to system. It is called iptables (Netfilter) on Linux; ipfw on FreeBSD; pf on OpenBSD; and IPFilter on NetBSD, Solaris, and other BSD variants.
Squid is the final component you need to configure. Fortunately, this is relatively straightforward because it doesn't depend on your operating system or network device.
I finish the chapter with a little checklist that may help you debug HTTP interception problems.
How It Works
Interception caching involves some network trickery, so it is helpful for you to understand what happens between the client and Squid. I'll use Figure 9-1 and the following sample tcpdump output to explain how the packets are intercepted as they flow through your network.
Figure 9-1. How HTTP interception works
The user-agent wants to request a resource, say /index.html from an origin server, say www.oreilly.com. It needs the origin server's IP address, so it makes a DNS request:Packet 1
TIME: 19:54:41.317310
UDP: 206.168.0.3.2459 -> 206.168.0.2.53
DATA: .d...........www.oreilly.com.....
---------------------------------------------------------------------------
Packet 2
TIME: 19:54:41.317707 (0.000397)
UDP: 206.168.0.2.53 -> 206.168.0.3.2459
DATA: .d...........www.oreilly.com.............PR.....%........PR.