On 15/12/2011 6:46 p.m., Elvar wrote:
>
>
> On 12/14/2011 11:38 PM, Amos Jeffries wrote:
>> On 15/12/2011 5:53 p.m., Elvar wrote:
>>>
>>>
>>> On 12/14/2011 10:46 PM, Amos Jeffries wrote:
>>>> On 15/12/2011 3:29 p.m., Elvar wrote:
>>>>> Hello,
>>>>>
>>>>> I'm running Squid & Dansguardian in several environments and the
>>>>> environment using transparent proxy mode is suffering from a
>>>>> severe delay in loading a page. Once the page starts to load it is
>>>>> quick but the initial load is severely delayed. When I switched
>>>>> from transparent to NTLM auth, surprisingly the delay is
>>>>> completely gone. I'd think it would be the other way around
>>>>> honestly. I'm not sure how to resolve this but any suggestions
>>>>> would be greatly appreciated.
>>>>
>>>> "transparent" is a confusing word. Particularly more so since you
>>>> say you changed from "transparent proxy" to one of the forms of
>>>> "transparent authentication".
>>>>
>>>> To clarify what you were meaning:
>>>>
>>>> Was your "transarent proxy" setup using?
>>>> NAT intercept?
>>>> TPROXY intercept?
>>>> WPAD?
>>>> Basic auth SSO?
>>>> Digest auth SSO?
>>>> Negotiate/Kerberos auth SSO?
>>>> OAuth?
>>>> or an external ACL helper doing out-of-band auth tests?
>>>>
>>>> Amos
>>>
>>> By transparent, I mean I'm using iptables to redirect outbound HTTP
>>> through Dansguardian. My iptables rule is below
>>>
>>> '#$IPT -t nat -A PREROUTING -i $LAN_IF -p tcp -s $LAN --dport 80 -j
>>> REDIRECT --to-port 8080'
>>>
>>> When I'm using this there seems to be more of a delay loading sites
>>> vs. configuring web browsers to connect to the proxy directly and
>>> authenticate using NTLM & winbind. When I use the iptables redirect
>>> rule I have authentication off. In general, what are some things I
>>> should check as to why / what may be causing the sites to load slow?
>>>
>>
>> Thank you.
>>
>> So with intercept the client performs DNS to locate the server to
>> connect to, iptables maintains a lot of state tracking, and Squid
>> duplicates the DNS lookups when it repeats the server locating.
>> Possibly also the client may be attempting to use a slightly
>> different level of HTTP/1.1 features (such as Expect: 100-continue)
>> which may be adding failures and/or timeouts to the transaction.
>>
>> With explicit configuration the client performs NTLM handshake. Most
>> browsers detect and "dumb-down" their HTTP feature use to match teh
>> suprot level of the proxy automatically.
>>
>> Speed is relative to DNS lookup time on the client, the NTLM
>> handshake time, and whether teh client browser attempts HTTP/1.1
>> features by default. Remembering that Squid is pooling the DNS
>> lookups from all clients, whereas each client is doing their own
>> individual requests and gets hit worse with lag.
>>
>> Amos
>
> Thank you for the detailed response. So my next question is, can I do
> anything to improve the performance with transparent filtering?
Possibly. You need to track down which of those (DNS lag or HTTP
features) is the cause and find some way to eliminate it. On the DNS
side that means usually having a shared resolver between Squid and the
clients (first lookup will cache the DNS results locally for a faster
repeat). On the HTTP feature side that usually means upgrading Squid and
maybe tweaking the browser config up/down to whatever HTTP level matches
the proxy.
Amos
Received on Thu Dec 15 2011 - 05:55:39 MST
This archive was generated by hypermail 2.2.0 : Thu Dec 15 2011 - 12:00:03 MST