Prerequisite: nginx needs to have the ngx_http_limit_conn_module and ngx_http_limit_req_module modules. You can use the command 2>&1 nginx -v | tr ' ' '\n'|grep limit to check whether there are corresponding modules. If not, please recompile and install these two module.
The test version is: nginx version is 1.15
Limit the number of links
1. Use The limit_conn_zone directive defines the key and sets parameters for the shared memory zone (worker processes will use this zone to share a counter of key values). The first parameter specifies the expression to be evaluated as the key. The second parameter zone specifies the name and size of the zone:
limit_conn_zone $binary_remote_addr zone=addr:10m;
2. Use the limit_conn directive in the context of location {}, server {} or http {} to apply the limit. The first parameter is the value set above. The specified shared memory area name. The second parameter is the number of links allowed for each key:
location /download/ { limit_conn addr 1; }
When using the $binary_remote_addr variable as a parameter, it is based on the restriction of the ip address. You can also use the $server_name variable. Limit the number of connections to a given server:
http { limit_conn_zone $server_name zone=servers:10m; server { limit_conn servers 1000; } }
Limit request rate
Rate limiting can be used to prevent ddos, cc attacks, or to prevent upstream servers from being attacked at the same time Flooded with too many requests. This method is based on the leaky bucket algorithm, where requests arrive at the bucket at various rates and leave the bucket at a fixed rate. Before using rate limiting, you need to configure the global parameters of the "leaky bucket":
-
key - a parameter used to distinguish one client from another, usually the variable
shared memory zone - The name and size of the zone that holds the state of these keys (i.e. the "leaky bucket")
rate - Number of requests per second ( The request rate limit specified in r/s) or requests per minute (r/m) ("leaky bucket draining"). Requests per minute specifies a rate of less than one request per second.
These parameters are set using the limit_req_zone directive. This directive is defined at the http {} level - this approach allows applying different zones and requesting overflow parameters to different contexts:
http { #... limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; }
With this configuration, a 10m bytes size with the name one will be created Shared memory area. This area holds the state of the client ip address set using the $binary_remote_addr variable. Note that $remote_addr also contains the client's IP address, while $binary_remote_addr holds a shorter binary representation of the IP address.
The optimal size of the shared memory area can be calculated using the following data: The value size of $binary_remote_addr ipv4 address is 4 bytes, and the storage state on 64-bit platforms takes up 128 bytes. Therefore, state information for approximately 16000 IP addresses takes up 1m bytes of this area.
If storage space is exhausted when nginx needs to add new entries, the oldest entries will be deleted. If the freed space is still not enough to accommodate the new record, nginx will return a 503 service unavailable status code, which can be redefined using the limit_req_status directive.
Once this zone is set, you can limit the request rate using the limit_req directive anywhere in the nginx configuration, especially server {}, location {} and http {} Context:
http { #... limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { #... location /search/ { limit_req zone=one; } } }
Using the above configuration, nginx will process no more than 1 request per second under the /search/ route, and the way to delay processing these requests is that the total rate is no greater than the set rate. nginx will delay processing such requests until "bucket" (shared bucket one) is full. For requests to the full bucket, nginx will respond with a 503 service unavailable error (when limit_req_status does not have a custom set status code).
Limit bandwidth
To limit the bandwidth per connection, use the following limit_rate directive:
location /download/ { limit_rate 50k; }
With this setting, the client Will be able to download content at speeds of up to 50k/sec over a single connection. However, clients can open multiple connections to bypass this limit. Therefore, if the goal is to prevent download speeds greater than a specified value, the number of connections should be limited as well. For example, one connection per IP address (if using the shared memory region specified above):
location /download/ { limit_conn addr 1; limit_rate 50k; }
To impose a limit only after the client has downloaded a certain amount of data, use the limit_rate_after directive. It might be reasonable to allow the client to quickly download a certain amount of data (e.g. file header - movie index) and limit the rate at which the rest of the data is downloaded (making the user watch the movie instead of downloading).
limit_rate_after 500k; limit_rate 20k;
The following example shows a combined configuration for limiting the number of connections and bandwidth. The maximum number of connections allowed is set to 5 connections per client address, which works for most common cases as modern browsers typically have a maximum of 3 connections open at a time. At the same time, the location provided for download only allows one connection:
http { limit_conn_zone $binary_remote_address zone=addr:10m server { root /www/data; limit_conn addr 5; location / { } location /download/ { limit_conn addr 1; limit_rate_after 1m; limit_rate 50k; } } }
The above is the detailed content of How Nginx limits http resource requests. For more information, please follow other related articles on the PHP Chinese website!

The reason why NGINX is popular is its advantages in speed, efficiency and control. 1) Speed: Adopt asynchronous and non-blocking processing, supports high concurrent connections, and has strong static file service capabilities. 2) Efficiency: Low memory usage and powerful load balancing function. 3) Control: Through flexible configuration file management behavior, modular design facilitates expansion.

