DescriptionLimiting IP rate: Cyber Security
This article will help you to understand how IP Rate Limiting works.
Let's assume we have the following settings:
|Amount of allowed requests per sec from one IP||50|
|Maximum amount of delayed request||40|
|Status code to return in response to rejected requests||555|
Your baseline is 50 requests per second (RPS). This means anything that is coming from a single IP, during a 1 second interval, with 50 RPS or less would be processed without any restrictions.
To account for traffic bursts we are using a second value - 40. This is your buffer size i.e: 40 requests that would be stored in the buffer and processed with some delay.
To summarize: at 50 RPS you should not be noticing any difference in request processing. At 51-90 RPS you would experience some delays. Anything above 90 RPS would get dropped with a 555 error. Use code 444 to prevent sending any response back to the front-end.
You can also set the buffer size to 0 and that would mean that anything above 50 RPS from a single IP, during a 1 second interval, would be dropped with a 555 error.
Things to keep in mind:
- Initially it would make sense to set some error code (e.g: 555) so you could get feedback from real users in case your configured values are too low. Please note that the error code 444 does not send a response to the front-end.
- AJAX heavy apps are very chatty in terms of RPS. Therefore, finding the optimum RPS value might take some experimenting and time.
- Users behind proxies could be coming with the same IP. Therefore, finding the optimum RPS value might take some experimenting and time.