[squid-users] TProxy and client_dst_passthru

[Amos Jeffries]

On 12/09/2016 3:04 a.m., Omid Kosari wrote:
> 
> I refer to following messages .i have same problem
> 

The "problem" is misunderstanding of the log entry meaning.

> 
> FredT wrote
>> Hi Amos,
>>
>> We have done additional tests in production with ISPs and the ORIGINAL_DST
>> in tproxy cannot be cached.
>> In normal mode (not tproxy), ORIGINAL_DST can be cached, no problem.
>> But once in tproxy (http_port 3128 tproxy), no way, it's impossible to get
>> TCP_HIT.
>>
>> We have played with the client_dst_passthru and the host_verify_strict,
>> many combinaisons on/off.
>> By settings client_dst_passthru ON and host_verify_strict OFF, we can
>> reduce the number of ORIGINAL_DST (generating DNS "alerts" in the
>> cache.log) but it makes issues with HTTPS websites (facebook, hotmail,
>> gmail, etc...).

Nod. That is the purpose of those controls. So they are working.

>> We have also tried many DNS servers (internals and/or externals), same
>> issue.
>>
>> I read what you explain in your previous email but it seems there is
>> something weird.
>> The problem is that the ORIGINAL_DST could be up to 25% of the traffic
>> with some installations meaning this part is "out-of-control" in term of
>> cache potential.

Any server type could be up to 100%. The type of server used implies
nothing about caching potential.

The reverse is true: caching potential implies server type, with
adjustments for traffic mode type and squid.conf settings.

For example:
 HIT implies HEIR_NONE.

 MISS with intercept/tproxy implies ORIGINAL_DST or a peer.
 REFRESH with intercept/tproxy implies ORIGINAL_DST or a peer.

 MISS in forward-proxy implies DIRECT or a peer.
 REFRESH in forward-proxy implies DIRECT or a peer.

> 
> FredT wrote
>> Hi Eliezer,
>>
>> Well, we have done many tests with Squid (3.1 to 3.5.x), disabling
>> "client_dst_passthru" (off) will stop the DNS entry as explained in the
>> wiki, the option directly acts on the flag "ORIGINAL_DST".
>> As you know, ORIGINAL_DST switches the optimization off (ex: StoreID) then
>> it's not possible to cache the URL (ex:
>> http://cdn2.example.com/mypic.png).

ORIGINAL_DST does nothing. It is simply a label indicating which type of
server supplied the HTTP response message for the transaction.

>>
>> In no tproxy/NAT mode, the client_dst_passthru works perfectly by
>> disabling the DNS entry control, so optimization is done correctly.
>> But in tproxy/NAT, the client_dst_passthru has no effect, we see
>> ORIGINAL_DST in logs.
>>
>> So, maybe I'm totaly wrong here the client_dst_passthru is not related to
>> the ORIGINAL_DST,

"client_dst_passthru on" makes Squid use ORIGINAL_DST (client provided)
server instead of DIRECT (DNS lookup) server(s) for *all* intercepted
traffic. Even requests where DIRECT is possible.


> or there is an explaination why the client_dst_passthru
>> does not act in tproxy/NAT...
>>

There is. The "transparent" part of "transparent interception proxy"
means that MISS should use the same server the client was originally
sending its request to (the ORIGINAL_DST server).


>> Bye Fred
> 
> please look at following results 
...
> 
> 60% vs 2% hit ratio(bytes) . The problem is ORIGINAL_DST
> 

The only visible problem is why that 2% exists.

==> ORIGINAL_DST is should *only* ever be used on MISS or
REFRESH/revalidate traffic. Never on a HIT. Thus zero (0%) hit-ratio is
the expected behaviour.

For the same reason that a report of the log traffic using "grep -v HIT"
will show zero cache ratio.

Amos