nginx设置请求大小(nginx配置请求时长)

1.软文推荐

2.软文推荐

3.软文推荐

目录： 1、8.Nginx的请求限制（ limit_conn_zone、 limit_conn、limit_req_zone、limit_req zone） 2、[code.nginx] Nginx服务器高级配置 3、如何调整nginx和apache服务器的header限制的大小 8.Nginx的请求限制（ limit_conn_zone、 limit_conn、limit_req_zone、limit_req zone）

在配置nginx的过程中我们需要考虑受到攻击或恶意请求的情况，比如单用户恶意发起大量请求，这时Nginx的请求限制可以帮助我们对其进行限制。

连接频率限制 : limit_conn_module

请求频率限制 : limit_req_module

理解:连接频率限制和请求频率限制都可以实现Nginx的请求限制 , 但是他们的实现原理是不一样的 , 区别就在于连接和请求上 , http协议的链接与请求 , http协议是建立在tcp协议之上的,要完成一次http的请求,先要进行tcp的3次握手建立http的连接 , 然后才进行http的request和response(请求和响应) , 现在http1.1以上的版本已经可以实现一次建立http的连接进行多次的http的request和response(请求和响应) ,最后客户端和服务端不断的来发送FIN包和ACK包来保持HTTP的连接 。

如果面对抢购和秒杀需求来限制 , 个人觉得连接频率限制和请求频率限制应该配合使用 , 使用连接频率限制同一IP同时只能有3个连接, 再使用请求频率限制对于同一ip的请求，限制平均速率为5个请求/秒 , 这样是不是比单独只使用一种限制要好很多?

比如只使用连接频率限制 , 由于一次建立http的连接可以进行多次的请求和响应 , 我们无法精确的限制同一ip同时发起多少次的http请求 ;

比如只使用请求频率限制 , 可以精确的限制同一ip1秒只能发起5次的http请求 , 假如同一ip1秒内发起了100000次请求 , 虽然限制了只有5次成功响应 , 但是其他的99995次的请求TCP握手建立http连接是不是会消耗服务器资源?

所以,个人觉得连接频率限制和请求频率限制应该配合使用!

HTTP请求建立在一次TCP连接基础上

一次TCP连接至少产生一次HTTP请求

ngx_http_limit_conn_module模块用于限制每个定义键的连接数，特别是来自单个IP地址的连接数。

未开启 连接限制 时做个压力测试 (不懂ab的可以看看这个文章 , 很简单明了)

这里模拟了10万个请求 , 1000个并发 , 78个请求失败,打开nginx的错误日志查看都是打开文件失败的错误 ( open() "/usr/share/nginx/html/50x.html" failed (24: Too many open files))! 想象一下 , 如果我们是一个商城程序的API接口 , 正常情况下 , 同一个IP下10万个请求1000个并发 , 算不算恶意攻击?那么就需要做一下连接限制了噻 , 具体怎么限制根绝具体的逻辑去处理 , 我们这里简单的限制一下(启用配置示例的连接限制)再次做个压力测试:

开启连接限制对单个IP限制同时只能存在一个连接,这里模拟了10万个请求 , 1000个并发 , 43616个请求失败,打开nginx的错误日志查看下错误全是连接限制的作用(limiting connections by zone "conn_zone") , 我们知道"现在http1.1以上的版本已经可以实现一次建立http的连接进行多次的http的request和response(请求和响应) " , 大家想想 , 如果我们需要做一个抢购和秒杀 , 是不是需要对单个抢购和秒杀限制连接单个IP同时只能存在一个或者多个连接的限制?不然人家写个脚本程序运行在十台八台的机器上疯狂的请求怎么办?当然这只是一个比较简单的应用场景 , 更多的还是需要自己思考与摸索.

ngx_http_limit_req_module模块用于限制请求的处理速率，特别是单一的IP地址的请求的处理速率。使用“漏桶”方法进行限制。

语法: limit_req_zone  key zone=name:size rate=rate;

只能在 http 块中使用

