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
