Table of contents
Principle: Token Bucket Algorithm
basic introduction
In a high-load network environment, in order to maintain the stability of the service, speed limit (download rate) is a necessary method to control the traffic volume. Nginx is a high-performance web server and reverse proxy server that can use the two main instructions limit_rate_after and limit_rate to achieve traffic control and speed limiting.
As one of the three major functions of NGINX traffic management, bandwidth control is relatively simple to implement. It only implements bandwidth control on a single connection, and is often used together with rate control and concurrency control to implement client traffic management.
From the perspective of NGINX architecture, the entire life cycle of a single connection is processed in a separate worker process. Therefore, bandwidth control does not require sharing and synchronizing data between worker processes. There is no need to define a shared memory zone to share and synchronize data like rate control and concurrency control. Based on this, the bandwidth control instructions do not have the instructions to define the shared memory area required for rate control and concurrency control.
Command configuration
limit_rate
The limit_rate command is used to control the data transmission speed sent to the client. It can limit the traffic of the entire connection or limit the access speed of a single client.
Syntax:limit_rate rate;
Default:limit_rate 0;
Context:http, server, location, if in locationLimits the rate of data sent to the client in response. The unit is BYTES per second. The default value 0 means no rate limiting. This limit is for each connection request, so if the client has n parallel connections at the same time, then the overall rate of the client is n times limit_rate.
limit_rate 1k;limit_rate_after
After a certain number of BYTES are transmitted, bandwidth control is implemented. Like the instruction limit_rate, the following parameter values can be set through variables.
Syntax:limit_rate_after size;
Default:limit_rate_after 0;
Context:http, server, location, if in locationThe command limit_rate_after can only take effect if limit_rate is configured. If you only configure limit_rate_after, there will be no bandwidth control effect.
location /test/ {
limit_rate_after 500k;
limit_rate 50k;
}If the sendfile_max_chunk directive is configured at the same time, the bandwidth will be controlled based on the smaller of the two values.
Practical test
location / {
limit_rate 1k;
root html;
}
Enter in the browser to http://xxxx/portal.tardownload the portal.tar file and you can see that the download speed is within 1k
location / {
limit_rate_after 50m;
limit_rate 1k;
root html;
} Type in the browser to http://xxxx/portal.tardownload the portal.tar file
After downloading 50m, the speed is limited to 1k
Principle: Token Bucket Algorithm
NGINX uses the token bucket algorithm for bandwidth control. Use a classic graph bias to describe the token bucket algorithm:
The specific process is:
- The system generates tokens at a fixed rate and caches them in the token bucket.
- When the token bucket is full, additional tokens will be discarded.
- When transmitting a message, the corresponding number of tokens is consumed according to the size of the message.
- When there are insufficient tokens, messages cannot be transmitted.
The token bucket algorithm uses a "bucket" to store tokens and a queue to store requests. In terms of function, the most obvious difference between the leaky bucket algorithm and the token bucket algorithm is whether the processing of burst traffic (burst) is allowed. The leaky bucket algorithm can forcibly limit the real-time transmission (processing) rate of data and does not make any additional changes to the burst traffic. Processing, which implements traffic control (policy); while the token bucket algorithm can limit the average transmission rate of data while allowing a certain degree of burst transmission, and it performs traffic shaping (shaping).