此指令用于声明请求限制 zone ， zone 可以保存各种 key 的状态， name 是 zone 的唯一标识， size 代表 zone 的内存大小， rate 指定速率限制。

参数详解:

1.key ，

若客户的请求匹配了key，则进入 zone 。可以是文本、变量，通常为Nginx变量。

如 $binary_remote_addr (客户的ip)， $uri( 不带参数的请求地址 ) ， $request_uri( 带参数的请求地址 ) ， $server_name (服务器名称) 。

支持组合使用，使用空格隔开。

2.zone

使用zone=test，指定此zone的名字为test。

3.size

在zone=name后面紧跟 :size ，指定此 zone 的内存大小。如zone=name: 10m ，代表name的共享内存大小为10m。通常情况下，1m可以保存16000个状态。

4.rate

使用rate=1r/s，限制 平均 1秒不超过1个请求。使用rate=1r/m，限制 平均 1分钟不超过1个请求。

例子:

同一ip 不同 请求地址，进入名为 one 的zone，限制速率为 5请求/秒 。

同一ip 同一 请求地址，进入名为 two 的zone，限制速率为 1请求/秒 。

语法: limit_req  zone=name [burst=number] [nodelay];

可在 http, server, location 块中使用

此指令用于设置共享的内存 zone 和最大的突发请求大小。

若请求速率超过了 limit_req_zone 中指定的 rate 但小于 limit_req 中的 burst ，则进行延迟处理，若再超过 burst ，就可以通过设置nodelay对其进行丢弃处理。

参数详解:

1.zone

使用 zone=name 指定使用名为 name 的 zone ，这个 zone 之前使用 limit_req_zone 声明过。

2.burst(可选)

burst用于指定最大突发请求数。许多场景下，单一地限制rate并不能满足需求，设置 burst ，可以延迟处理超过rate限制的请求。

3.nodelay(可选)

如果设置了 nodelay ，在突发请求数大于 burst 时，会丢弃掉这部分请求。因为如果只是延迟处理，就像” 漏斗 “，一旦上面加得快( 请求 )，下面漏的慢( 处理速度 )，” 漏斗 “总会有溢出的时候。这时，丢弃掉溢出的部分就显得很有意义了。

单客户分为三种情况:

请求速率 rate(1r/s) ，正常处理

rate(1r/s) 请求速率 ＜ burst(5r/s) ，大于rate部分延迟

burst(5r/s)  请求速率 ，大于burst部分丢弃(返回503服务暂时不可用)

未开启请求限制时做个压力测试 (不懂ab的可以看看这个文章 , 很简单明了)

这里模拟了10万个请求 , 1000个并发 , 全部请求成功! 想想一下 , 如果我们是一个商城程序的API接口 , 正常情况下,同一个IP下10万个请求算不算恶意攻击?那么就需要做一下请求限制了噻 , 具体怎么限制根绝具体的逻辑去处理 , 我们这里简单的限制一下:

同一ip请求，进入名为req_zone的zone，限制速率为20次请求/秒,

超过部分进行延迟处理，若超过10个请求/秒，丢弃超过部分。

修改了配置之后平滑重启一下nginx -s reload , 再次使用之前的参数做个压力测试看看

同一IP发起了请求10万次, nginx只接受处理了100次,是不是nginx的压力一下子就小了[code.nginx] Nginx服务器高级配置

这里提及的参数是和IPv4网络有关的Linux内核参数。我们可以将这些内核参数的值追加到Linux系统的/etc/sysctl.conf文件中，然后使用如下命令使修改生效：

这些常用的参数包括以下这些。

** 1. net.core.netdev_max_backlog参数 **

net.core.netdev_max_backlog，表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。一般默认值为128（可能不同的Linux系统该数值也不同）。Nginx服务器中定义的NGX_LISTEN_BACKLOG默认为511.我们可以将它调整一下：

** 2.net.core.somaxconn参数 **

