limit_req_zone limit by location/proxy

[Justin Deltener]

Rolled into production and after tens of thousands of page requests only 3
were smacked down and all were bogus security scanners or "bad dudes"
MISSION ACCOMPLISHED! Thanks a ton Maxim!


On Wed, Nov 13, 2013 at 10:20 AM, Justin Deltener
<jdeltener at realtruck.com>wrote:

> I'll give that a try. I really appreciate your help Maxim!
>
>
> On Wed, Nov 13, 2013 at 10:01 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> Hello!
>>
>> On Wed, Nov 13, 2013 at 09:09:55AM -0600, Justin Deltener wrote:
>>
>> > Aha, that is the lightbulb moment.
>> >
>> > So if we're talking actual rate..which makes sense how would you setup a
>> > scenario with the following requirements.
>> >
>> > You can have whatever rate you want as long as you don't exceed 5 proxy
>> > requests in the same second. I don't care if 5 come within 5ms of each
>> > other.. Hitting 6 total proxy requests in 1 second would kill the
>> request.
>> > It seems we can't really specify that without increasing the rate which
>> in
>> > turn could allow a sustained session with high rates to still have a
>> ton of
>> > requests come in to kill the server.
>>
>> What you are asking about is close to something like this:
>>
>>     limit_req_zone ... rate=5r/s;
>>     limit_req ... burst=5 nodelay;
>>
>> That is, up to 5 requests (note "burst=5") are allowed at any rate
>> without any delays.  If there are more requests and the rate
>> remains above 5r/s, they are rejected.
>>
>> > We're attempting to account for 301 redirects which spawn requests much
>> > faster than normal human requests. I realize we could add a get param to
>> > the url to excuse it from the limit, but that seems a bit out there..
>> >
>> > I also don't quite understand how long a burst rate can be sustained. It
>> > seems one could set the default rate to 1/m and set the burst to
>> whatever
>> > you like..
>> >
>> > Does that make sense?
>>
>> The burst parameter configures maximum burst size, in requests (in
>> terms of "leaky bucket" - it's the bucket size).  In most cases,
>> it's a reasonable aproach to set a relatively low rate, switch off
>> delay, and configure a reasonable burst size to account for
>> various things like redirects, opening multiple pages to read them
>> later, and so on.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
>
> --
>
> Justin Deltener
>
> Nerd Curator | Alpha Omega Battle Squadron
>
> Toll Free: 1-877-216-5446 x3921
>
> Local: 701-253-5906 x3921
>
> RealTruck.com <http://www.realtruck.com/>
>
> Guiding Principle #3<http://www.realtruck.com/about-realtruck/#realtrucks-guiding-principles>:
> Improve
>



-- 

Justin Deltener

Nerd Curator | Alpha Omega Battle Squadron

Toll Free: 1-877-216-5446 x3921

Local: 701-253-5906 x3921

RealTruck.com <http://www.realtruck.com/>

Guiding Principle
#3<http://www.realtruck.com/about-realtruck/#realtrucks-guiding-principles>:
Improve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20131113/c7b2fcbb/attachment.html>