RE: [squid-users] Pessimal behavior with Windows Update (Long)

> -----Original Message-----
> From: Brett Glass [mailto:squid-users@brettglass.com]
> Sent: Monday, June 27, 2005 4:00 PM
> To: Squid-users@squid-cache.org
> Subject: [squid-users] Pessimal behavior with Windows Update (Long)
> Importance: High
>
>
> Everyone:
>
> Here, at last, is the long message I promised regarding the
> problems I've observed with Squid, Windows Update, and other
> services which fetch large files (in particular, software patches)
> via HTTP (including Intuit's update mechanism for Quickbooks). I've
> dashed it off in a hurry between installation appointments for my
> wireless ISP, so please forgive any typos, grammatical mistakes, or
> similar errors.
>

I cut out the description of the problem to make this a little shorter... I
don't have too much to add, but that has never stopped me from
"contributing" in the past.

>
> Proposed solutions
>
> The following improvements to Squid could greatly improve
> administrators' ability to cache Windows Update (and other similar
> updates) without the deleterious effects mentioned above.
>
> 1. Modify Squid so that before it attempts to prefetch an entire
> object in response to a range request, it first checks the size of
> the object against "maximum_object_size". It should also perform
> all the other checks it normally performs to determine whether an
> object is cacheable (including evaluation of the ACLs, if any, used
> with the "no_cache" parameter). If the entire file is not cacheable
> for any reason whatsoever, the range request should be passed
> through verbatim. (This seems like common sense, but it is
> apparently not done now.)
>
> 2. Allow the "maximum_object_size" parameter to be selected, for
> each transfer, via an ACL. (Fortuitously, the standard syntax of
> the Squid configuration file both allows this and provides backward
> compatibility in the case where no ACL is specified. See the
> "tcp_outgoing_address" parameter, which acquired the ability to use
> ACLs only recently and is backward compatible with configuration
> files that don't exploit this new capability.) With this
> modification, an administrator could allow the caching of large
> Windows Update files but not large files from other sources.
>
> 3. If a range transfer is to be expanded into a transfer of the
> entire file, exempt the transfer from the "quick_abort" mechanism.
> (After all, it's normal for the client to disconnect after it
> receives the data it has requested.)
>
> 4. Encourage Microsoft to modify Windows Update so that it can
> "discover" a server on which updates are preloaded or cached.
> Currently, SUS and WUS require modification to a client machine's
> registry; this is practical for organizations with IT staffs but
> not for ISPs. An ISP should be able to run a Web cache, FTP server,
> or Web server to which Windows updates are downloaded once and then
> distributed downstream. Microsoft has a financial incentive to do
> this, because its updates are currently distributed through Akamai
> (which undoubtedly charges it by the bit for downloads). Alas, we
> can't hold our breath waiting for Microsoft to do such a thing.
> Therefore, the modifications to Squid mentioned above are essential
> to providing an efficient solution -- not only to Windows Update
> issues but also to issues with similar updating systems from Intuit
> and other software vendors.

5. Set up a separate "big file" proxy (could just be a second squid instance
on the same box) that caches large requests. Set the main proxy server to
only cache files of a "sane" size. Use the "big file" proxy as a parent for
said domains (never_direct and always_direct would manage this). Not
optimal, perhaps not even pretty, but it will save you from caching 400MB of
streaming music.

>
> The first three of these items should be implemented as soon as
> possible, so that administrators of Squid caches can safely cache
> Microsoft's updates. Now that the largest of these have grown to
> more than 700 megabytes, the need is urgent.
>
> --Brett Glass
Received on Tue Jun 28 2005 - 16:08:53 MDT