该参数用于调节系统同时发起的TCP连接数，一般默认值为128。在客户端存在高并发请求的情况下，在默认值较小，可能导致链接超时或者重传问题，我们可以根据实际需要结合并发请求数来调节此值。

** 3.net.ipv4.tcp_max_orphans参数 **

该参数用于设定系统中最多允许存在多少TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，没有与用户文件句柄关联的TCP套接字将立即被复位，同时给出警告信息。这个限制只是为了防止简单的DoS(Denial of Service，拒绝服务)攻击。一般在系统内存比较充足的情况下，可以增大这个参数的赋值：

** 4.net.ipv4.tcp_max_syn_backlog参数 **

该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。一般在系统内存比较充足的情况下，可以增加这个参数的赋值：

** 5.net.ipv4.tcp_timestamps参数 **

该参数用于设置时间戳，这可以避免序列号的卷绕。在一个1Gb/s的链路上，遇到以前用过的序列号的概率很大。当此值赋值为0时，禁用对于TCP时间戳的支持。在默认情况下，TCP协议会让内核接受这种“异常”的数据包。针对Nginx服务器来说，建议将其关闭：

** 6.net.ipv4.tcp_synack_retries参数 **

该参数用于设置内核放弃TCP连接之前向客户端发送SYN+ACK包的数量。为了建立对端的连接服务，服务器和客户端需要进行三次握手，第二次握手期间，内核需要发送SYN并附带一个回应前一个SYN的ACK，这个参数主要影响这个进程，一般赋值为1，即内核放弃连接之前发送一次SYN+ACK包，可以设置其为：

** 7.net.ipv4.tcp_syn_retries参数 **

该参数的作用和上一个参数类似，设置内核放弃建立连接之前发送SYN包的数量，它的赋值和上个参数一样即可：

在Nginx配置文件中，有这样两个指令：worker_processes和worker_cpu_affinity，它们可以针对多核CPU进行配置优化。

** 1.worker_processes指令 **

worker_processes指令用来设置Nginx服务的进程数。官方文档建议此指令一般设置为1即可，赋值太多会影响系统的IO效率，降低Nginx服务器的性能。为了让多核CPU能够很好的并行处理任务，我们可以将worker_processes指令的赋值适当的增大一些，最好是赋值为机器CPU的倍数。当然，这个值并不是越大越好，Nginx进程太多可能增加主进程调度负担，也可能影响系统的IO效率。针对双核CPU，建议设置为2或

4。如果是四核CPU，设置为：

设置好worker_processes指令之后，就很有必要设置worker_cpu_affinity指令。

** 2. worker_cpu_affinity指令 **

worker_cpu_affinity指令用来为每个进程分配CPU的工作内核。这个指令用来为每个进程分配CPU的工作内核。这个指令的设置方法有些麻烦。

如下图所示：

worker_cpu_affinity指令的值是由几组二进制值表示的。其中，每一组代表一个进程，每组中的每一位表示该进程使用CPU的情况，1表示使用，0表示不使用。注意，二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。

如果设置的Nginx服务的进程数为4，CPU为4核，因此会有四组值，并且每组有四位，所以，此指令的设置为：

四组二进制数值分别对应4个进程，第一个进程对应0001，表示使用第一个CPU内核。第二个进程对应0010，表示使用第二个CPU内核，以此类推。

如果将worker_processes指令的值赋值为8，即赋值为CPU内核个数的两倍，则worker_cpu_affinity指令的设置可以是：

如果一台机器的CPU是八核CPU，并且worker_processes指令的值赋值为8，那么worker_cpu_affinity指令的设置可以是：

** 1.keepalive_timeout指令 **

该指令用于设置Nginx服务器与客户端保持连接的超时时间。

这个指令支持两个选项，中间用空格隔开。第一个选项指定客户端连接保持活动的超时时间，在这个时间之后，服务器会关闭此连接。第二个选项可选，其指定了使用Keep-Alive消息头保持活动的有效时间，如果不设置它，Nginx服务器不会向客户端发送Keep-Alive消息头以保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接，超过设置的时间后，客户端就可以关闭连接，而不需要服务器关闭了。你可以根据自己的实际情况设置此值，建议从服务器的访问数量、处理速度以及网络状态方面考虑。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端连接保持活动的时间是60s，60s后服务器与客户端断开连接。使用Keep-Alive消息头保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接时间为50s，50s后浏览器主动与服务器断开连接。

