This article explains the legacy version of
Rate Limiting restricts the rate of traffic that may be directed to one or more web sites. HTTP/HTTPS requests that exceed a rate limiting policy will not be honored.
Key information:
- Our service inspects all traffic, regardless of delivery platform, when determining whether a rate limiting policy is applicable.
-
A rate limiting policy may be applied to all clients, unique clients, or unique user agentsRefers to software that acts on behalf of a user. For example, a web browser (e.g., FireFox, Chrome, and Internet Explorer) is a user agent. A web browser will make HTTP/HTTPS requests based on user actions (e.g., requesting a web site or clicking a link)..
-
A rate limiting policy may be applied to either of the following:
- All requests
-
Qualified Requests: Use scope and condition groups to define one or more prerequisites (e.g., URL or user agent) that a request must meet before it will count towards the rate limit.
A request will only count towards the rate limit when it satisfies the rule's scope. Additionally, if one or more condition group(s) have been defined, then the request must also satisfy all of the conditions defined within at least one condition group.
- A rate limiting policy does not take into account whether content needs to be requested from an origin server or if a cached version may be served directly from our network.
-
A rate limiting policy is enforced by each edge server according to the approximate number of requests that it receives over the specified time interval (e.g., 1 second, 10 seconds, or 1 minute).
Requests from a single client may be load balanced to different edge servers based on the requested URL.
Scenario 1: Rate Limiting All Requests
This scenario assumes:
- All traffic is directed to a single delivery platform (e.g., HTTP Large).
-
A different edge server is handling each unique request URL.
A single edge server could potentially handle multiple unique request URLs that are eligible for Rate Limiting. In which case, the rate limit would be applied to the aggregate traffic for that content.
The rate limiting policy for this scenario is defined below.
| Policy Setting | Value |
|---|---|
|
Source |
Any request This type of source applies a rate limit to all requests without taking into account the client that submitted each request. |
|
Scope |
Default (Match all hostnames and URL paths) |
|
Rate |
300 requests per minute |
In the above scenario, the CDN received 1200 requests per minute for the following three files:
- Index.html: 600 requests
- Styles.css: 400 requests
- Logo.png: 200 requests
The CDN handled the above requests in the following manner:
-
It honored the following 800 requests:
- Index.html: 300 requests
- Styles.css: 300 requests
- Logo.png: 200 requests
More Information
A rate limit of 300 requests per minute is being enforced on a per edge server basis. Since a different edge server handled each unique URL, the maximum number of requests that could have been honored for each of these assets is 300. Only 200 requests were honored for Logo.png, since it was only requested 200 times within that minute.
-
Our CDN service will randomly apply a predefined rate limiting action (e.g., URL redirection) to the following 400 requests:
- Index.html: 300 requests600 requests per minute - 300 honored requests = 300 rate limited requests
- Styles.css: 100 requests400 requests per minute - 300 honored requests = 100 rate limited requests
- Logo.png: 0 requestsAll requests for Logo.png were honored, since it did not exceed the rate limiting policy.
Scenario 2: Rate Limiting Unique Clients
This scenario assumes:
- All traffic is directed to a single delivery platform (e.g., HTTP Large).
-
A different edge server is handling each unique request URL.
A single edge server could potentially handle multiple unique request URLs that are eligible for Rate Limiting. In which case, the rate limit would be applied to the aggregate traffic for that content.
A rate limiting policy may be applied to each unique client. The rate limiting policy for this scenario is defined below.
| Policy Setting | Value |
|---|---|
|
Source |
IP address This type of source applies a rate limit to all requests from unique IP addresses. |
|
Scope |
Default (Match all hostnames and URL paths) |
|
Rate |
50 requests per minute |
The following diagram illustrates how this rate limiting policy controls the total number of requests that may flow through our network.
In this scenario, only requests originating from one of the clients will be rate limited. Specifically, only that client's requests for Index.html and Styles.css will be rate limited. All other requests will be honored, since they don't exceed the defined rate limit (i.e., 50 requests per minute).
Aggregate traffic is not taken into account when rate limiting unique clients. For example, this rate limiting policy would not be enforced on 2,000 clients if they only issued 5 requests per minute. Although aggregate traffic exceeded the rate limiting policy, no single client exceeded 50 requests per minute.
Scenario 3: Multiple Rate Limiting Policies (Rules)
This scenario assumes:
- All traffic is directed to a single delivery platform (e.g., HTTP Large).
- A single edge server is handling all traffic.
A Rate Limiting configuration may contain multiple rate limiting policies (i.e., rules) that define a custom rate limit for different types of requests. Rate Limiting will process these rules in the order in which they are listed. Once a rule is satisfied, it will be applied to the request and no additional rules will be processed.
It is recommended to order rules according to how they identify requests. Stricter rules that identify requests using multiple conditions should be placed closer to the top of the list, while catch-all rules should be placed closer to the bottom. This ensures that rules are applied to requests as intended.
The rate limiting policy for this scenario is defined below.
| # | Rate Limiting Policy (Rule) |
|---|---|
| 1 |
Source: IP address Scope: Default (Match all hostnames and URL paths) Rate Limit: 200 requests per minute
Match Conditions: Host = cdn.mydomain.com & Request URL = /sales/index.htm  View Details
Match Condition #1:
Match Condition #2:
Action: Redirect (HTTP 302) |
| 2 |
Source: IP address Scope: Default (Match all hostnames and URL paths) Rate Limit: 200 requests per minute
Match Condition: Host = cdn.mydomain.com View Details
Action: Drop request |
|
3 |
Source: Any request Scope: Default (Match all hostnames and URL paths) Rate Limit: 500 requests per minute Match Condition: None Action: Redirect (HTTP 302) |
This sample scenario examines how the following requests will be affected by Rate Limiting.
Although the majority of the following requests satisfy multiple rules, only the first rule that a request violates will be applied to it.
| Request | Rule |
Description |
|---|---|---|
|
Client: 100.10.20.33 Request rate: 350 per minute Request URL: http://cdn.mydomain.com/sales/index.htm
|
1 |
Action: Approximately 200 requests will be honored, while approximately 150 requests will be redirected. Why? All of these requests satisfy the first rule. As a result, the subsequent rules (i.e., second and third rules) are skipped. |
|
Client: 101.10.20.44 Request rate: 300 per minute Request URL: http://cdn.mydomain.com/marketing/index.htm
|
2 |
Action: Approximately 200 requests will be honored, while approximately 100 requests will be dropped. Why? These requests do not meet the conditions defined for the first rule. However, they do satisfy the second rule. As a result, the subsequent rule (i.e., third rule) is skipped. |
|
Client: 102.10.20.55 Request rate: 250 per minute Request URL: http://cdn.mydomain.com/sales/index.htm
|
1 |
Action: Approximately 200 requests will be honored, while approximately 50 requests will be redirected. Why? All of these requests satisfy the first rule. As a result, the subsequent rules (i.e., second and third rules) are skipped. |
|
Client: 102.10.20.55 Request rate: 450 per minute Request URL: http://cdn2.mydomain.com/sales/index.htm
|
3 |
Action: All 450 requests will be honored. Why? These requests do not meet the conditions defined for the first or second rule. However, the third rule is applicable, since it is a catch-all rule that applies to all requests. Although the total number of requests from all clients exceeds 500 requests per minute, only the 450 requests submitted by this client are eligible for rate limiting by the third rule. Therefore, the rate limit defined in the third rule is not being exceeded. Notice that a different rate limiting policy is applied to these requests, even though they originate from the same client (i.e., 102.10.20.55). |