> -----Original Message----- > From: Brett Glass [mailto:squid-users@xxxxxxxxxxxxxx] > Sent: Monday, June 27, 2005 4:00 PM > To: Squid-users@xxxxxxxxxxxxxxx > Subject: 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
