Nginx-限制并发、访问速率、流量

Bertha 。 2023-07-15 11:28 16阅读 0赞

在Nginx中，以LIMIT开头的配置项，都是做限制功能的。这里介绍三个常用的限制模块：

1）`limit_conn_zone`模块：限制同一IP地址并发连接数。

2）`limit_request`模块：限制同一IP某段时间的访问量。

3）core模块提供的`limit_rate`：限制同一IP流量。

本文针对这三个模块进行配置，并验证各自的功能特点。

## 一、limit\_conn\_zone模块 ##

通过`limit_zone`模块来达到限制用户连接数的目的，即限制同一用户IP地址的并发连接数。

#### 1、配置示例 ####

limit_conn_zone $binary_remote_addr zone=myzone:10m;
        server { 
            listen       80;
            server_name  localhost;
    
            location /downloads/ { 
                limit_conn myzone 1;
                alias   /data/apps/;
                index  index.html index.htm;
            }
        }

#### 2、指令 ####

指令名称：`limit_conn_zone`（nginx1.18以后用limit\_conn\_zone取代了limit\_conn）  
语法：`limit_conn_zone key zone=name:size;`  
默认：`no`  
区域：`http`  
功能：上面示例中的`$binary_remote_addr`是获取客户端ip地址的变量，长度为4字节，会话信息的长度为32字节。

指令名称：`limit_conn`  
语法：`limit_conn zone number;`  
默认：`no`  
区域：`http、server、location`  
功能：该指令用于为一个会话设定最大并发连接数。如果并发请求超过这个限制，那么将返回预定错误（limit\_conn\_status）

指令名称：`limit_conn_status`  
语法：`limit_conn_status code;`  
默认：`limit_conn_status 503;`  
区域：`http、server、location`  
功能：设置要返回的状态码以响应被拒绝的请求。

指令名称：`limit_conn_log_level`  
语法：`limit_conn_log_level info | notice | warn | error`  
默认值：`error`  
区域：`http、server、location`  
功能：该指令用于设置日志的错误级别，当达到连接限制时，将会产生错误日志。

上面配置的示例中，没有显示配置limit\_conn\_status 、limit\_conn\_log\_level，如果没有配置，则启用它们的默认值。

#### 3、测试 ####

我这里测试下载app包，用ab命令进行模拟并发访问。

[root@localhost ~]# ab -n 10 -c 10 http://192.168.0.171/downloads/test.apk

`-n`：总请求数

`-c`：并发个数

结果：

