While CARP is almost always the default recommendation, your physical architecture determines how you deploy it:
1. The Standard Setup: Frontend Load Balancer + CARP
If you have an enterprise load balancer (like an F5 BIG-IP, HAProxy, or an AWS Network Load Balancer) in front of your Squid cluster, you can let the load balancer handle the hashing or CARP-like routing.
The Flow: The load balancer uses URI-hash-based routing to ensure requests for
[example.com/file.zip](https://example.com/file.zip)always hit Proxy A, while requests fordomain.org/image.pngalways hit Proxy B.The Benefit: No peer-to-peer communication between proxies is required. Each proxy acts independently, but they form a single logical, non-overlapping cache array.
2. The Internal Grid: Peer-to-Peer CARP
If you do not have a smart load balancer and want the Squid proxies to handle the routing among themselves, you configure them as CARP peers.
The Flow: A user's browser randomly hits Proxy A. Proxy A hashes the URL, realizes the hash belongs to Proxy B, and transparently forwards the request directly to Proxy B over the local network.
What about HTCP or Cache Digests?
HTCP (Hypertext Cache Protocol): While more secure than ICP and capable of handling complex HTTP headers, it still suffers from the same query-and-wait UDP overhead. It is rarely used in modern enterprise setups.
Cache Digests: This is a decent alternative if you must run a mesh hierarchy (where proxies occasionally peer but aren't strictly a load-balanced array). It works by sharing a Bloom filter "map" of the cache, avoiding UDP queries but consuming noticeable RAM to store the peer's directory.
Enterprise Recommendation:
For the highest throughput, lowest latency, and zero wasted storage, design your enterprise cluster with a load balancer utilizing URI-hash routing at the front, or fallback to Squid's built-in CARP peer configuration if you are running a self-managed proxy array.
How It Works Without Knowing the URIs
Instead of looking up a URL in a database of known links, the load balancer uses a hash function (a one-way mathematical formula).
When a client requests any URI—even one the load balancer has never seen before in its life—the load balancer performs three instant steps:
[ Client Request: /any-random-new-file.pdf ]
│
▼
[ Load Balancer ]
│
1. Run Hash: hash("/any-random-new-file.pdf") ──► 1,837,294,021
│
2. Modulo Nodes: 1,837,294,021 % 3 Nodes ──► Remainder: 1
│
3. Route to: Node 1 (Proxy B)
Grabs the URI string from the incoming HTTP request (e.g.,
/photos/sunset_9921.jpg).Passes it through the hash function. This mathematical formula instantly converts the text string into a large, highly unique integer (e.g.,
3,481,029,552). No matter how many times you run/photos/sunset_9921.jpgthrough the formula, it will always result in3,481,029,552.Maps that number to a server. It performs a quick modulo operation based on the number of active Squid proxies you have. If you have 3 proxies (indexed as 0, 1, and 2):
$$3,481,029,552 \pmod 3 = 0$$The request is immediately routed to Proxy 0.
Because this is pure math, it requires zero memory lookup tables. It works seamlessly for a single URL, 10 million random URLs, or URLs generated dynamically in the future.
The Only Caveat: Changing the Cluster Size
The only time "knowledge" of the system matters is when you add or remove a Squid proxy from your cluster.
With Standard Hashing: If you add a 4th proxy, the modulo math changes from $\pmod 3$ to $\pmod 4$. Suddenly, almost every URL will calculate to a different server index than it did before. Your cache hit rate will temporarily plummet because the load balancer starts looking for files on the wrong proxies (a "cache bust").
The Enterprise Solution: This is why enterprises use Consistent Hashing (like CARP or Ketama). Consistent hashing maps both the URLs and the servers onto a mathematical circle (a hash ring). If you add a 4th proxy, only a small fraction (about 25%) of your cached URLs get reassigned to the new proxy, while the other 75% continue to route to their original, correct proxies.
