Nginx current limit (simple implementation)

 Nginx is now the most popular load balancing and reverse proxy middleware with many application scenarios. Here is an introduction to its current limiting implementation scheme.

There are three powerful tools for high-concurrency systems: caching, downgrading and current limiting, the mainstream middleware Nginx in high-concurrency scenarios

Scene access:

In the face of the Internet with a sharp increase in traffic, interface current limiting is also necessary, especially for high-concurrency scenarios. Nginx's current limiting is mainly in two ways: limiting the frequency of access and limiting the number of concurrent connections.

Rate limiting is the most useful of NGINX's many features, and it is also one of the features that are often misunderstood and misconfigured. This feature can limit the number of HTTP requests that a user can generate in a given period of time. The request can be as simple as a GET request for the home page or a POST request for a login form.
Current limiting can also be used for security purposes, such as slowing down brute force password cracking attacks. Help prevent DDoS attacks by limiting the rate of incoming requests and marking out target URLs (combined with logs). Generally speaking, current limiting is used to protect upstream application servers from being annihilated and paralyzed by a large number of user requests at the same time.

working principle:

How NGINX current limit works

NGINX current limiting uses the leaky bucket algorithm , which is widely used in communications and packet-switched computer networks to deal with unexpected situations when bandwidth is limited. The principle is similar to that of a bucket with water coming in from above and leaking from below; if the rate of water ingress is greater than the rate of water leakage, the bucket will overflow.

In the request processing process, the water represents the request from the client, and the bucket represents a queue in which the request is waiting to be processed according to the first-in-first-out (FIFO) algorithm. Leaking water means that the request leaves the buffer and is processed by the server, and overflow means that the request is discarded and will never be serviced.

Nginx official corresponding document: http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

Specific implementation plan:

1. Restrict access frequency (normal traffic)

In Nginx, we use the ngx_http_limit_req_module module to limit the access frequency of requests, which is based on the leaky bucket algorithm principle. Next, we use nginx limit_req_zone and limit_req instructions to limit the request processing rate of a single IP.

grammar:limit_req_zone key zone rate

Below: modify limit_req in localtion to limit_req (hand error) (how to write a wrong, nginx -s reload will also report an error)

  • key: Define the current limiting object. Binary_remote_addr is a key, which means that the current is limited based on remote_addr (client IP). The purpose of binary_ is to compress the memory footprint.
  • zone: Define a shared memory area to store access information. myRateLimit:10m represents a memory area with a size of 10M and a name of myRateLimit. 1M can store 16000 IP address access information, 10M can store 16W IP address access information.
  • rate is used to set the maximum access rate, rate=10r/s means processing up to 10 requests per second. Nginx actually tracks request information with millisecond granularity, so 10r/s is actually a limit: a request is processed every 100 milliseconds. This means that since the last request is processed, if another request arrives within 100 milliseconds, the request will be rejected.

2. Limit access frequency (burst traffic)

According to the above configuration, when the traffic suddenly increases, the excess request will be rejected, and the burst traffic cannot be processed. Then, how to deal with the burst traffic? Nginx provides the burst parameter to solve the problem of burst traffic, and it is used in conjunction with the nodelay parameter. Burst is translated as burst or burst, which means the number of requests that can be processed additionally after exceeding the set processing rate.

Still refer to the picture above:

burst=20 nodelay means that these 20 requests are processed immediately and cannot be delayed, which is equivalent to special work. However, even if these 20 sudden requests are processed immediately, subsequent requests will not be processed immediately. Burst=20 is equivalent to 20 pits in the cache queue. Even if the request is processed, these 20 positions can only be released in 100ms. This achieves the effect that the rate is stable, but the sudden flow can be handled normally.

Three, limit the number of concurrent connections

Nginx's ngx_http_limit_conn_module module provides the function of limiting the number of resource connections. You can use limit_conn_zone and limit_conn instructions.

limit_conn perip 20: The corresponding key is $binary_remote_addr, which means that a single IP can hold up to 20 connections at the same time. limit_conn perserver 100: The corresponding key is $server_name, which indicates the total number of concurrent connections that the virtual host (server) can handle at the same time. Note that this connection will be counted only after the request header is processed by the backend server.

 

 

 

 

Guess you like

Origin blog.csdn.net/Coder_Boy_/article/details/110409656