Nginx配置专题研究
1常用功能配置优化
- 1.1网络连接的优化
只能在events模块设置，用于防止在同一一个时刻只有一个请求的情况下，出现多个睡眠进程会被唤醒但只能有一个进程可获得请求的尴尬，如果不优化，在多进程的nginx会影响以部分性能。
如果设置允许 accept_mutex ，则 worker 会轮流的也即串行的方式接受新连接。其中一个worker被唤醒来处理新来的连接，其他的worker保持不动；如果不允许 accept_mutex，Nginx会通知所有的worker，唤醒他们【惊群问题】，以便让其中一个worker来接受处理新来的连接，Nginx默认禁用该功能（一个保守的设置，预防惊群问题）。
1.11.3版本之前，该功能默认是开启的。
events {
accept_mutex on; #优化同一时刻只有一个请求而避免多个睡眠进程被唤醒的设置，on为防止被同时唤醒，默认为off，因此nginx刚安装完以后要进行适当的优化。
}
- 1.2设置是否允许同时接受多个网络连接
只能在events模块设置，Nginx服务器的每个工作进程可以同时接受多个新的网络连接，但是需要在配置文件中配置，此指令默认为关闭，即默认为一个工作进程只能一次接受一个新的网络连接，打开后几个同时接受多个；设置了 multi_accept off 后，worker进程一次只能处理一个连接，设置为on的时候，worker 进程一次可以接受所有连接。配置语法如下：
events {
accept_mutex on;
multi_accept on; #打开同时接受多个新网络连接请求的功能。
}
- 1.3隐藏ngxin版本号
当前使用的nginx可能会有未知的漏洞，如果被黑客使用将会造成无法估量的损失，但是我们可以将nginx的版本隐藏，如下：
server_tokens off; #在http 模块当中配置
- 1.4选择事件驱动模型
Nginx支持众多的事件驱动，比如select、poll、epoll，只能设置在events模块中设置：
events {
accept_mutex on;
multi_accept on;
use epoll; #使用epoll事件驱动，因为epoll的性能相比其他事件驱动要好很多
}
- 1.5配置单个工作进程的最大连接数
通过worker_connections number；进行设置，numebr为整数，number的值不能大于操作系统能打开的最大的文件句柄数，使用ulimit -n可以查看当前操作系统支持的最大文件句柄数，默认为为1024.
events {
worker\_connections 102400; #设置单个工作进程最大连接数102400
accept\_mutex on;
multi\_accept on;
use epoll;
}
- 1.6定义MIME-Type
在浏览器当中可以显示的内容有HTML/GIF/XML/Flash等内容，浏览器为取得这些资源需要使用MIME Type，即MIME是网络资源的媒体类型，Nginx作为Web服务器必须要能够识别全都请求的资源类型，在nginx.conf文件中引用了一个第三方文件，使用include导入：
include mime.types;
default_type application/octet-stream;
- 1.7自定义访问日志
访问日志是记录客户端即用户的具体请求内容信息，全局配置模块中的error_log是记录nginx服务器运行时的日志保存路径和记录日志的level，因此有着本质的区别，而且Nginx的错误日志一般只有一个，但是访问日志可以在不同server中定义多个，定义一个日志需要使用access_log指定日志的保存路径，使用log_format指定日志的格式，格式中定义要保存的具体日志内容：
log\_format main '$remote\_addr - $remote\_user [$time\_local] "$request" '
'$status $body\_bytes\_sent "$http\_referer" '
'"$http\_user\_agent" "$http\_x\_forwarded\_for"';
access\_log /var/log/nginx/access.log main;
- 1.8将日志定义为json格式
在使用日志分析工具如ELK对访问日志做统计的时候，就需要将日志格式定义为json格式，以便于取相应字段的key做统计，完整的定义如下：
log_format logstash_json '{"@timestamp":"$time_iso8601",'
'"host":"$server\_addr",'
'"clientip":"$remote\_addr",'
'"size":$body\_bytes\_sent,'
'"responsetime":$request\_time,'
'"upstreamtime":"$upstream\_response\_time",'
'"upstreamhost":"$upstream\_addr",'
'"http\_host":"$host",'
'"url":"$uri",'
'"domain":"$host",'
'"xff":"$http\_x\_forwarded\_for",'
'"referer":"$http\_referer",'
'"agent":"$http\_user\_agent",'
'"status":"$status"}';
server {
listen 8090;
server_name samsung.chinacloudapp.cn;
access_log /var/log/nginx/samsung1.access.log logstash_json;
location / {
root html;
index index1.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
access\_log /var/log/nginx/json.access.log logstash\_json; #定义日志路径为/var/log/nginx/json.access.log,并引用在主配置文件nginx.conf中定义的json日志格式
复制代码
json格式的日志内如下：
{"@timestamp":"2016-04-25T13:16:29+08:00","host":"192.168.0.202","clientip":"106.120.73.171","size":0,"responsetime":0.000,"upstreamtime":"-","upstreamhost":"-","http_host":"samsung.chinacloudapp.cn","url":"/index1.html","domain":"samsung.chinacloudapp.cn","xff":"-","referer":"-","agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36","status":"304"}
- 1.9配置允许sendfile方式传输文件
是由后端程序负责把源文件打包加密生成目标文件，然后程序读取目标文件返回给浏览器；这种做法有个致命的缺陷就是占用大量后端程序资源，如果遇到一些访客下载速度巨慢，就会造成大量资源被长期占用得不到释放（如后端程序占用的CPU/内存/进程等），很快后端程序就会因为没有资源可用而无法正常提供服务。通常表现就是 nginx报502错误，而sendfile打开后配合location可以实现有nginx检测文件使用存在，如果存在就有nginx直接提供静态文件的浏览服务，因此可以提升服务器性能.
可以配置在http、server或者location模块，配置如下：
sendfile on;
sendfile\_max\_chunk 512k; #Nginxg工作进程每次调用sendfile()传输的数据最大不能超出这个值，默认值为0表示无限制，可以设置在http/server/location模块中。
- 1.10配置nginx工作进程最大打开文件数
可以设置为linux系统最大打开的文件数量一致，在全局模块配置
worker_rlimit_nofile 65535;
- 1.11会话保持时间
用户和服务器建立连接后客户端分配keep-alive链接超时时间，服务器将在这个超时时间过后关闭链接，我们将它设置低些可以让ngnix持续工作的时间更长，1.8.1默认为65秒，一般不超过120秒。
keepalive_timeout 65 60; #后面的60为发送给客户端应答报文头部中显示的超时时间设置为60s：如不设置客户端将不显示超时时间。
Keep-Alive:timeout=60 #浏览器收到的服务器返回的报文
如果设置为0表示关闭会话保持功能，将如下显示：
Connection:close #浏览器收到的服务器返回的报文
- 1.12配置网络监听
使用命令listen，可以配置监听IP+端口，端口或监听unix socket:
listen 8090; #监听本机的IPV4和IPV6的8090端口，等于listen *:8000
listen 192.168.0.1:8090; #监听指定地址的8090端口
listen Unix:/www/file #监听unix socket
2server部分主要配置
- 2.1基于域名和IP的虚拟主机
server_name localhost www.a.com; ＃多个域名用空格间隔即可
server_name 192.168.0.2; #IP是本机的网卡IP地址
- 2.2if指令
- 2.2.1语法
| key | value |
|---|---|
| 语法: | if (condition) { … } |
| 默认值: | — |
| 上下文: | server, location |
-
2.2.2条件
-
1)变量名；如果变量值为空或者是以"0"开始的字符串，则条件为假；
-
2)使用"="和"!="运算符比较变量和字符串；
-
3)使用""（大小写敏感）和"*"（大小写不敏感）运算符匹配变量和正则表达式。正则表达式可以包含匹配组，匹配结果后续可以使用变量$1…$9引用。如果正则表达式中包含字符"}"或者";"，整个表达式应该被包含在单引号或双引号的引用中。
-
4)使用"-f"和"!-f"运算符检查文件是否存在；
-
5)使用"-d"和"!-d"运算符检查目录是否存在；
-
6)使用"-e"和"!-e"运算符检查文件、目录或符号链接是否存在；
-
7)使用"-x"和"!-x"运算符检查可执行文件；
例如：
if ($http_user_agent ~ MSIE) {
return 200 'IE \>\_\>';
}
if (KaTeX parse error: Undefined control sequence: \* at position 15: http\_cookie ~\̲*̲ "id=([^;]…)") {
set $id $1;
}
if ($http_refer != 'test.tyloafer.cn') {
return 403;
}
if ($vip) {
limit\_rate 10k;
}
if (!-e $request_uri) {
rewrite /(.\*)$ /index.php?r=$request\_uri;
}
- 2.3location配置
- 2.3.1location语法
location指令可以用于虚拟服务器server部分，并且意味着提供来自客户端的URI或者内部重定向访问。除少数情况外，location也可以被嵌套使用
格式如下
location [modifier] url {……}
或者是命名location
location @name {……}
命名location仅对内部访问重定向，在进入一个location之前他会保留被请求的URI部分，命名location只可以在server级别定义。
location [=||*|^~] uri { … }
其中，方括号中的四种标识符是可选项，用来改变请求字符串和uri的匹配方式。uri是待匹配的请求字符串，可以是不包含正则的字符串，这种模式被称为"标准的uri"；也可以包含正则，这种模式被称为"正则uri"。
- 2.3.2四种可选标识符
| 标识符 | 描述 |
|---|---|
| = | 精确匹配： 用于标准uri前，要求请求字符串和uri严格匹配。如果匹配成功就停止匹配，立即执行该location里面的请求。 |
| ~ | 正则匹配： 用于正则uri前，表示uri里面包含正则，并且区分大小写。 |
| ~* | 正则匹配： 用于正则uri前，表示uri里面包含正则，不区分大小写。 |
| ^~ | 非正则匹配； 用于标准uri前，nginx服务器匹配到前缀最多的uri后就结束，该模式匹配成功后，不会使用正则匹配。 |
| 无 | 普通匹配（最长字符匹配）； 与location顺序无关，是按照匹配的长短来取匹配结果。若完全匹配，就停止匹配。 |
- 2.3.3匹配顺序及优先级
(=) >(^~) > (~) >(~*) > (/filename) >(/)
精确匹配 > 非正则匹配 > 正则匹配 >普通匹配
多个 location 配置的情况下匹配顺序为：
- 1)首先精确匹配 =
- 2)其次前缀匹配 ^~
- 3)其次是按文件中顺序的正则匹配
- 4)然后匹配不带任何修饰的前缀匹配。
- 5)最后是交给 / 通用匹配
- 6)当有匹配成功时候，停止匹配，按当前匹配规则处理请求
例如：
location = / {
echo "规则A";
}
location = /login {
echo "规则B";
}
location ^~ /static/ {
echo "规则C";
}
location ^~ /static/files {
echo "规则X";
}
location ~ .(gif|jpg|png|js|css)$ {
echo "规则D";
}
location ~* .png$ {
echo "规则E";
}
location /img {
echo "规则Y";
}
location / {
echo "规则F";
}
那么产生的效果如下：
-
1)访问根目录 /，比如 http://localhost/ 将匹配 规则A
-
2)访问 http://localhost/login 将匹配 规则B，http://localhost/register 则匹配 规则F
-
3)访问 http://localhost/static/a.html 将匹配 规则C
-
4)访问 http://localhost/static/files/a.exe 将匹配 规则X，虽然 规则C 也能匹配到，但因为最大匹配原则，最终选中了 规则X。你可以测试下，去掉规则 X ，则当前 URL 会匹配上 规则C。
-
5)访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配 规则D 和 规则 E ，但是 规则 D 顺序优先，规则 E 不起作用，而 http://localhost/static/c.png 则优先匹配到 规则 C
-
6)访问 http://localhost/a.PNG 则匹配 规则 E ，而不会匹配 规则 D ，因为 规则 E 不区分大小写。
-
7)访问 http://localhost/img/a.gif 会匹配上 规则D,虽然 规则Y 也可以匹配上，但是因为正则匹配优先，而忽略了 规则Y。
-
8)访问 http://localhost/img/a.tiff 会匹配上 规则Y。
-
9)访问 http://localhost/category/id/1111 则最终匹配到规则 F ，因为以上规则都不匹配，这个时候应该是 Nginx 转发请求给后端应用服务器，比如 FastCGI（php），tomcat（jsp），Nginx 作为反向代理服务器存在。
-
2.4rewrite配置
-
2.4.1语法
| key | value |
|---|---|
| 语法: | rewrite regex replacement [flag]; |
| 默认值: | — |
| 上下文: | server, location, if |
-
2.4.2flag
-
- last # 停止执行当前这一轮的ngx_http_rewrite_module指令集，然后查找匹配改变后URI的新location；
-
- break # 停止执行当前这一轮的ngx_http_rewrite_module指令集；
-
- redirect # 在replacement字符串未以"http://"或"https://"开头时，使用返回状态码为302的临时重定向；
-
- permanent # 返回状态码为301的永久重定向。
-
2.5proxy_pass配置
-
2.5.1什么是代理服务器
客户机发送请求时，不会直接发送到目的主机，而是先被代理服务器收到，代理服务器收到客服机的请求后，再向目的机发出，目的机就会返回数据给客户机，在返回给客户机之前，会被代理服务器先收到，会存放在代理服务器的硬盘中。然后代理服务器会再向客户机发出，最后客户机就会收到目的机返回的数据。
- 2.5.2代理服务器的作用有哪些
- 2.5.2.1可以提高访问速度
因为目标主机返回的数据会存放在代理服务器的硬盘中，因此下一次客户机再次访问相同的站点数据的时候，会直接从代理服务器的硬盘中读取，因此响应速度会更快。
- 2.5.2.2防火墙的作用
由于所有的客户机请求都必须通过代理服务器访问远程站点，因此可在代理服务器上设限，过滤一些不安全的信息。
- 2.5.3理解什么是反向代理
反向代理是指以代理服务器接收Internet上的链接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求连接的客户端。
什么意思呢？上面的解释可能有点不好理解，那么下面我们先来打个比方，比如我的内部服务器是放在212环境上，那么开发的接口如下这样的：
http://192.168.1.212:8136/xxxx 然后端口号是8136，然后直接访问该接口会返回对应的数据，但是接口一般都是域名访问的，因此我们需要在nginx上配置一个域名，假如为 xy.xxx.com, 然后当我们在联调接口的时候，我们使用 http://xy.xxx.com/xxxx 这样的接口时，它会反向代理到 http://192.168.1.212:8136/xxxx 上来，这样它会返回内部服务器的数据给客户端，客户端就拿到对应的数据显示出来了。
- 2.5.4理解proxy_pass指令
该指令是用来设置代理服务器的地址，可以是主机名称，IP地址加端口号等形式。基本语法如下所示：
proxy_pass: URL;
在nginx中配置proxy_pass代理转发时，如果在proxy_pass后面的url加/，表示绝对根路径；如果没有/，表示相对路径，把匹配的路径部分也给代理走。
假设下面四种情况分别用 http://192.168.1.1/proxy/test.html 进行访问。
- 2.5.4.1第一种：
location /proxy/ {
proxy_pass http://127.0.0.1/;
}
代理到URL：http://127.0.0.1/test.html
- 2.5.4.2第二种（相对于第一种，最后少一个 / ）
location /proxy/ {
proxy_pass http://127.0.0.1;
}
代理到URL：http://127.0.0.1/proxy/test.html
- 2.5.4.3第三种：
location /proxy/ {
proxy_pass http://127.0.0.1/aaa/;
}
代理到URL：http://127.0.0.1/aaa/test.html
- 2.5.4.4第四种（相对于第三种，最后少一个 / ）
location /proxy/ {
proxy_pass http://127.0.0.1/aaa;
}
代理到URL：http://127.0.0.1/aaatest.html
- 2.5.4.5域名代理
location /zdpyc/door {
proxy_pass http:/www.baidu.com/
}
- 2.5.5proxy参数配置
proxy_connect_timeout 60s;
proxy_send_timeout 900;
proxy_read_timeout 1200;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr; #ip
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host h o s t : host: host:server_port;
proxy_set_header Cache-Control no-cache;
proxy_intercept_errors on;
- 2.5.6跨域问题
在我们访问文件的时候，会出现
No 'Access-Control-Allow-Origin' header is present on the requested resource.之类的提示，遇到这种问题最简单的方式就是在服务器进行配置，当然客户端的方式就是jsonp，但是麻烦，还是下面的解决方式比较简单
nginx/nginx.conf
加入如下代码
http {
###start####
add_header 'Access-Control-Allow-Origin' "*" always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Accept, Authorization, Cache-Control, Content-Type, DNT, If-Modified-Since, Keep-Alive, Origin, User-Agent, X-Requested-With, Token, x-access-token' always;
###end ###
}
- 2.6upstream 指令
- 2.6.1语法
| 语法: | upstream name { … } |
|---|---|
| 默认值: | — |
| 上下文: | http |
- 2.6.2upstream负载均衡策略
- 2.6.2.1轮询(weight=1)
默认选项，当weight不指定时，各服务器weight相同，
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream bakend {
server 192.168.1.10;
server 192.168.1.11;
}
- 2.6.2.2权重weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
如果后端服务器down掉，能自动剔除。
比如以下配置，则1.11服务器的访问量为1.10服务器的两倍。
upstream bakend {
server 192.168.1.10 weight=1;
server 192.168.1.11 weight=2;
}
- 2.6.2.3ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session不能跨服务器的问题。
如果后端服务器down掉，要手工down掉。
upstream resinserver{
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
4、fair（第三方插件）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream resinserver{
server 192.168.1.10:8080;
server 192.168.1.11:8080;
fair;
}
- 2.6.2.4url_hash（第三方插件）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存服务器时比较有效。
在upstream中加入hash语句，hash_method是使用的hash算法。
upstream resinserver{
server 192.168.1.10:8080;
server 192.168.1.11:8080;
hash $request_uri;
hash_method crc32;
}
-
2.6.3设备的状态
-
1)down 表示单前的server暂时不参与负载
-
2)weight 权重,默认为1。 weight越大，负载的权重就越大。
-
3)max_fails 允许请求失败的次数默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误
-
4)fail_timeout max_fails次失败后，暂停的时间。
-
5)backup 备用服务器, 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。-
-
2.6.4负载均衡实例
upstream tel_img_stream {
#ip_hash;
server 192.168.11.68:20201;
server 192.168.11.69:20201 weight=100 down;
server 192.168.11.70:20201 weight=100;
server 192.168.11.71:20201 weight=100 backup;
server 192.168.11.72:20201 weight=100 max_fails=3 fail_timeout=30s;
}
说明:
1)、down 表示当前的server暂时不参与负载
2)、weight 默认为1.weight越大，负载的权重就越大。
3)、backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
4)、上例中192.168.11.72:20201 设置最大失败次数为 3，也就是最多进行 3 次尝试，且超时时间为 30秒。max_fails 的默认值为 1，fail_timeout 的默认值是 10s。
注意，当upstream中只有一个 server 时，max_fails 和 fail_timeout 参数可能不会起作用。
weight\backup 不能和 ip_hash 关键字一起使用。http://www.jbxue.com/article/26828.html
最后在需要使用负载均衡的server中增加 proxy_pass http://tel_img_stream/;
3sysctl.conf针对IPv4内核的7个参数的配置优化：
- 1)net.core.netdev_max_backlog #每个网络接口的处理速率比内核处理包的速度快的时候，允许发送队列的最大数目。
[root@Server1 nginx]# sysctl -a | grep max_backlog
net.core.netdev_max_backlog = 1000 这里默认是1000，可以设置的大一些，比如：
net.core.netdev_max_backlog = 102400
- 2)net.core.somaxconn: #用于调节系统同时发起的TCP连接数，默认值一般为128，在客户端存在高并发请求的时候，128就变得比较小了，可能会导致链接超时或者重传问题。
net.core.somaxconn = 128 #默认为128，高并发的情况时候要设置大一些，比如：
net.core.somaxconn = 102400
- 3)net.ipv4.tcp_max_orphans:设置系统中做多允许多少TCP套接字不被关联到任何一个用户文件句柄上，如果超出这个值，没有与用户文件句柄关联的TCP套接字将立即被复位，同时给出警告信息，这个值是简单防止DDOS（Denial of service）的攻击，在内存比较充足的时候可以设置大一些：
net.ipv4.tcp_max_orphans = 32768 #默认为32768，可以改该打一些：
net.ipv4.tcp_max_orphans = 102400
- 4)net.ipv4.tcp_max_syn_backlog #用于记录尚未收到客户度确认消息的连接请求的最大值，一般要设置大一些：
net.ipv4.tcp_max_syn_backlog = 256 #默认为256，设置大一些如下：
net.ipv4.tcp_max_syn_backlog = 102400
- 5)net.ipv4.tcp_timestamps #用于设置时间戳，可以避免序列号的卷绕，有时候会出现数据包用之前的序列号的情况，此值默认为1表示不允许序列号的数据包，对于Nginx服务器来说，要改为0禁用对于TCP时间戳的支持，这样TCP协议会让内核接受这种数据包，从而避免网络异常，如下：
net.ipv4.tcp_timestamps = 1 #默认为1，改为0，如下：
net.ipv4.tcp_timestamps = 0
- 6)net.ipv4.tcp_synack_retries #用于设置内核放弃TCP连接之前向客户端发生SYN+ACK包的数量，网络连接建立需要三次握手，客户端首先向服务器发生一个连接请求，服务器收到后由内核回复一个SYN+ACK的报文，这个值不能设置过多，会影响服务器的性能，还会引起syn攻击：
net.ipv4.tcp_synack_retries = 5 #默认为5，可以改为1避免syn攻击
net.ipv4.tcp_synack_retries = 1
- 7)net.ipv4.tcp_syn_retries #与上一个功能类似，设置为1即可：
net.ipv4.tcp_syn_retries = 5 #默认为5，可以改为1
net.ipv4.tcp_syn_retries = 1
4 配置文件中针对CPU的2个优化参数
-
1)woker_precess #设置Nginx 启动多少个工作进程的数量
-
2)woker_cpu_affinit #固定Nginx 工作进程所运行的CPU核心
5 配置文件中与网络相关的4个指令
- 1)keepalived_timeout 60 50； #设置Nginx服务器与客户端保持连接的时间是60秒，到60秒后服务器与客户端断开连接，50s是使用Keep-Alive消息头与部分浏览器如 chrome等的连接事件，到50秒后浏览器主动与服务器断开连接。
keepalived_timeout 60 50;
- 2)sendtime_out 10s #Http核心模块指令，指定了发送给客户端应答后的超时时间，Timeout是指没有进入完整established状态，只完成了两次握手，如果超过这个时间客户端没有任何响应，nginx将关闭与客户端的连接。
sendtime_out 10s;
- 3)client_header_timeout #用于指定来自客户端请求头的headerbuffer大小，对于大多数请求，1kb的缓冲区大小已经足够，如果自定义了消息头部或有更大的cookie，可以增加缓冲区大小。
client_header_timeout 4k;
-
4)multi_accept #设置是否允许，Nginx在已经得到一个新连接的通知时，接收尽可能更多的连接。
multi_accept on;
6 配置文件中与驱动模型相关的8个指令
-
1)use； #用于指定Nginx 使用的事件驱动模型
-
2)woker_process； #指定Nginx启动的工作进程的数量
-
3)woker_connections 65535； #指定Nginx 每个工作进程的最大连接数，woker_connections * woker_process即为Nginx的最大连接数量。
-
4)woker_rlimit_sigpending 65535 #Nginx每个进程的事件信号队列的上限长度，如果超出长度，Nginx则使用poll模型处理客户的请求。
-
5)devpoll_changes 和 devpoll_events #用于设置Nginx 在/dev/poll 模型下Nginx服务器可以与内核之间传递事件的数量，前一个设置传递给内核的事件数量，后一个设置从内核读取的事件数量，默认为512。
-
6)kqueue_changes 和 kqueue_events #设置在kqueue模型下Nginx服务器可以与内核之间传递事件的数量，前一个设置传递给内核的事件数量，后一个设置从内核读取的事件数量，默认为512。
-
7)epoll_events #设置在epoll驱动模式下Nginx 服务器可以与内核之间传递事件的数量，默认为512。
-
8)rtsig_signo #设置Nginx在rtsig 模式使用的两个信号中的第一个，第二个信号是在第一个信号的编号上加1.
-
9)rtsig_overflow #这些参数指定如何处理rtsig队列溢出。当溢出发生在nginx清空rtsig队列时，它们将连续调用poll()和 rtsig.poll()来处理未完成的事件，直到rtsig被排空以防止新的溢出，当溢出处理完毕，nginx再次启用rtsig模式，rtsig_overflow_events specifies指定经过poll()的事件数，默认为16，rtsig_overflow_test指定poll()处理多少事件后nginx将排空rtsig队列，默认值为32，rtsig_overflow_threshold只能运行在Linux 2.4.x内核下，在排空rtsig队列前nginx检查内核以确定队列是怎样被填满的。默认值为1/10，"rtsig_overflow_threshold 3"意为1/3。
7Nginx中并发性能相关配置参数说明
worker_processes：开启worker进程的数目，通常可设置为CPU核心的倍数。在不清楚的情况下，可设置成一倍于CPU核心数或auto(Nginx将自动发现CPU核心数)。
worker_connections：单个worker可处理并发连接的上限，但实际并发连接数能否达到这个值还与系统其他资源限制有关。当前Nginx实例可处理的并发连接数为 worker_processes * worker_connections。
worker_rlimit_nofile：worker可打开文件数上限(每个套接字打开一个文件描述符)，worker_rlimit_nofile类似于系统配置ulimit -n(不过ulimit -n设置的最大值不能超过65536，且只能在当前shell环境中生效，重启后无效)。
limit_conn_zone：定义连接域，通常要与limit_conn配合使用。
limit_conn_zone $binary_remote_addr zone=addr:10m;#shared memory size: 10m
limit_conn：为指定域中的每个key配置并发连接数，当实际连接请求数超出该值则拒绝。
limit_conn_zone $binary_remote_addr zone=addr:10m;#shared memory size 10m
server {
...
limit\_conn addr 1;#allow only one connection per an IP address at a time.
}
但要记住的是，
In HTTP/2 and SPDY, each concurrent request is considered a separate connection.
limit_conn_status：当连接请求被拒绝后返回的状态码，默认503。
limit_req_zone：它是基于漏桶(Leaky Bucket)算法实现的，
复制代码
http {
limit\_req\_zone $binary\_remote\_addr zone=one:10m rate=10r/m;
...
server {
...
location /search/ {
limit\_req zone=one burst=5 nodelay;
}
复制代码
limit_req：来不及处理的请求被延迟执行，直到它们的数量超过burst(漏桶的最大容量，默认为0)，即溢出(Nginx将拒绝该请求)；在上例中，nodelay表示在记时一分钟内，即使请求未溢出，只要是超出了10个后也直接拒绝。
limit_req_status：当请求被拒绝后返回的状态码，默认503。
limit_rate：这是ngx_http_core_module提供的功能，用于限制Nginx的下载速率。如果是对代理限速，也可以使用X-Accel-Limit-Rate响应头。
location /download {
limit\_rate\_after 10m;
limit\_rate 128k;
}
limit_rate_after：通常与limit_rate一起使用。在上例中，10m以前不限速，10m以后才限制下载速率。
accept_mutex：默认为off，V1.11.3前默认为on， There is no need to enable accept_mutex on systems that support the EPOLLEXCLUSIVE flag (1.11.3) or when using reuseport. 当一个新连接到来时，所有可用的worker将从等待状态被唤醒，最终却只有一个worker能接受并处理连接，这就是所谓的惊群现象；如果这种现象每秒重复多次，将导致服务器性能下降，因为所有被唤醒的worker都在占用CPU时间，而增加了非生产性CPU周期和未使用的上下文切换。但Linux系统底层已经解决了这个问题，Nginx 自1.11.3开始支持EPOLLEXCLUSIVE flag，因此accept_mutex默认变为off。
events {
accept\_mutex on;#worker processes will accept new connections by turn.
}
accept_mutex_delay：当启用accept_mutex时，只有一个具有互斥锁的worker接受连接，其他worker则轮流等待accept_mutex_delay指定的时间。
multi_accept：默认为off。值为on使得worker能够在获得新连接通知时接受所有连接并放到监听队列中，值为off使得worker将逐个接受新连接。
thread_pool：采用asynchronous file I/O (AIO)，多线程读写不锁worker。Nginx 1.7.11以上的版本可使用，加 --with-threads 配置参数编译。
上图展示了Nginx的事件队列是在循环中顺序执行的，可能存在又长又重的操作(阻塞操作)导致事件处理循环卡住，其他事件必须等待这个操作执行完毕，因此而引入线程池；但在cache情景下，线程池并不会带来性能提升，反而应避免使用。
Syntax: thread_pool name threads=number [max_queue=number];
Default: thread_pool default threads=32 max_queue=65536;
Context: main
This directive appeared in version 1.7.11.
复制代码
http {
thread\_pool one threads=128 max\_queue=0;
thread\_pool two threads=32;
server {
location /one {
aio threads=one;
}
location /two {
aio threads=two;
}
}
…
}
复制代码
aio(asynchronous file I/O)：开启或关闭异步文件I/O功能，它也允许aio使用线程池。Nginx官方给aio使用线程池的测试案例得9倍性能提升，可参考 NGINX引入线程池 性能提升9倍。
Syntax: aio on | off | threads[=pool];
Default: aio off;
Context: http, server, location
keepalive： 在每一个worker进程的cache中创建一个到upstream的空闲keepalive连接池。如果keepalive池中的连接用完，Nginx依然可以向upstream发出更多的新连接，连接池只是起到缓存空闲keepalive连接的作用。It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open. The connections parameter should be set to a number small enough to let upstream servers process new incoming connections as well.
复制代码
upstream fastcgi_backend {
server 127.0.0.1:9000;
keepalive 8;#连接池最大容量8。When this number is exceeded, the least recently used connections are closed.
}
server {
...
location /fastcgi/ {
fastcgi\_pass fastcgi\_backend;
fastcgi\_keep\_conn on;
...
}
}
如果正常流量并不高，某些参数设置无需过高；否则，一旦遭遇DDOS攻击，将有可能导致服务器瘫痪。
8附录
- 8.1常见http状态码
HTTP响应码，也称http状态码(HTTP Status Code)，反映了web服务器处理HTTP请求状态，每一个响应码都代表了一种服务端反馈的响应状态，标识了本次请求是否成功。我们应该了解常见的响应码代表的状态，通过响应码能够对错误进行排查和定位。
- 8.1.11XX——信息类（Information）
表示收到http请求，正在进行下一步处理，通常是一种瞬间的响应状态
100 (Continue)：信息型状态响应码表示目前为止一切正常, 客户端应该继续请求, 如果已完成请求则忽略
101 (Switching Protocol)：状态码表示服务器应客户端升级协议的请求（Upgrade请求头）正在进行协议切换。
- 8.1.22XX——成功类（Successful）
表示用户请求被正确接收、理解和处理
200（成功）：请求成功。一般用于GET与POST请求
201（已创建）：已创建。成功请求并创建了新的资源
202（已接受）：表示服务器端已经收到请求消息，但是尚未进行处理。但是对于请求的处理确实无保证的，即稍后无法通过 HTTP 协议给客户端发送一个异步请求来告知其请求的处理结果。这个状态码被设计用来将请求交由另外一个进程或者服务器来进行处理，或者是对请求进行批处理的情形。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求
- 8.1.33XX——重定向类（Redirection）
表示没有请求成功，必须采取进一步的动作
300 （多种选择） 针对请求，服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
- 8.1.44XX——客户端错误（Client Error）
表示客户端提交的请求包含语法错误或不能正确执行
400（Bad Requests）：客户端请求的地址不存在或者包含不支持的参数
401（Unauthorized）：未授权，或认证失败。对于需要登录的网页，服务器可能返回此响应
403（Forbidden）：没权限。服务器收到请求，但拒绝提供服务
404（Not Found）：请求的资源不存在。遇到404首先检查请求url是否正确
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足'期望'请求标头字段的要求。
- 8.1.55XX——服务端错误（Server Error）
表示服务器不能正确执行一个正确的请求（客户端请求的方法及参数是正确的，服务端不能正确执行，如网络超时、服务僵死，可以查看服务端日志再进一步解决）
500（Internal Server Error）：服务器内部错误，无法完成请求
503（Service Unavailable）：由于超载或系统维护（一般是访问人数过多），服务器无法处理客户端的请求 ，通常这只是暂时状态。
9 Nginx 配置工具
Nginx 配置工具