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.
