Re: [squid-users] Reverse proxy + larger files

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sat, 04 Jan 2014 18:23:40 +1300

On 4/01/2014 4:01 a.m., pbd_at_pbd.name wrote:
> Hi,
>
> I have setup Squid3 (3.1.19) as a simple caching reverse proxy for some
> web server running on same machine. I have a question about transfering
> larger files when client has slow connection. Is it possible to configure
> Squid to retrieve a file from cache peer with maximum speed, close
> connection to cache peer and then slowly send it to client who has limited
> bandwidth?

That behaviour is part of Squid anti-DoS security protections.
Disabling it turns Squid into a traffic amplifier of vast proportions:
 It only takes a ~52 byte request from client to start a transaction.
If that transaction were Squid downloading a multi-TB object at full
line speed imagine what could happen to your RAM, disk, and network
when a 56K dial modem client can send 1000 such requests per second at
Squid.

What Squid does instead is:

1) cache, so that only one large transfer happens and as many slow
clients as need it can download the cached copy.

2) "collapsed forwarding" where multiple clients can treat cacheable
active downloads as if they were already cached (sadly this is missing
from Squid-3 current stable series, but has been added to the upcoming
3.5 series a few days ago. Try out the 3.HEAD version code to see if
that meets your needs).

3) read_ahead_gap allows the behaviour you describe to be performed on
small or medium sized objects. See the bufferbloat documentation (and
above DoS problem) on why setting this to big amount is a bad idea.
When the client fetches an object bigger than this there is a burst of
fast traffic which slows down after the read_ahead_gap has been reached.

>
> It seems that in default configuration Squid fetches data from cache peer
> with same speed that it is able to send it to client.
>
> Regards,
>
> pbd
>

Amos
Received on Sat Jan 04 2014 - 09:02:47 MST

This archive was generated by hypermail 2.2.0 : Mon Jan 06 2014 - 12:00:04 MST