Limit connections per IP (patch)

I would agree, a feature/module to limit connections per IP/given time would be of great use.

I hope to see this feature soon, it is especially useful when serving a high traffic server and to prevent hotlinking, etc.

I too am interested in limiting connections per IP, please add this function!

Also voting for this one, would make a huge difference for us

I'd like to see this too ;)

Check this out! :) http://trac.lighttpd.net/trac/ticket/195

evasive doesn't allow anything but refusing the request entirely; it's not a good solution for most uses. Instead, mod_throttle.

• each configuration block defines a simple token bucket and maximum concurrency
• token bucket allows limiting the rate of requests; maximum concurrency limits the number of simultaneous requests

• requests beyond limits are simply delayed; when a request finishes, the next one(s) are started in a roughly FIFO manner

• multiple blocks can be configured.

The original purpose of this is for limiting expensive requests; in our case, we wanted to allow only 2-3 concurrent Rails requests per second. Since Rails servers are 50-100 megs a piece, a reliable server can't let a single user monopolize them, and our application allows several long-running requests which can hold one up for several seconds.

At the same time, we can limit the number of large simultaneous file downloads to, say, 2. This doesn't break download managers; if they start a lot of threads on the same file, two will start and the rest will simply block until others finish (though in practice the client will probably time them out and restart them; this is harmless).

Token buckets are the normal paradigm: you start with a specified number of tokens, each request uses one token, and the tokens refill back to the max at a specified rate. This gives some flexibility in limiting the connection rate, by allowing bursts of activity to avoid affecting responsiveness. Each rule has its own separate token buffer, so you can give different limits to different things (eg. pages of thumbnails may need to allow more rapid requests than Rails requests).

Any rule can be defined as a "ban" rule; if a request in the rule is denied, the IP is banned for a specified length of time (all requests are refused).

Lighttpd's configuration syntax makes this a bit of a hack in cases. Each configuration conditional becomes a separate rule, so to set up two independent rules on the same conditional (eg. a throttle rule and a ban rule), you need to use different conditionals or the configurations will be merged: $HTTP/url? =~ "/requests" {

throttle.max-concurrent-connections = 3

} $HTTP/url? =~ "/requests|abcdefg" {

throttle.bucket-size = 300 throttle.tokens-per-second = 1 throttle.ban-when-empty = 1

}

This also adds the $HTTPorigurl? conditional, which exposes con->request.orig_uri. This is needed to match against the real request when using error-handler-404 for fcgi requests; otherwise only the redirected URL can be matched.

This could probably use more cleaning up, but with another ticket I've opened with a simple patch not getting a reply in three weeks (#1675), I don't really expect this big one to be applied (is development dead?)--I'm just making this available to people who google their way here. Patch is in the public domain (merge it if you like); this code has been live on a medium-traffic site for several weeks and seems stable. Patch doesn't add documentation.

tokens-per-second should refill smoothly; 2 should start a new connection every half second, not two connections every second. There's no timer interface to do this and I don't need it right now.

One significant limitation: if a client starts an expensive Rails request, and then closes the connection, the connection closure is not communicated to Rails, so the expensive request will continue but the user will get his parallel connection back and can start another. Whether this is a lighttpd fcgi bug or a Rails bug or somewhere in between I'm not sure; fcgi does specify how to communicate dropped connections, and it's important that Rails code be able to catch a signal of some kind (eg. a callback that can return or throw) to decide whether or not to continue with the request after the client has disappeared.

(There's no good reason for this code to be C instead of C++, which would make it substantially simpler, and make it trivial to use better data structures for some of the data, which would make it faster; I can't be bothered to do that in C and it's fast enough for my use.)