Concurrency Level:      10
    Time taken for tests:   0.005 seconds
    Complete requests:      10
    Failed requests:        1
       (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
    Write errors:           0
    Non-2xx responses:      9
    Total transferred:      16483538 bytes

可以看到，这次测试完成了10个并发连接，其中9个返回的是非200状态码。再来看一下Nginx日志：

[root@localhost logs]# tail access.log 
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:13:43:09 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"

10个并发连接，其中只有1个返回200状态码，其余9个都是503状态，这样的测试结果和设定的测试结果相符。

## 二、limit\_request模块 ##

使用`ngx_http_limit_req_module`模块可以限制某一IP在一段时间内对服务器发起请求的连接数，该模块为内置模块。

#### 1、配置示例 ####

limit_req_zone $binary_remote_addr zone=zone2:10m rate=1r/s;
        server { 
            listen       80;
            server_name  localhost;
    
            location /downloads/ { 
                limit_req zone=zone2 burst=5 nodelay;
                alias   /data/apps/;
                index  index.html index.htm;
            }
        }

#### 2、指令 ####

指令名称：`limit_req_zone`  
语法：`limit_req_zone key zone=name:size rate= number r/s`  
默认值：`no`  
区域：`http`  
使用示例：`limit_req_zone $binary_remote_addr zone=zone2:10m rate=1r/s`  
对于上面的示例：

$binary_remote_addr ：表示通过remote_addr这个标识来做限制。
    zone=zone2:10m：表示生成一个 10M ，名字为 zone2 的内存区域，用来存储访问的频次信息
    rate=1r/s：表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，即每秒只处理一个请求，还可以有比如 30r/m ， 即限制每 2秒 访问一次，即每 2秒 才处理一个请求。

指令名称：`limit_req`  
语法：`limit_req zone=name [burst=number] [nodelay | delay=number];`  
默认值：`no`  
区域：`http、server、location`  
使用示例：`limit_req zone=zone2 burst=5 nodelay;`

zone=zone：设置使用哪个配置名来做限制，与上面 limit_req_zone 里的 name 对应
    burst=5 ：这个配置的意思是设置一个大小为5的缓冲区，当有大量请求过来时，超过访问频次限制 rate=1r/s 的请求可以先放到这个缓冲区内等待，但是这个缓冲区只有5个位置，超过这个缓冲区的请求直接报503并返回。
    nodelay：如果设置，会在瞬间提供处理（rate+burst）个请求的能力，请求超时（rat+burst）的时候直接返回503，永远不存在请求需要等待的情况。如果没有设置，则所有请求会依次等待排队；

指令名称：`limit_req_status`  
语法：`limit_req_status code;`  
默认：`limit_req_status 503;`  
区域：`http、server、location`  
功能：设置要返回的状态码以响应被拒绝的请求。

指令名称：`limit_req_log_level`  
语法：`limit_req_log_level info | notice | warn | error;`  
默认：`limit_req_log_level error;`  
区域：`http、server、location`  
功能：该指令用于设置日志的错误级别，当达到连接限制时，将会产生错误日志。

上面配置的示例中，没有显示配置`limit_req_status`、`limit_req_log_level`，如果没有配置，则启用它们的默认值。

举个例子来更好的理解上面的`rate=1r/s`和`burst=5`

第一秒： 来了6个请求 - 1 个处理 - 5个等待
    第二秒：来了2个请求 - 1个处理 - 5个等待 - 1 个丢弃
    
    上面总共8个请求，时间2秒，2秒处理了2个请求，还剩6个，但是缓冲队列只能存放5个请求，剩下1个丢弃。
    
    或者
    
    第一秒：来了10个请求 - 1个处理 - 5个等待 - 4个丢弃

就是按照这样的方式来计算的，也就是说，上面的配置，每秒最多只能保持6个请求，但是每秒最多只能处理1个请求。

#### 3、测试 ####

本模块测试分为三种不同的方式进行测试验证：

1）不加burst和不加nodelay

2）加burst和不加nodelay

3）加burst和加nodelay

##### 测试1-不加burst和不加nodelay #####

配置如下：

limit_req_zone $binary_remote_addr zone=zone2:10m rate=1r/s;
        server { 
            listen       80;
            server_name  localhost;
    
            location /downloads/ { 
                limit_req zone=zone2;
                alias   /data/apps/;
                index  index.html index.htm;
            }
        }

通过ab命令模拟并发访问：

[root@localhost ~]# ab -n 10 -c 10 http://192.168.0.171/downloads/test.apk
    ...省略
    Concurrency Level:      10
    Time taken for tests:   0.005 seconds
    Complete requests:      10
    Failed requests:        1
       (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
    Write errors:           0
    Non-2xx responses:      9
    Total transferred:      16483538 bytes
    ...省略

通过ab测试后的结果为10个并发连接，只有1个成功，剩余9个都返回非200状态码，查看Nginx日志：

[root@localhost logs]# tail access.log 
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:06:56 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"

1秒钟的10次请求，只有1个返回200，剩余全是503请求被拒绝。

得出的结论是：`不加burst和不加nodelay的情况下，rate=1r/s 1秒钟只能处理1个请求，剩余的所有请求都会直接返回503。`

##### 测试2-加burst和不加nodelay #####

配置如下：

limit_req_zone $binary_remote_addr zone=zone2:10m rate=1r/s;
        server { 
            listen       80;
            server_name  localhost;
    
            location /downloads/ { 
                limit_req zone=zone2 burst=5;
                alias   /data/apps/;
                index  index.html index.htm;
            }
        }

通过ab命令模拟并发访问：通过ab命令模拟并发访问：

[root@localhost ~]# ab -n 10 -c 10 http://192.168.0.171/downloads/test.apk
    ...省略
    Concurrency Level:      10
    Time taken for tests:   5.006 seconds
    Complete requests:      10
    Failed requests:        6
       (Connect: 0, Receive: 0, Length: 6, Exceptions: 0)
    Write errors:           0
    Non-2xx responses:      4
    Total transferred:      98882678 bytes
    ...省略

通过ab测试后的结果为10个并发连接，其中失败了4个，成功了6个。

在本次的测试中，使用`burst=5`建立以一个可以存放5个并发连接的缓冲区。

第一秒：10个连接并发请求，1个处理 5个等待，4个丢弃；  
第二秒：1个处理 4 个等待；  
第三秒：1个处理 3 个等待；  
第四秒：1个处理 2 个等待；  
第五秒：1个处理 1 个等待；  
第六秒：1个处理 完毕。

通过上面的推算，一共需要 6 秒才能处理完所有的请求，查看 Nginx 日志，验证推算是不是正确：

[root@localhost logs]# tail access.log 
    192.168.0.171 - - [13/Mar/2020:15:19:37 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:37 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:37 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:37 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:37 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:38 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:39 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:40 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:41 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:19:42 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"

通过日志，可以看出，第一秒处理了1个请求，拒绝了4个连接，剩下的请求分别是每秒 1个连接请求的处理。

得出的结论是：`加burst和不加nodelay的情况下，rate=1r/s burst=5 处理1个，缓存5个后续1秒一个的处理，其他的全部丢弃。`

##### 测试3-加burst和加nodelay #####

配置如下：

通过ab命令模拟并发访问：通过ab命令模拟并发访问：

[root@localhost ~]# ab -n 10 -c 10 http://192.168.0.171/downloads/test.apk
    ...省略
    Concurrency Level:      10
    Time taken for tests:   0.022 seconds
    Complete requests:      10
    Failed requests:        6
       (Connect: 0, Receive: 0, Length: 6, Exceptions: 0)
    Write errors:           0
    Non-2xx responses:      4
    Total transferred:      98882678 bytes
    ...省略

10个连接请求，很快就直接返回了，其中4个非200错误，6个成功。查看Nginx日志：

[root@localhost logs]# tail access.log 
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 503 206 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"
    192.168.0.171 - - [13/Mar/2020:15:28:24 +0800] "GET /downloads/test.apk HTTP/1.0" 200 16479754 "-" "ApacheBench/2.3"

这次的测试结果，同一秒钟，处理了rate+burst个请求，其他的全部返回连接请求拒绝。

#### 4、总结 ####

通过测试的三种情况，返回了不同的结果，因此有必要详细说明：

1）不加 burst 和 不加 nodelay 的情况：按照 rate 设定的规则，严格执行。例如：rate=1r/s ，则1秒只处理1个请求，其他的全部返回连接503。

2）加 burst 和 不加 nodelay 的情况：首先按照 rate 规则处理，并且缓存 burst 个连接，剩余的全部返回503，后续缓存的 burst 按照 rate 规则进行处理。

3）加 burst 和 nodelay 的情况：第一次处理 rate+burst 个连接请求，剩余的请求全部返回 503。

## 四、limit\_rate\_ip限制流量 ##

对于提供下载的网站，肯定是要进行流量控制的。Nginx通过core模块的limit\_rate等指令可以做到限流的目的。

#### 1、示例 ####

server { 
            listen       80;
            server_name  localhost;
    
            location /downloads/ { 
                limit_rate_after 3m;
                limit_rate 512K;
                alias   /data/apps/;
                index  index.html index.htm;
            }
        }

#### 2、指令 ####

指令名称：`limit_rate`  
语法：`limit_rate speed;`  
默认值：`no`  
区域：`http、server、location`  
示例：`limit_rate 512k;`  
功能：该指令用于指定向客户端传输数据的速度，速度的单位是每秒传输的字节数。注意：该限制只是针对一个连接的设定，也就是说，如果同时有2个连接，那么它的速度将会是该指令设置的两倍。

指令名称：`limit_rate_after`  
语法：`limit_rate_after size;`  
默认值：`limit_rate_after 1m;`  
区域：`http、server、location`  
示例：`limit_rate_after 3m;`  
功能：以最大的速度下载 size大小后，在进行 limit\_rate speed 限速，例如：limit\_rate\_after 3m 解释为：以最大的速度下载3m后，再进行限速。

#### 3、测试 ####

测试前疑问：对于这个模块是通过什么来进行限速的呢？ 上面的两个模块都有声明 `$binary_remote_addr` 远端ip地址进行操作的，而`limit_rate`什么都没规定。针对这个问题，做以下测试：

配置如下：

表示：正常速度下载 3m数据后，限速 512K 的速度下载。

这次通过curl来下载文件。  
![在这里插入图片描述][20200316210858477.png]  
如果同时开启多个终端下载呢？

连接-1  
![在这里插入图片描述][20200316210931795.png]  
连接-2  
![在这里插入图片描述][20200316210947609.png]  
因为 limit\_rate 并没有声明以什么条件作为限制，所以同一个ip无论发起多少个请求，每个请求都会是 512k 下载。在迅雷等多种下载软件中，使用多线程的方式下载同一个文件，这个速度就翻倍了。 那这个限速就形同虚设。

因此，如果要进行限速，可以和 `limit_conn_zone` 模块配合进行使用。配置如下：

limit_conn_zone $binary_remote_addr zone=myzone:10m;
        server  { 
            listen       80;
            server_name  localhost;
    
            location /downloads/ { 
                limit_conn myzone 1;
                limit_rate_after 3m;
                limit_rate 512K;
                alias   /data/apps/;
                index  index.html index.htm;
            }
        }

再进行通主机多线程下载：

连接-1  
![在这里插入图片描述][20200316211016903.png]  
连接-2  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3djMTY5NTA0MDg0Mg_size_16_color_FFFFFF_t_70]  
当第一个连接在下载的时候发起第二个连接，服务器会直接返回连接拒绝503，这样就达到了限速的目的。

#### 4、总结 ####

当需要进行限速操作时，需要`limit_rate`和`limit_conn`模块联合起来使用才能达到限速的效果。

参考文章：  
[https://www.cnblogs.com/hukey/p/10498544.html][https_www.cnblogs.com_hukey_p_10498544.html]

[20200316210858477.png]: /images/20230528/adc4acae3ba34a9088f1c6ea3b01a39c.png
[20200316210931795.png]: /images/20230528/343ee079548f4d139dd947518d51398b.png
[20200316210947609.png]: /images/20230528/133dfe61820147f187bc7b001b9a0301.png
[20200316211016903.png]: /images/20230528/47107517f8e946afbafde189a67d0dd8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3djMTY5NTA0MDg0Mg_size_16_color_FFFFFF_t_70]: /images/20230528/30a01f0eff3844639508a61e9c36e111.png
[https_www.cnblogs.com_hukey_p_10498544.html]: https://www.cnblogs.com/hukey/p/10498544.html