Re: [squid-users] Re: can squid load data into cache faster than sending it out?

On Thu, May 12, 2011 at 01:37:13PM +1200, Amos Jeffries wrote:
> On 12/05/11 08:18, Dave Dykstra wrote:
...
> >> So its a choice of being partially vulnerable to "slow loris" style
> >>attacks (timeouts etc prevent full vulnerability) or packet
> >>amplification on a massive scale.
> >
> >Just to make sure I understand you, in both cases you're talking about
> >attacks, not normal operation, right? And are you saying that it is
> >easier to mitigate the trickle-feed attack than the packet-amplification
> >attack, so trickle-feed is less bad? I'm not so worried about attacks
> >as normal operation.
> >
>
> Both are real traffic types, the attack form is just artificially
> induced to make it worse. Like ping-flooding in the 90's it happens
> normally, but not often. All it takes is a large number of slow
> clients requesting non-identical URLs.
>
> IIRC it was noticed worse by cellphone networks with very large
> numbers of very slow GSM clients.
> A client connects sends request, Squid reads back N bytes from
> server and sends N-M to the client. Repeat until all FD available in
> Squid are consumed. During which time M bytes of packets are
> overflowing the server link for each 2 FD used. If the total of all
> M is greater than the server link size...
>
> Under the current design the worst case is Server running out of FD
> first and reject new connections. Or TCP protections dropping
> connections and Squid aborting the clients early. The overflow
> factor is 32K or 64K linear with the number of FD and cant happen
> naturally where the client does read the data just slowly.

With my application the server has a limit on the number of parallel
connections it has to its backend database, so there is no danger of
overflowing the bandwidth between the reverse-proxy squid and its server
(also, they're on the same machine so the "network" is intra-machine).
If there are many clients that suddenly make large requests they are put
into a queue on the server until they get their turn, and meanwhile the
server sends keepalive messages every 5 seconds so the clients don't
timeout. With my preferred behavior, the squid would read that data
from the server as fast as possible, and then it wouldn't make any
difference to the squid-to-server link if the clients had low bandwidth
or high bandwidth.

I'll submit a feature request for an option to bugzilla.

Thanks a lot for your explanations, Amos.

- Dave
Received on Thu May 12 2011 - 14:18:41 MDT