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

Hey Alex,

Thanks for the words of explanation.
I could think of another situation which the client is pumping the
network in couple TCP layers and WWW(port 80) is not the most
prioritized traffic.
In the above case the client tries again and again to fetch in the TCP
level but the milk is not coming out of the cow that didn't have any..

In a case there is a problematic client I would limit the client SYN
rate if he is a problematic client..
In a case he is a nice client but here and there he has a peak I would
shape his SYN rate into squid only.
In a case he is a nice client and also a non-problematic(99% of the
clients) I would not limit him.
In order to detect problematic clients I would arrange a NETFLOW or any
other way to collect the already exisiting data and make sure that a
shaping and not policy limit will be the one that the client is
suffering from.

How hard would it be to add a Forward proxy the option to send an error
page to a runtime syn\accpet\other limit?
Like a ..counter that will redirect traffic to another server inside
squid??.. iptables can do that in one or two rules while saying the
client "We are sorry but your inter\intra-net usage is weird please
contatct the technical support"

Thanks again,
Eliezer

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:24:17 MDT