Limiting IP rate: Cyber Security

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:

DescriptionValue
Amount of allowed requests per sec from one IP50
Maximum amount of delayed request40
Status code to return in response to rejected requests555

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.