[aklug] Re: GCI, ond others, bandwith restrictions

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Thu Oct 21 2010 - 09:09:30 AKDT

On Thu, 21 Oct 2010, Jeremy Austin wrote:

> I used to cache MS updates, but unfortunately can't remember why I
> stopped. I remember it was a pain, though. Apple updates I am
> definitely considering; they're fairly large, and our percentage of
> Macs is only rising.

If you ran into problems with MS updates I'd like to know what it was.
Given the problems with MS to begin with, I think the last thing we want to
do to the world is make it harder for them to plug all those holes. ;-)

> What does dropping GET queries do? How does that work?

I wasn't entirely clear. We're not "dropping" GET queries altogether, we're
just dropping them from being eligible for caching, regardless of what the
content expiration headers say. We treat all queries as dynamic content.

> With MS updates, an external redirector used to be needed. Squid 2.7
> and 3 have introduced several new options for overriding refresh
> times, so I need to research that again.

Yeah, 3.x had some major changes which were nice, but, then they also
stopped doing some basic sanity checks that were hard coded in 2.x. Ran
into a real nasty looping issue that required explicit ACLs to handle
requests which basically DoS'd the cluster.

> For streaming flash video, I'm testing a commercial squid redir from
> cachevideos.com, which again is an external redirector. So far so
> good.

I'll have to look into that. We've written our own redirectors, but
anything that increases cache coherency is a good thing.

> For organizations that are large enough to enforce use of a PAC file
> (Proxy Auto Configuration), squid is a fairly viable option.
> Transparent proxying (with disclosure) is easier to maintain, though.
> Either way, there are some badly written sites and clients that have
> never worked through squid (Microsoft Sharepoint, I'm looking at you.
> Google Android, I'm looking at you.) Be prepared to keep a
> non-proxyable whitelist.
>
> I have done squid peering via ICP with one of my upstream providers,
> but only when multiple ISPs were available. At one point when I had
> some bandwidth from AT&T they were transparently proxying all my
> outbound traffic on port 80. Boy was it was messy, with no recourse!

We do do that, but not without recourse. We've always had ways of bypassing
it should it break a site or if a customer want no content filtering, etc.,
at all.

> As with anything that adds a layer of complexity to your network that
> can't be bypassed, be prepared to have it break in interesting ways.

We deal with that all the time. Normally, though, it's just a really poorly
written web app that doesn't like it. You'd be amazed at the number of
sites ignoring well established RFCs.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Thu Oct 21 09:09:45 2010

This archive was generated by hypermail 2.1.8 : Thu Oct 21 2010 - 09:09:45 AKDT