On 12/14/2011 11:55 PM, Amos Jeffries wrote:
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
I set up monitoring for many of the stats pulled from 'squidclient
mgr:info' and I'm wondering what is considered healthy for the dns
response times?
Thanks,
Elvar
