Re: [squid-users] Has anyone heard about this option??

On 10/09/2013 03:24 PM, Eliezer Croitoru wrote:

> In a case there is a problematic client I would limit the client SYN
> rate if he is a problematic client..

SYN rate? The malicious client in question sends only one SYN packet
because it only needs one HTTP connection to kill Squid. If there is no
read ahead gap limit, one HTTP request is enough to consume all
available RAM on the Squid box.

> How hard would it be to add a Forward proxy the option to send an error
> page to a runtime syn\accpet\other limit?

If client usage information is available somewhere, then one can use an
external_acl_type or eCAP/ICAP to block or redirect that client. No new
options are needed.

Cheers,

Alex.

> On 10/09/2013 11:42 PM, Alex Rousskov wrote:
>> The buffer is needed regardless of the network speeds. Relatively slow
>> (compared to the server) client network may indeed require larger
>> buffers for better performance, but there are other factors affecting
>> optimal buffer sizes.
>>
>> In one extreme case, consider a malicious client requesting an
>> infinite-size object from a fast server while reading just 1 byte every
>> minute to keep the transaction alive. Without the buffer size limit,
>> your pool will soon overflow. The opposite extreme is a client so slow
>> or so poorly connected that it cannot fetch the response before the
>> origin server times out. Both cases occur in real deployments.
>>
>> Squid could hard-code the maximum buffer size (i.e., the read ahead
>> gap), but deployment environments differ, and sooner or later somebody
>> would want a different size value. That is why it is a configuration
>> option.
>>
>>
>> HTH,
>>
>> Alex.
Received on Wed Oct 09 2013 - 21:38:09 MDT