Squid_ The Definitive Guide - Duane Wessels [101]
Squid looks at the always_direct list first. If the request matches this list, the direct flag is set to DIRECT_YES.
Squid looks at the never_direct list next. If the request matches this list, the direct flag is set to DIRECT_NO.
Squid has a special check for requests that appear to be looping. When Squid detects a forwarding loop, it sets the direct flag to DIRECT_YES to break the loop.
Squid checks the minimum_direct_hops and minimum_direct_rtt settings, but only if you've enabled netdb. If the measured hop count or round-trip time is lower than the configured values, Squid sets the direct flag to DIRECT_YES.
If none of the previous conditions are true, Squid sets the direct flag to DIRECT_MAYBE.
If the direct flag is set to DIRECT_YES, the selection process is complete. Squid forwards the request directly to the origin server and skips the remaining steps in this section.
Step 2: Neighbor Selection Protocols
Here Squid uses one of the hierarchical protocols to select a neighbor cache. As before, once Squid selects a neighbor in this step, it exits the routine and proceeds to Step 3. This step roughly corresponds to the peerGetSomeNeighbor( ) function:
Squid examines the neighbor's Cache Digests. If it indicates a hit, that neighbor is placed on the next-hop list.
Squid tries CARP if enabled. CARP always succeeds (i.e., selects a parent), unless the cache_peer_access or cache_peer_domain rules forbid communication with any of the parent caches for a particular request.
Squid checks netdb measurements (if enabled) for a "closest parent." If Squid knows that the round-trip time from one or more parents to the origin server is less than its own RTT to the origin server, Squid selects the parent with the least RTT. For this to happen, the following conditions must be met: Both your Squid and the parent cache(s) must have enabled netdb measurements.
query_icmp must be enabled in your configuration file.
The origin server must respond to ICMP pings.
The parent(s) must have previously measured the RTT to the origin server and returned those measurements in ICP/HTCP replies, or through a netdb exchange.
Squid sends ICP/HTCP queries as the last resort. Squid loops through all neighbors and checks a number of conditions. Squid doesn't query a neighbor if: The direct flag is DIRECT_MAYBE and the request is nonhierarchical (see Section 10.4.5). Because Squid is allowed to go directly to the origin server, it doesn't bother the neighbor with this request, which is likely to be uncachable.
The direct flag is DIRECT_NO, the neighbor is a sibling, and the request is nonhierarchical. Because Squid is forced to use a neighbor, it only queries parents, which can always handle a cache miss.
The cache_peer_access or cache_peer_domain rules forbid sending this request to the neighbor.
The neighbor's no-query flag is set, or its ICP/HTCP port number is zero.
The neighbor is a multicast responder.
Squid counts how many queries it sends and calculates how many replies to expect. If it expects at least one reply, the rest of the next-hop selection procedure is postponed until the replies arrive, or a timeout occurs. Squid expects to receive replies from neighbors that are alive, but not neighbors that are dead (see Section 10.3.2).
Step 2a: ICP/HTCP Reply Processing
If Squid sends out any ICP or HTCP queries, it waits for some number of replies. Just after transmitting the queries, Squid knows how many replies to expect and the maximum amount of time to wait for them. Squid expects a reply from every alive neighbor queried. If you're using multicast, Squid adds the current group size estimate to the expected reply count. While waiting for replies, Squid schedules a timeout, in case one or more of the replies don't arrive.
When Squid receives an ICP/HTCP reply from a neighbor, it takes the following actions:
If the reply is a hit, Squid forwards the request to that neighbor immediately. Any replies arriving after this point are ignored.