I don't know the clients ipaddresses before hand (in case that matters). On Sun, Jan 8, 2012 at 5:24 PM, Baptiste <bed...@gmail.com> wrote:
> Hi, > > You can do this with a stick-table and a "store conn_rate(60s)". > Then with an ACL, you can trigger decision based on the conn_rate value: > acl abuser src_conn_rate gt 100 > block if abuser > > So the 101st request and above in a minute would be blocked. > > cheers > > > On Sun, Jan 8, 2012 at 10:53 PM, S Ahmed <sahmed1...@gmail.com> wrote: > > Actually my requirements are as follows: > > > > To block all further connections if they make more than 100 api calls in > a > > given minute. > > > > So if they make 100 api calls in the span of 55 seconds, block all > further > > calls for the next 5 seconds. > > > > Can I do this? And if I do, it should limit my bandwidth then correct? > > > > > > On Sun, Jan 8, 2012 at 2:24 AM, Willy Tarreau <w...@1wt.eu> wrote: > >> > >> On Sat, Jan 07, 2012 at 07:11:02PM -0500, S Ahmed wrote: > >> > I was reading this: > http://blog.serverfault.com/2010/08/26/1016491873/ > >> > > >> > A bit confused, the link to the src is version 1.5 but version 1.4 > seems > >> > to > >> > have a modified date of sept 2011 while 1.5 is august 2010. > >> > >> The most recent 1.5 dates September 10th 2011 (1.5-dev7). There is no > >> need to compare 1.4 and 1.5 release dates, as 1.5 is the development > >> branch and 1.4 is the stable branch. So new 1.4 versions are released > >> when bugs are discovered, regardless of the 1.5 development cycle. > >> > >> > Is this an addon module or? Is it being maintained? > >> > >> 1.5 is still in active development, but since the development is not > >> fast, we try to ensure good stability for each new development release > >> so that people who rely on it can safely use it. > >> > >> > Ok my main question is this: > >> > > >> > When a given ipaddress is rate limited and connections are dropped, > how > >> > exactly is this happening? Will it drop the connection during the > TCP > >> > handshake and as a result only the http header will be sent from the > >> > client > >> > and not body? > >> > >> Connections are not necessarily dropped. You can drop them, you can send > >> them to a specific backend, you can delay them, you have various > options. > >> You can match an IP's connection rate using an ACL and you can do many > >> things using ACLs. What is not doable at the moment (delayed to 1.6) is > >> to shape the traffic. > >> > >> > I'm using this where clients are sending http requests and they don't > >> > really have control over it, so I have to rate limit them as best as I > >> > can. > >> > With this rate limiting, will this save be bandwith also since I don't > >> > have > >> > to rate limit at the application level? > >> > >> Well, you have to undestand that however you do it, rate limiting does > not > >> save bandwidth but *increases* bandwidth usage : whether you force to > send > >> smaller packets or you drop and force to retransmit, in the end for the > >> same > >> amount of payload exchanged, more packets will have to be exchanged when > >> the > >> traffic is shaped. Rate limiting must not be used to save bandwidth, but > >> to > >> protect servers and to ensure a fair share of the available bandwidth > >> between > >> users. > >> > >> > i.e. b/c at the application level I > >> > have to load the header and body to determine if I should reject the > >> > request. > >> > >> If you want to act on connections, in my opinion the best solution would > >> be to only delay those who are abusing. Basically you have two server > >> farms > >> (which can be composed of the very same servers), one farm for normal > >> users > >> and the other one for abusers. The abusers one has a very small limit on > >> concurrent connections per server. Once a user is tagged as an abuser, > >> send > >> it to this farm and he will have to share his access with the other ones > >> like him, waiting for an available connection from a small pool. This > will > >> also mechanically make his connection rate fall, and allow him to access > >> via the normal pool next time. > >> > >> What is recommended is also to consider that above a certain rate, > you're > >> facing a really nasty user that you want to kick off your site, and then > >> you drop the connection as soon as you see them on the doorstep. > >> > >> > (Ok as I wrote this it seems the link from the blog entry is to > haproxy > >> > itself, so this is built in the core?) > >> > >> Yes, this is built in 1.5-dev. You can download 1.5-dev7 or even the > >> latest daily snapshot and you'll get that. > >> > >> Willy > >> > > >
