Many large organizations use caching proxy servers to save on network bandwidth utilization (and costs) and improve browsing response times. In fact, an entire industry has grown up around caching proxy appliances. But in the open source world, we’ve had one of the most advanced proxy servers for many, many years. Squid (http://www.squid-cache.org) is to caching proxy servers as Apache is to web servers — the hands-down open source winner.
Many large organizations use caching proxy servers to save on network bandwidth utilization (and costs) and improve browsing response times. In fact, an entire industry has grown up around caching proxy appliances. But in the open source world, we’ve had one of the most advanced proxy servers for many, many years. Squid (http://www.squid-cache.org) is to caching proxy servers as Apache is to web servers — the hands-down open source winner.
Caching Background
In a typical deployment, the Squid proxy server sits between internal users and a corporate firewall, as shown in Figure One. Rather than sending all requests directly to remote sites on the Internet, clients connect to the Squid proxy to issue GET and POST requests. If Squid has the requested resource, it simply returns it from its local cache; otherwise, Squid contacts the remote site to request the resource, possibly caching the result.
To keep track of when objects should expire and to determine if an object should be cached in the first place, Squid pays attention to the Expires, Last-Modified, Pragma, and Cache-Control headers that are sent back in HTTP responses. If Squid already has an up-to-date, local copy of a resource, there’s no need to fetch it from the…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
