scenes to be used
Recently, the related configuration of the report query system load balancing cluster has been completed. The two implementation methods are session management strategies based on Ehcache and Redis respectively.
We all know that server resources are limited, but requests from clients are unlimited (malicious attacks are not ruled out). In order to ensure that most requests can be responded normally, some requests from clients have to be given up, so we will use Nginx Current limiting operation, this operation can relieve the pressure on the server to a great extent, so that other normal requests can be responded normally.
How to use Nginx to implement basic current limiting, such as limiting a single IP to 50 visits per second. Through the Nginx current limiting module, we can set that once the number of concurrent connections exceeds our setting, a 503 error will be returned to the client. This can be very effective in preventing CC attacks. Combined with the iptables firewall, basically CC attacks can be ignored.
how to use
conf configuration
#Unified configuration in the http domain #Limit requests limit_req_zone $binary_remote_addr $ uri zOne=api_read:20m rate=50r/s; #Configure a connection zone by ip limit_conn_zone $binary_remote_addr zOne=perip_conn:10m; #Configure a connection zone by server limit_conn_zone $server_name zOne=perserver_conn:100m; server { listen 80; server_name report.52itstyle.com; index login.jsp; location / { #Request current limit queuing through burst default is 0 limit_req zOne=api_read burst=5; #The limit on the number of connections, each IP concurrent request is 2 limit_conn perip_conn 2; #The number of connections limited by the service (that is, the number of concurrent connections to the server is limited) limit_conn perserver_conn 1000; #Connection speed limit limit_rate 100k; proxy_pass http://report; } } upstream report { fair; server 172.16.1.120:8882 weight=1 max_fails=2 fail_timeout=30s; server 172.16.1.120:8881 weight=1 max_fails=2 fail_timeout=30s; }
configure 503 error
By default, if the limit is exceeded, a 503 error will be reported, prompting:
503 Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Sorry for the inconvenience. Please report this message and include the following information to us. Thank you very much!
There is nothing wrong with this display, but it is not friendly enough. Here we customize the 503 error.
error_page 500 502 503 504 /50x.html; location = /50x.html { root html;#custom 50X error }
Configuration instructions
limit_conn_zone
It is to define a container for storing session state for each IP. In this example, a 100m container is defined, according to 32bytes/session, it can handle 3200000 sessions.
limit_rate 300k;
The speed limit for each connection is 300k. Note that this is the speed limit for the connection, not for the IP. If an IP allows two concurrent connections, then this IP is limit_rate×2.
burst=5;
This is equivalent to putting 5 seats next to the checkpoint req. If a request is stopped for exceeding the speed limit at the time, ask him to sit in an empty seat, wait in line, and if the checkpoint is empty, he can go through. If even the seats are full, then I’m sorry, the request is returned directly, and the client gets a response that the server is busy. Therefore, burst has nothing to do with request_rate. If it is set to 10000, 10,000 requests can be queued, but the checkpoint still releases 5 requests in 1 second (turtle speed). And you can’t queue up all the time, so nginx also set a timeout. If the queue exceeds a certain period of time, it will return directly and return the response that the server is busy.
The above configuration of Nginx needs to configure the following modules:
ngx_http_limit_conn_module (static)
ngx_http_limit_req_module (static)
Execute the command nginx -V to check whether it is installed.