The differences between NGINX and Apache in terms of community, support and resources are as follows: 1. Although the NGINX community is small, it is active and professional, and official support provides advanced features and professional services through NGINXPlus. 2.Apache has a huge and active community, and official support is mainly provided through rich documentation and community resources.

NGINXUnit is an open source application server that supports a variety of programming languages and frameworks, such as Python, PHP, Java, Go, etc. 1. It supports dynamic configuration and can adjust application configuration without restarting the server. 2.NGINXUnit supports multi-language applications, simplifying the management of multi-language environments. 3. With configuration files, you can easily deploy and manage applications, such as running Python and PHP applications. 4. It also supports advanced configurations such as routing and load balancing to help manage and scale applications.

NGINX can improve website performance and reliability by: 1. Process static content as a web server; 2. forward requests as a reverse proxy server; 3. allocate requests as a load balancer; 4. Reduce backend pressure as a cache server. NGINX can significantly improve website performance through configuration optimizations such as enabling Gzip compression and adjusting connection pooling.

NGINXserveswebcontentandactsasareverseproxy,loadbalancer,andmore.1)ItefficientlyservesstaticcontentlikeHTMLandimages.2)Itfunctionsasareverseproxyandloadbalancer,distributingtrafficacrossservers.3)NGINXenhancesperformancethroughcaching.4)Itofferssecur

NGINXUnit simplifies application deployment with dynamic configuration and multilingual support. 1) Dynamic configuration can be modified without restarting the server. 2) Supports multiple programming languages, such as Python, PHP, and Java. 3) Adopt asynchronous non-blocking I/O model to improve high concurrency processing performance.

NGINX initially solved the C10K problem and has now developed into an all-rounder who handles load balancing, reverse proxying and API gateways. 1) It is well-known for event-driven and non-blocking architectures and is suitable for high concurrency. 2) NGINX can be used as an HTTP and reverse proxy server, supporting IMAP/POP3. 3) Its working principle is based on event-driven and asynchronous I/O models, improving performance. 4) Basic usage includes configuring virtual hosts and load balancing, and advanced usage involves complex load balancing and caching strategies. 5) Common errors include configuration syntax errors and permission issues, and debugging skills include using nginx-t command and stub_status module. 6) Performance optimization suggestions include adjusting worker parameters, using gzip compression and

Diagnosis and solutions for common errors of Nginx include: 1. View log files, 2. Adjust configuration files, 3. Optimize performance. By analyzing logs, adjusting timeout settings and optimizing cache and load balancing, errors such as 404, 502, 504 can be effectively resolved to improve website stability and performance.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Zend Studio 13.0.1
Powerful PHP integrated development environment

SublimeText3 Linux new version
SublimeText3 Linux latest version

SAP NetWeaver Server Adapter for Eclipse
Integrate Eclipse with SAP NetWeaver application server.

MinGW - Minimalist GNU for Windows
This project is in the process of being migrated to osdn.net/projects/mingw, you can continue to follow us there. MinGW: A native Windows port of the GNU Compiler Collection (GCC), freely distributable import libraries and header files for building native Windows applications; includes extensions to the MSVC runtime to support C99 functionality. All MinGW software can run on 64-bit Windows platforms.

DVWA
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is very vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, to help web developers better understand the process of securing web applications, and to help teachers/students teach/learn in a classroom environment Web application security. The goal of DVWA is to practice some of the most common web vulnerabilities through a simple and straightforward interface, with varying degrees of difficulty. Please note that this software
