----- Original Message -----
From: "Nils Holland" <nils@tisys.org>
To: "Paul Stewart" <pauls@nexicom.net>
Cc: "'squidlist'" <squid-users@squid-cache.org>
Sent: Friday, October 19, 2001 1:29 AM
Subject: Re: [squid-users] Compression
> On Thu, 18 Oct 2001, Paul Stewart wrote:
>
> > Is there a way that content served via the cache could be gzipped on
the
> > fly? Perhaps it's already possible and I am not aware of it? My
> > opinion would be that this is a win/win scenario with the cache
speeding
> > up delivery of content to the browser, saving bandwidth on the
backbone
> > connections, and also delivering the content even faster to the
browser
> > (especially a dial-up user).
>
> Actually, just for the sake of completeness: Dial-up connections use a
> on-the-fly compression known as V.42bis. Using this method, data is
> compressed on it's way over the phone line.
>
> Your suggestion may still be wise, I just wanted to point out that
adding
> gzip compression to Squid will probably not make much of a difference
to
> dial-up users, as their data is already being compressed when it
passes
> through the bottleneck (=phone line).
>
It's worth noting that compressing a single data stream of related data
will achieve higher compression ratios that compressing the link layer
of a multiplexed data stream.
V.42bis and it's predecessors are great for terminal access and things
like kermit or zmodem point to point dedicated transfers, they are not
so great at handling the ppp around ip around tcp around the data
pattern that you see with internet connections.
Consider a user checking mail and downloading a single file
concurrently. Even this simple -and common AFAIK- example will drop the
effectiveness of link compression.
IIRC some modem tuning sites recommend modem compression be turned of
for internet links for this exact reason.
Rob
Received on Thu Oct 18 2001 - 17:19:46 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:02:52 MST