If your users do not mind, you can block ads and user tracking
sites of which many produce 1x1 gifs.
Most ads and tracking codes are not cacheable and may consume a lot.
This all depends on which sites your users visit of course.
Marcus
Amos Jeffries wrote:
> On 31/03/11 01:38, Ed W wrote:
>> Hi, Just investigating some tuning for squid for use with satellite
>> links (which are relatively slow + bandwidth can be charged at
>> $10-100/MB)
>>
>> I'm pondering having a dual proxy configuration with a proxy at both
>> ends of the satellite link. A desired goal would be to force serving
>> from local cache anything which hasn't actually changed (byte for byte)
>> on the internet side.
>>
>> My thought was to investigate having the internet side proxy add etag
>> headers to all content based on some quality hash function. Then have
>> the (expensive) remote side proxy rewrite the request headers to always
>> use If-None-Match? The idea is that the bandwidth is cheap on internet
>> connected side, so it can refresh it's cache of the whole page, generate
>> a new hash, but still return a "not modified" response if the end result
>> is the same string of bytes. How much of that can I implement in Squid
>> 3.x today..?
>
> 3.1.10+ will validate If-None-Match and ETag, but will not add them to
> requests itself.
>
>>
>> Note, I realise this could lead to some side effects where the action of
>> visiting the web page itself causes some other side effect, however, I
>> think this is a manageable problem for this requirement?
>>
>> Thanks for any pointers to ideas or other products that might help?
>
> ICAP or eCAP would be the way to go here for quick results. Making a
> plugin to do the ETag generation and alterations before sending off.
>
> You could also look at cutting bodies off 304 replies at the Internet
> side to avoid the bandwidth expensive TCP_REFRESH_UNMODIFIED responses.
>
> NP: if you want to go ahead and alter Squid code adding If-None-Match on
> outbound requests is an open bug. As is proper ETag variant caching
> support.
>
> Amos
Received on Wed Mar 30 2011 - 18:17:10 MDT
This archive was generated by hypermail 2.2.0 : Fri Apr 01 2011 - 12:00:02 MDT