【干货】企业级Nginx Web服务优化实战（上）
优采云 发布时间: 2022-05-20 20:15【干货】企业级Nginx Web服务优化实战（上）
server_tokens参数的官方说明如下：syntax: server_tokens on|off; #此行为参数语法，on为开启状态，off为关闭状态default: server_tokens on; #此行意思是不配置该参数，软件默认情况的结果context: http,server,location #此行为server_tokens参数可以放置的位置参数作用：激活或禁止Nginx的版本信息显示在报错信息和Server的响应首部位置中。
官方资料地址：
配置完毕后保存，重新加载配置文件，再次通过curl查看，结果如下：
[root@LNMP nginx]# curl -I 192.168.0.220HTTP/1.1 200 OKServer: nginx #版本号已经消失Date: Wed, 23 Aug 2017 11:22:15 GMTContent-Type: text/html; charset=UTF-8Connection: keep-aliveX-Powered-By: PHP/5.3.28Link: ; rel="https://api.w.org/"
<p><br />
此时，浏览器的报错提示中没有了版本号，如下图所示，修改成功。</p>
1.2 更改源码隐藏Nginx软件名及版本号
隐藏了Nginx版本号后，更进一步，可以通过一些手段把Web服务软件的名称也隐藏起来，或者更改为其他Web服务软件名以迷惑黑客。但软件名字的隐藏修改，一般情况下不会有配置参数和入口，Nginx也不例外，这可能是由于商业及品牌展示等原因，软件提供商不希望使用者把软件名字隐藏起来。因此，此处需要更改Nginx源代码，具体的解决方法如下：
1.2.1 第一步：依次修改3个Nginx源码文件。
修改的第一个文件为nginx-1.6.3/src/core/nginx.h,如下：
[root@LNMP ~]# cd /usr/src/nginx-1.6.2/src/core/[root@LNMP core]# ls -l nginx.h-rw-r--r--. 1 1001 1001 351 Sep 16 2014 nginx.h[root@LNMP core]# sed -n '13,17p' nginx.h#define NGINX_VERSION "1.6.2" #修改为想要显示的版本号#define NGINX_VER "nginx/" NGINX_VERSION#将nginx修改为想要修改的软件名称。#define NGINX_VAR "NGINX" #将nginx修改为想要修改的软件名称#define NGX_OLDPID_EXT ".oldbin"
修改后的结果如下：<br />
[root@LNMP core]# sed -n '13,17p' nginx.h#define NGINX_VERSION "0.0.0.0"#define NGINX_VER "yunjisuan/" NGINX_VERSION<br />#define NGINX_VAR "YUNJISUAN"#define NGX_OLDPID_EXT ".oldbin"
修改的第二个文件是nginx-1.6.3/src/http/ngx_http_header_filter_module.c的第49行，需要修改的字符串内容如下：
<br />
ls -l /usr/src/nginx-1.6.2/src/http/ngx_http_header_filter_module.c -rw-r--r--. 1 1001 1001 19321 Sep 16 2014 /usr/src/nginx-1.6.2/src/http/ngx_http_header_filter_module.c[root@LNMP http]# grep -n 'Server: nginx' ngx_http_header_filter_module.c 49:static char ngx_http_server_string[] = "Server: nginx" CRLF; #修改本行结尾的nginx
通过sed替换修改，后如下：<br />
[root@LNMP http]# grep -n 'Server: nginx' ngx_http_header_filter_module.c 49:static char ngx_http_server_string[] = "Server: nginx" CRLF;[root@LNMP http]# sed -i 's#Server: nginx#Server: yunjisuan#g' ngx_http_header_filter_module.c [root@LNMP http]# grep -n 'Server: yunjisuan' ngx_http_header_filter_module.c 49:static char ngx_http_server_string[] = "Server: yunjisuan" CRLF;
修改的第三个文件是nginx-1.6.3/src/http/nginx_http_special_response.c,对面页面报错时，它会控制是否展开敏感信息。这里输出修改前的信息ngx_http_special_response.c中的第21~30行，如下：
[root@LNMP http]# sed -n '21,30p' ngx_http_special_response.c static u_char ngx_http_error_full_tail[] ="" NGINX_VER "" CRLF #此行需要修改"" CRLF"" CRLF;<br />static u_char ngx_http_error_tail[] ="nginx" CRLF #此行需要修改"" CRLF
修改后的结果如下：<br />
[root@LNMP nginx-1.6.2]# sed -n '21,32p' src/http/ngx_http_special_response.c static u_char ngx_http_error_full_tail[] ="" NGINX_VER " (Mr.chen 2018-08-26)" CRLF #此行是定义对外展示的内容"" CRLF"" CRLF;<br /><br />static u_char ngx_http_error_tail[] ="yunjisuan" CRLF #此行将对外展示的Nginx名字更改为yunjisuan"" CRLF"" CRLF;
1.2.2 第二步是修改后编辑软件，使其生效
修改后再编译安装软件，如果是已经安装好的服务，需要重新编译Nginx，配好配置，启动服务。
再次使浏览器出现404错误，然后看访问结果，如下图所示：
如上面所示：Nginx的软件和版本名都被改掉了，并且加上了本人的大名。
再看看Linux curl命令响应头部信息，如下：
[root@LNMP conf]# curl -I localhost/xxx/HTTP/1.1 404 Not FoundServer: yunjisuan/0.0.0.0 #也更改了Date: Wed, 23 Aug 2017 15:33:54 GMTContent-Type: text/htmlContent-Length: 196Connection: keep-alive
1.3 更改Nginx服务的默认用户<br />
[root@LNMP conf]# cd /usr/local/nginx/conf/[root@LNMP conf]# grep "#user" nginx.conf.default#user nobody;
为了防止黑客猜到这个Web服务的用户，我们需要更改成特殊的用户名，例如nginx或特殊点的inca，但是这个用户必须是系统里事先存在的，下面以nginx用户为例进行说明。
（1）为Nginx服务建立新用户
useradd nginx -s /sbin/nologin -M#不需要有系统登录权限，应当禁止登陆。
（2）配置Nginx服务，让其使用刚建立的nginx用户<br />
更改Nginx服务默认使用用户，方法有二：
第一种：直接更改配置文件参数，将默认的#user nobody；改为如下内容：
user nginx nginx;
如果注释或不设置上述参数，默认为nobody用户，不推荐使用nobody用户名，最好采用一个普通用户，此处用大家习惯的，前面建立好的nginx用户。
第二种：直接在编译nginx软件时指定编译的用户和组，命令如下：
./configure --user=nginx --group=nginx --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module<br />#提示：#前文在编译Nginx服务时，就是这样带着参数的，因此无论配置文件中是否加参数，默认都是nginx用户。
（3）检查更改用户的效果<br />
重新加载配置后，检查Nginx服务进程的对应用户，如下：
[root@LNMP conf]# ps -ef | grep nginx | grep -v greproot 52023 1 0 11:30 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginxnginx 52024 52023 0 11:30 ? 00:00:00 nginx: worker process
<p><br />
通过查看上述更改后的Nginx进程，可以看到worker processes进程对应的用户都变成了nginx。所以，我们有理由得出结论，上述的两种方法都可设置Nginx的worker进程运行的用户。当然，Nginx的主进程还是以root身份运行的。</p>
二，根据参数优化Nginx*敏*感*词*能2.1 优化Nginx服务的worker进程个数2.1.1 优化Nginx进程对应的配置
#优化Nginx进程对应Nginx服务的配置参数如下：worker_processes 1; #指定了Nginx要开启的进程数，结尾数字就是进程个数<br />上述参数调整的是Nginx服务的worker进程数，Nginx有Master进程和worker进程之分，Master为管理进程，真正接待“顾客”的是worker进程。
<p><br /></p>
2.1.2 优化Nginx进程个数的策略2.1.3 查看Web服务器CPU硬件资源信息
下面介绍查看Linux服务器CPU总核数的方法：
（1）通过/proc/cpuinfo可查看CPU个数及总核数。查看CPU总核数的示例如下：
[root@LNMP ~]# grep processor /proc/cpuinfo processor : 0processor : 1processor : 2processor : 3[root@LNMP ~]# grep processor /proc/cpuinfo | wc -l4 #表示为1颗CPU四核[root@LNMP ~]# grep -c processor /proc/cpuinfo4 #表示为1颗CPU四核<br />#查看CPU总颗数示例如下：[root@LNMP ~]# grep "physical id" /proc/cpuinfo physical id : 0 #物理ID一致，同一颗CPUphysical id : 0 #物理ID一致，同一颗CPUphysical id : 0 #物理ID一致，同一颗CPUphysical id : 0 #物理ID一致，同一颗CPU[root@LNMP ~]# grep "physical id" /proc/cpuinfo | sort | uniq | wc -l1 #去重复，表示1颗CPU
（2）通过执行top命令，然后按数字1，即可显示所有的CPU核数，如下：
2.1.4 实践修改Nginx配置
假设服务器的CPU颗数为1颗，核数为4核，则初始的配置可通过查看默认的nginx.conf里的worker_processes数来了解，命令如下:
[root@LNMP ~]# grep worker_processes /usr/local/nginx/conf/nginx.confworker_processes 1;[root@LNMP ~]# sed -i 's#worker_processes 1#worker_processes 4#' /usr/local/nginx/conf/nginx.conf[root@LNMP ~]# grep worker_processes /usr/local/nginx/conf/nginx.confworker_processes 4; #提示可以通过vi修改
<br />
#优雅重启Nginx，使修改生效，如下：[root@LNMP ~]# /usr/local/nginx/sbin/nginx -tnginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is oknginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful[root@LNMP ~]# /usr/local/nginx/sbin/nginx -s reload
<br />
#现在检查修改后的worker进程数量，如下：[root@LNMP ~]# ps -ef | grep "nginx" | grep -v greproot 1110 1 0 11:12 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginxnginx 1429 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1430 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1431 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1432 1110 0 11:33 ? 00:00:00 nginx: worker process
从“worker_processes 4”可知，worker进程数为4个。Nginx Master主进程不包含在这个参数内，Nginx Master的主进程为管理进程，负责调度和管理worker进程。
有关worker_processes参数的官方说明如下：
syntax: worker_processes number; #此行为参数语法，number为数量default: worker_processes 1; #此行意思是不匹配该参数，软件默认情况数量为1context: main; #此行为worker_processes参数可以放置的位置worker_processes为定义worker进程数的数量，建议设置为CPU的核数或CPU核数*2，具体情况要根据实际的业务来选择，因为这个参数，除了要和CPU核数匹配外，和硬盘存储的数据以系统的负载也有关，设置为CPU的个数或核数是一个好的起始配置。From：http://nginx.org/en/docs/ngx_core_module.html
<p><br /></p>
2.2 优化绑定不同的Nginx进程到不同的CPU上
worker_processes 4;worker_cpu_affinity 0001 0010 0100 1000;<br />#worker_cpu_affinity就是配置Nginx进程与CPU亲和力的参数，即把不同的进程分给不同的CPU处理。这里0001 0010 0100 1000是掩码，分别代表第1，2，3，4核CPU，由于worker_processes进程数为4，因此，上述配置会把每个进程分配一核CPU处理，默认情况下进程不会绑定任何CPU，参数位置为main段。
四核和八核CPU服务器的参数配置参考如下：<br />
#八核掩码worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000；<br />#四核掩码worker_cpu_affinity 0001 0010 0100 1000；<br />worker_cpu_affinity 的作用是绑定不同的worker进程数到一组CPU上。通过设置bitmask控制进程允许使用的CPU，默认worker进程不会绑定到任何CPU（自动平均分配。）
<p><br /></p>
2.2.1 实验环境准备主机名IP地址备注
Nginx
192.168.0.220
nginxWeb
测试机1
192.168.0.240
Webbench压力测试
测试机2
192.168.0.245
Webbench压力测试
#安装webbenchtar xf webbench-1.5.tar.gz cd webbench-1.5mkdir /usr/local/manmake install cleanwhich webbench.
虚拟机开启4核心<br />
2.2.2 第一步：不绑定worker进程进行压力测试
#配置文件如下：（未绑定worker进程）<br />
[root@LNMP nginx]# cat conf/nginx.confworker_processes 4;#worker_cpu_affinity 0001 0010 0100 1000;events { worker_connections 10240;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name bbs.yunjisuan.com; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }}
#在NginxWeb上执行如下命令：<br />
[root@LNMP nginx]# top -u nginxTasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombieCpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stMem: 1004412k total, 911632k used, 92780k free, 6952k buffersSwap: 2031608k total, 0k used, 2031608k free, 749976k cached<br /> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1454 nginx 20 0 49240 5640 468 S 0.0 0.6 0:00.00 nginx 1455 nginx 20 0 49240 5672 500 S 0.0 0.6 0:00.00 nginx 1456 nginx 20 0 49240 5672 500 S 0.0 0.6 0:00.00 nginx 1457 nginx 20 0 49240 5672 500 S 0.0 0.6 0:00.00 nginx
#在以上界面时按键盘的数值1键，出现如下界面：<br />
top - 14:44:46 up 36 min, 1 user, load average: 0.00, 0.00, 0.00Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombieCpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stCpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stCpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stCpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stMem: 1004412k total, 911384k used, 93028k free, 6960k buffersSwap: 2031608k total, 0k used, 2031608k free, 749976k cached<br /> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1454 nginx 20 0 49240 5640 468 S 0.0 0.6 0:00.00 nginx 1455 nginx 20 0 49240 5672 500 S 0.0 0.6 0:00.00 nginx 1456 nginx 20 0 49240 5672 500 S 0.0 0.6 0:00.00 nginx 1457 nginx 20 0 49240 5672 500 S 0.0 0.6 0:00.00 nginx
在另外的两台测试机器上同时进行压力测试，命令如下：
webbench -c 2000 -t 60 http://192.168.0.220/
结果如下：
2.2.3 第二步：绑定worker进程进行压力测试
#配置文件如下（绑定worker进程）<br />
[root@LNMP nginx]# cat conf/nginx.confworker_processes 4;worker_cpu_affinity 0001 0010 0100 1000; #修改本行events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name bbs.yunjisuan.com; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }}
在另外的两台测试机器上同时进行压力测试，命令如下：<br />
webbench -c 2000 -t 60 http://192.168.0.220/
结果如下：
根据图示，我们基本可以看出，平均绑定worker进程和不绑定的实验效果基本是一致的（CPU0是默认会被使用的）。原因在nginx在经过不断的优化后，会自动对worker进程进行动态的平均分配。
2.2.4 第三步：修改nginx配置，将所有worker进程绑定到CPU3上
#配置文件如下所示：<br />
[root@LNMP nginx]# cat conf/nginx.confworker_processes 4;worker_cpu_affinity 1000 1000 1000 1000; #修改本行events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name bbs.yunjisuan.com; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }}
在另外的两台测试机器上同时进行压力测试，命令如下：
webbench -c 2000 -t 60 http://192.168.0.220/
结果如下：
从上图我们可以得知，worker进程的压力被集中分配到了CPU3上。（CPU0是默认被使用的）
2.3 Nginx事件处理模型优化
#具体的配置参数如下：<br />
events #events指令是设定Nginx的工作模式及连接数上限{ use epoll；#use是一个事件模块指令，用来指定Nginx的工作模式。Nginx支持的工作模式有select，poll，kqueue，epoll，rtsig和/dev/poll。其中select和poll都是标准的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平台上，而kqueue用在BSD系统中。对于Linux系统Linux2.6+内核，推荐选择epoll工作模式，这是高性能高并发的设置}
根据Nginx官方文档建议，也可以不指定事件处理模型，Nginx会自动选择最佳的事件处理模型服务。
对于使用连接进程的方法，通常不需要进行任何设置，Nginx会自动选择最有效办法。
2.4 调整Nginx单个进程允许的客户端最大连接数
接下来，调整Nginx单个进程允许的客户端最大连接数，这个控制连接数的参数为work_connections。
worker_connections的值要根据具体服务器性能和程序的内存使用量来指定（一个进程启动使用的内存根据程序确定），如下：
events #events指令是设定Nginx的工作模式和连接数上线{ worker_connections 20480; #worker_connections也是个事件模块指令，用于定义Nginx每个进程的最大连接数，默认是1024.最大客户端连接数由worker_processes和worker_connections决定，即Max_client= worker_processes*worker_connections。进程的最大连接数受Linux系统进程的最大打开文件数限制，在执行操作系统命令“ulimit -HSn 65535”或配置相应文件后，worker_connections的设置才能生效。}
下面是worker_connections的官方说明<br />
参数语法：worker_connections number
默认配置：worker_connections 512
放置位置：events
说明：
worker_connections用来设置一个worker process支持的最大并发连接数，这个连接数包括了所有链接，例如：代理服务器的连接，客户端的连接等，实际的并发连接数除了受worker_connections参数控制外，还和最大打开文件数worker_rlimit_nofile有关(见下文)，Nginx总并发连接=worker数量*worker_connections。
参考资料：
2.5 配置Nginx worker进程最大打开文件数
接下来，调整配置Nginx worker进程的最大打开文件数，这个控制连接数的参数为worker_rlimit_nofile。该参数的实际配置如下：
worker_rlimit_nofile 65535;#最大打开文件数，可设置为系统优化后的ulimit -HSn的结果
下面是worker_rlimit_nofile number的官方说明：<br />
参数语法：worker_rlimit_nofile number
默认配置：无
放置位置：主标签段
说明：此参数的作用是改变worker processes能打开的最大文件数
参考资料：
备注：
Linux系统文件最大打开数设置：ulimit -n 65535
2.5.1 实验环境准备主机名IP地址备注
Nginx
192.168.0.220
nginxWeb
测试机1
192.168.0.240
Webbench压力测试
测试机2
192.168.0.245
Webbench压力测试
2.5.2 修改nginx.conf配置文件
[root@LNMP nginx]# cat conf/nginx.confworker_processes 1;#worker_cpu_affinity 0000 0010 0100 1000;#worker_rlimit_nofile 65535;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name bbs.yunjisuan.com; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }}
先定1核1024连接数。同学们注意多开几个虚拟机进行压力测试。不然的话，web服务器还没出问题，你测试服务器先down掉了。
2.5.2 测试nginx服务连接数的极值
#使用这个命令可以抓取nginx的连接数[root@LNMP nginx]# netstat -antp | grep nginx | wc -l554[root@LNMP nginx]# netstat -antp | grep nginx | wc -l471
逐渐提高压力，抓连接数，看看nginx啥时候down
2.6 开启高效文件传输模式
（1）设置参数：sendfile on;
sendfile参数用于开启文件的高效传输模式。同时将tcp_nopush和tcp_nodelay两个指令设置为on，可防止网络及磁盘I/O阻塞，提升Nginx工作效率。
#sendfile参数的官方说明如下：syntax: sendfile on | off; #参数语法default: sendfile off; #参数默认大小context: http,server,location,if in location #可以放置的标签段
参数作用：
激活或禁用sendfile()功能功能。sendfile()是作用于两个文件描述符之间的数据拷贝函数，这个拷贝操作是在内核之中的，被称为“零拷贝”，sendfile()比read和write函数要高效很多，因为，read和write函数要把数据拷贝到应用层再进行操作。相关控制参数还有sendfile_max_chunk,同学们可以执行查询。细节见#sendfile
（2）设置参数：tcp_nopush on;
#tcp_nopush参数的官方说明如下：syntax: tcp_nopush on | off; #参数语法default: tcp_nopush off; #参数默认大小context: http,server,location #可以放置的标签段
<p><br /></p>
参数作用： 激活或禁用Linux上的TCP_CORK socket选项，此选项仅仅当开启sendfile时才生效，激活这个tcp_nopush参数可以允许把http response header和文件的开始部分放在一个文件里发布，其积极的作用是减少网络报文段的数量。细节见http://nginx.org/en/docs/http/ngx_http_core_module.html。
2.7 优化Nginx连接参数，调整连接超时时间
2.7.1 什么是连接超时2.7.2 连接超时的作用
简单的说，连接超时是服务的一种自我管理，自我保护的重要机制。
2.7.3 连接超时带来的问题，以及不同程序连接设定知识2.7.4 Nginx连接超时的参数设置
（1）设置参数：keepalive_timeout 60;
用于设置客户端连接保持会话的超时时间为60秒。超过这个时间，服务器会关闭该连接，此数值为参考值。
keepalive_timeout参数的官方说明如下：syntax: keepalive_timeout timeout [header_timeout] #参数语法default: keepalive_timeout 75s; #参数默认大小context: http,serverr,location #可以放置的标签段
参数作用：
（2）设置参数：tcp_nodelay on;
用于激活tcp_ondelay功能，提高I/O性能。
#tcp_nodelay参数的官方说明如下：syntax: tcp_nodelay on | off #参数语法default: tcp_nodelay on; #参数默认大小context: http,server,location #可以放置的标签段
参数作用：
默认情况下当数据发送时，内核并不会马上发送，可能会等待更多的字节组成一个数据包，这样可以提高I/O性能。但是，在每次只发送很少字节的业务场景中，使用tcp_nodelay功能，等待时间会比较长。
参数生效条件：
激活或禁用TCP_NODELAY选项，当一个连接进入keep-alive状态时生效。细节见。
（3）设置参数：client_header_timeout 15;
用于设置读取客户端请求头数据的超时时间。此处的数值15，其单位是秒，为经验参考值。
#client_header_timeout参数的官方说明如下：syntax: client_header_timeout time; #参数语法default: client_header_timeout 60s; #参数默认大小context: http,server #可以放置的标签段
参数作用：
设置读取客户端请求头数据的超时时间。如果超过这个时间，客户端还没有发送完整的header数据，服务器端将返回“Request time out (408)”错误，可指定一个超时时间，防止客户端利用http协议进行攻击。细节见：。
（4）设置参数：client_body_timeout 15;
用于设置读取客户端请求主体的超时时间，默认值60
#client_body_timeout参数的官方说明如下：syntax: client_body_timeout time; #参数语法default: client_body_timeout 60s; #默认60context: http,server,location #可以放置的标签段
参数作用：
设置读取客户端请求主体的超时时间。这个超时仅仅为两次成功的读取操作之间的一个超时，非请求整个主体数据的超时时间，如果在这个超时时间内，客户端没有发送任何数据，Nginx将返回“Request time out(408)”错误，默认值60，细节见:
（5）设置参数：send_timeout 25;
用于指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间，如果超过这个时间，客户端没有任何活动，Nginx将会关闭连接，默认值为60秒，可以改为参考值25秒。
#send_timeout参数的官方说明如下：syntax: send_timeout time; #参数语法default: send_timeout 60s; #默认值60context: http,server,location #可以放置的标签段
参数作用：
