Re: [squid-users] Re: cache peer communication about HIT/MISS between squid and and non-squid peer

On 07.05.2012 07:15, x-man wrote:
> Amos Jeffries-2 wrote
>>
>> On 02.05.2012 03:12, x-man wrote:
>>> Hello,
>>>
>>> I have this question:
>>>
>>> If you have squid, that is working as intercept proxy for
>>> customers,
>>> has
>>> parent cache_peer (non-squid), who is not talking ICP or HTCP
>>> procols, and
>>> is only dealing with part of the content.
>>>
>>> How this parent cache_peer will communicate to the main SQUID about
>>> if the
>>> request is MISS or HIT, as I want the main squid to apply packet
>>> mark for
>>> the HIT traffic.
>>>
>>> Or the marking should be done on the cache peer level?
>>
>> It is best done at the node which has all the information. Things
>> are
>> not really as simple as HIT/MISS.
>>
>> You will also need TOS pass-thru features enabled in the kernel to
>> propigate the TOS from the squid-upstream packets to the
>> client(s)-squid
>> packets. Although in you could also map the upstream TOS to a
>> netfilter
>> MARK value and pass it through Squid then map it to TOS value on the
>> other connection(s).
>>
>> Amos
>>
>
>
> If I mark the packets from the cache_peer with netfilter mark, will
> the
> squid preserve it? In this case do I need some kernel
> modifications?!?

If it was MARK'd on the same machine,the new netfiler MARK extensions
to ZPH QoS will preserve it same as they do for TOS preserving. But
without needing kernel patching and custom Squid build like TOS preserve
does so far.

>
> I wonder if there is any simple way that the cache_peer will tell the
> MAIN
> squid that this is HIT and the main squid (who is replying to the
> customers)
> will MARK it with proper TOS? Any way.. be it with protocol or not.

The conceptual problem is that HIT/MISS is *only* a terminology
distinction relative to the particular cache doing the processing. There
may be multiple caches involved and a request might be a HIT on one of
them and MISS on all the others. Everything is a HIT on origin servers,
but may be a HIT or MISS on surrogate servers (reverse proxy).

Taking the idea to its conclusion everything is therefore a HIT,
because at some point down the chain it was a HIT.

I know you have a simpler usage case where things are clearer, but the
above should help explain why this is a hard problem for Squid to "just"
have a config for.

Waking up;
   fully internally to Squid we have the X-Cache: header at present
being emitted with HIT/MISS details. You may be able to setup a
rep_header_regex ACL the scans for HIT and your upstream cache name.
Used on tcp_outgoing_tos to set TOS value. This is not a completely
reliable header though, there will be some false matches or failures
using it at present and future plans are to remove it from most traffic.

Amos
Received on Sun May 06 2012 - 22:31:17 MDT