** 2.send_timeout指令 **

该指令用于设置Nginx服务器响应客户端的超时时间，这个超时时间仅针对两个客户端和服务器之间建立连接后，某次活动之间的时间。如果这个时间后客户端没有任何活动，Nginx服务器将会关闭连接。此指令的设置需要考虑服务器访问数量和网络状况等方面。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端建立连接后，某次会话中服务器等待客户端响应超时10s，就会自动关闭连接。

** 3.client_header_buffer_size指令 **

该指令用于设置Nginx服务器允许的客户端请求头部的缓冲区大小，默认为1KB。此指令的赋值可以根据系统分页大小来设置。分页大小可以用以下命令取得：

有过Nginx服务器工作经验的可能遇到Nginx服务器返回400错误的情况。查找Nginx服务器的400错误原因比较困难，因为此错误并不是每次都会出现，出现错误的时候，通常在浏览器和日志里也看不到任何有关提示信息。根据实际的经验来看，有很大一部分情况是客户端的请求头部过大造成的。请求头部过大，通常是客户单cookie中写入了较大的值引起的。于是适当增大此指令的赋值，允许Nginx服务器接收较大的请求头部，可以改善服务器对客户端的支持能力。一般将此指令赋值为4KB大小，即：

** 4.multi_accept指令 **

该指令用于配置Nginx服务器是否尽可能多的接收客户端的网络连接请求，默认值为off。

本节涉及的指令与Nginx服务器的事件驱动模型密切相关。

其中，number为设置的最大数量。结合worker_processes指令，我们可以计算出Nginx服务器允许同时连接的客户端最大数量Client = worker_processes * worker_connections / 2;

在使用Nginx服务器的过程中，笔者曾经遇到过无法访问Nginx服务器的情况，查看日志发现一直在报如下错误:

根据报错信息，推测可能是Nginx服务器的最大访问连接数设置小了。此指令设置的就是Nginx服务器能接受的最大访问量，其中包括前端用户连接也包括其他连接，这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积。此指令一般设置为65535：

此指令的赋值与linux操作系统中进程可以打开的文件句柄数量有关系。按照以上设置修改此项赋值以后，Nginx服务器报以下错误：

究其原因，Linux系统中有一个系统指令open file resource limit，它设置了进程可以打开的文件句柄数量。worker_connections指令的赋值当然不能超过open file resource limit的赋值。可以使用以下命令查看在你的Linux系统中open file resource limit的赋值。

可以通过一下命令将open file resource limit指令的值设为2390251：

这样，Nginx的worker_connections指令赋值为65535就没问题了。

其中，limit为Linux平台事件信号队列的长度上限值。

该指令主要影响事件驱动模型中rfsig模型可以保存的最大信号数。Nginx服务器的每一个工作进程有自己的事件信号队列用于暂存客户端请求发生信号，如果超过长度上线，Nginx服务器自动转用poll模型处理未处理器的客户端请求。为了保证Nginx服务器对客户端请求的高效处理，请大家根据实际的客户端并发请求数量和服务器运行环境的处理能力设定该值。设置示例为：

其中，number为要设置的数量，默认值均为32。

其中，number为要设置的数量，默认值均为512.

使用kequeue_changes方式，可以设置与内核之间传递事件的数量。

其中，number为要设置的数量，默认值均为512。

7.rtsig_signo指令

该指令用于设置rtsig模式使用的两个信号中的第一个，第二个信号是在第一个信号的编号上加1，语法为：

默认的第一个信号设置为SIGRTMIN+10。

提示

在Linux中可以使用一下命令查看系统支持的SIGRTMIN有哪些。

8.rtsig_overflow_* 指令

该指令代表三个具体的指令，分别为rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。这些指令用来控制当rtsig模式中信号队列溢出时Nginx服务器的处理方式，语法结构为：

其中，number是要设定的值。

rtsig_overflow_events指令指定队列溢出时使用poll库处理的事件数，默认值为16。

rtsig_overflow_test指令设定poll库处理完第几件事件后将清空rtsig模型使用的信号队列，默认值为32。

rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了。

如何调整nginx和apache服务器的header限制的大小

现在主流的apache和nginx服务器他们都可以自由设置header的头信息上限大小。我们通过配置文件修改来达到目的。

nginx默认的header长度上限是4k，如果超过了这个值

如果header头信息请求超过了，nginx会直接返回400错误

可以通过以下2个参数来调整nginx的header上限

client_header_buffer_size 16k;

large_client_header_buffers 4 16k;

看起来是，nginx默认会用client_header_buffer_size这个buffer来读取header值，如果header过大，它会使用large_client_header_buffers来读取

引用client_header_buffer_size

syntax: client_header_buffer_size size

default: 1k

context: http, server

Directive sets the headerbuffer size for the request header from client.

For the overwhelming majority of requests it is completely sufficient a buffer size of 1K.

However if a big cookie is in the request-header or the request has come from a wap-client the header can not be placed in 1K, therefore, the request-header or a line of request-header is not located completely in this buffer nginx allocate a bigger buffer, the size of the bigger buffer can be set with the instruction large_client_header_buffers.

引用large_client_header_buffers

syntax: large_client_header_buffers number size

default: large_client_header_buffers 4 4k/8k

context: http, server

Directive assigns the maximum number and size of buffers for large headers to read from client request.

The request line can not be bigger than the size of one buffer, if the client send a bigger header nginx returns error "Request URI too large" (414).

The longest header line of request also must be not more than the size of one buffer, otherwise the client get the error "Bad request" (400).

Buffers are separated only as needed.

By default the size of one buffer is equal to the size of page, depending on platform this either 4K or 8K, if at the end of working request connection converts to state keep-alive, then these buffers are freed.

对于apache2来说，它默认值是8k

可以调整以下2个参数

LimitRequestLine 16k

LimitRequestFieldSize 16k

LimitRequestLine 指令设置的是每一个header长度的上线

引用LimitRequestLine 指令

说明 限制接受客户端发送的HTTP请求行的字节数

语法 LimitRequestLine bytes

默认值 LimitRequestLine 8190

作用域 server config

状态 核心(C)

模块 core

bytes将设置HTTP请求行的字节数限制。

LimitRequestLine指令允许服务器管理员增加或减少客户端HTTP请求行允许大小的限制。因为请求行包括HTTP方法、URI、协议版本，所以LimitRequestLine指令会限制请求URI的长度。服务器会需要这个值足够大以装载它所有的资源名，包括可能在GET请求中所传递的查询部分的所有信息。

这个指令给了服务器管理员更大的可控性以控制客户端不正常的请求行为。这有助于避免某些形式的拒绝服务攻击。

LimitRequestFieldSize指令设置的是所有header总长度的上限值

引用LimitRequestFieldSize 指令

说明 限制客户端发送的请求头的字节数

语法 LimitRequestFieldsize bytes

默认值 LimitRequestFieldsize 8190

作用域 server config

状态 核心(C)

模块 core

bytes指定了HTTP请求头允许的字节大小。

LimitRequestFieldSize指令允许服务器管理员增加或减少HTTP请求头域大小的限制。一般来说，服务器需要此值足够大，以适应普通客户端的任何请求的头域大小。一个普通头域的大小对于不同的客户端来说是有很大差别的，一般与用户配置他们的浏览器以支持更多的内容协议密切相关。SPNEGO的认证头最大可能达到12392字节。

这个指令给了服务器管理员更大的可控性以控制客户端不正常的请求行为。这有助于避免某些形式的拒绝服务攻击。注:该设置在apache root/manual/mod/core.xml中进行设置