Nginx架构及配置详解-拓冰建站

一、概述

Nginx采用C进行编写，是俄罗斯程序员开发的一款轻量级的可构建Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器的软件， Nginx服务器是一个高性能的HTTP和反向代理web服务器，同时也可提供了IMAP/POP3/SMTP服务。nginx常用作跑静态和做负载反向代理，动态php交给apache处理，因后者比较稳定，jsp交给tomcat、resin或jboss。nginx跑静态的能力非常强大，是目前web服务器里最强的。通过配置，可实现nginx和apache、tomcat、resin的动静分离，国内已使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

✿ 特性：

1>模块化设计，较好的扩展性
2>高可靠性
3>基于master/worker架构设计
4>支持热部署；可在线升级
5>不停机更新配置文件、更好日志文件、更新服务器查询版本
6>较低的内存消耗,1万个keep-alive连接模式下的非活动连接仅消耗2.5M内存
7>event-driven机制：支持aio，mmap（内存映射）
8>多平台支持：Nginx 可以在大多数 UnixLinux OS 上编译运行，并有 Windows 移植版,可在Windows上较好运行
9>并发能力强,在连接高并发的情况下，Nginx是Apache服务不错的替代品,能够支持高达 50,000 个并发连接数的响应。
10>支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能

关联资源：Nginx官方地址、Nginx源码包下载、Nginx中文文档网站、NginxWebUI、Nginxproxymanager

✿ Nginx应用场景：

1>静态资源的web服务器
2>作为http/pop3/imap4协议的反向代理服务器(主要使用)
3>动态与静态资源的分离的工作

✿ 反向代理：

对应正向代理，当你访问某一个网站时，并非直接访问目标网站，而是告诉代理服务器我需要访问什么目标网站，由代理服务器转发用户请求给目标网站，将目标网站访问结果再转发给你，此时，你是请求代理方。而反向代理是此时代理服务器做服务器的代理，我们的访问请求并非直接访问到目标服务器上，而是访问代理服务器，由代理服务器决定什么样的请求以什么样的方式访问正式服务器；

✿ 负载均衡：

目前大多数的网站都会采用负载均衡手段来针对目前用户的指数级增长来减少对单点服务器的负载压力，比如目前我们拥有3台真实服务器，我们需要根据相应策略决定什么样的用户请求分配到哪个真实服务器，比如按照轮询的方式，用户请求挨个到达代理服务器，此时代理服务器按照第一个请求转发至第一台真实服务器，第二个请求转发到第二个服务器上，依次类推，这样可以防止大量的用户请求全部访问到同一台物理机上，单点物理机的性能始终有限的，当然这可能对服务器数据访问时候造成事务性的失效，在Web方面可能造成Session访问的问题。

✿ 动态静态资源分离：

如Java的JSP和静态资源如：.js/.css/.html/.png方面的资源分离，之前开发web方面的程序时候我们习惯将html、css等资源文件也放置于Tomcat之中，用户访问后tomcat需要将请求的这些静态资源文件一并返回给用户，再者如果有多台同业务逻辑的tomcat服务器的话，同样的资源还需要在每个服务器上放一份，同时也增加了tomcat服务器的网络IO，十分不合算的，如果我们只将JSP之类的请求交给tomcat，而代理服务器上存放静态资源，当用户的请求非动态资源的时候，我们完全可以将代理服务器的静态资源直接返回给用户，而不去增大Tomcat的压力，tomcat只需要负责逻辑处理和动态资源的加载就可以了。

二、架构及原理

如图所示：一个master进程，可生成一个或多个worker进程，其中：

master：负责加载分析配置文件、管理worker进程、平滑升级、…
worker：处理并响应用户请求。

一个master有多个worker，每个worker可响应n个请求，每个worker有核心模块core和外围的诸多模块modules组成，为了实现http功能有http协议的ht_core模块，为了功能完善还有很多其它模块，如实现负载均衡的ht_upstream模块，ht_proxy反代模块，Fastcgi模块ht_fastcgi模块；

用到哪些功能编译哪些模块或载入哪些模块即可；基于每种模块，可以与后端的不同应用通信；例如基于ht_core模块可与web ；基于server通信，基于ht_fastcgi模块可与php通信；基于memcache模块可与mamcache通信；所以这是反代模型工作时的架构；

nginx是高度模块化的，nginx的woker进程中除了用于响应用户请求之外，还有实现管理的组件，如cache loader负责加载缓存、cache manager负责管理缓存，用到时可启用，否则可不启用；

基于在本地磁盘上与本地磁盘数据通信时，支持高级IO机制、sendfile机制、AIO机制、mmap机制等；

实现并发用户请求响应时，可基于kevent、epoll、select；

mmap内存映射，如何文件要想被访问，都要先从磁盘载入（布置到）内存才能被访问；而内存映射指的是，在内存空间中找一段空间，并没有把数据复制过来，是可以直接通过这段内存加载数据，在有些场景中，为了避免打开文件复制内存中这个复制过程，直接把文件映射一下，能够完成某个文件被访问到；

nginx源码的目录结构：

nginx的configure原理(100%)
nginx的编译旅程将从configure开始，configure脚本将根据我们输入的选项、系统环境参与来生成所需的文件（包含源文件与Makefile文件）。configure会调用一系列auto脚本来实现编译环境的初始化。

auto脚本:
auto脚本由一系列脚本组成，他们有一些是实现一些通用功能由其它脚本来调用（如have），有一些则是完成一些特定的功能（如option）。

正向代理：

反向代理：

**负载均衡:**负载均衡策略有2种：内置策略和扩展策略。其中内置策略为轮询，加权轮询，Ip hash。

上图中，Ip hash算法，对客户端请求的ip进行hash操作，然后根据hash结果将同一个客户端ip的请求分发给同一台服务器进行处理，可以解决session不共享的问题；

web缓存：
Nginx可以对不同的文件做不同的缓存处理，配置灵活，并且支持FastCGI_Cache，主要用于对FastCGI的动态程序进行缓存。配合着第三方的ngx_cache_purge，对制定的URL缓存内容可以的进行增删管理。

Nginx 的进程模型：

Nginx 服务器，正常运行过程中：
1>多进程：一个 Master 进程、多个 Worker 进程
2>Master 进程：管理 Worker 进程
3>对外接口：接收外部的操作(信号)
4>对内转发：根据外部的操作的不同，通过信号管理 Worker
5>监控：监控 worker 进程的运行状态，worker 进程异常终止后，自动重启 worker 进程
6>Worker 进程：所有 Worker 进程都是平等的
7>实际处理：网络请求，由 Worker 进程处理;
8>Worker 进程数量：在 nginx.conf 中配置，一般设置为核心数，充分利用 CPU 资源，同时，避免进程数量过多，避免进程竞争 CPU 资源，增加上下文切换的损耗。

1）HTTP 连接建立和请求处理过程：

Nginx 启动时，Master 进程，加载配置文件
Master 进程，初始化监听的 socket
Master 进程，fork 出多个 Worker 进程
Worker 进程，竞争新的连接，获胜方通过三次握手，建立 Socket 连接，并处理请求

2）Nginx 高性能、高并发：

Nginx 采用：多进程 + 异步非阻塞方式(IO 多路复用 epoll)
请求的完整过程：
建立连接
读取请求：解析请求
处理请求
响应请求
请求的完整过程，对应到底层，就是：读写 socket 事件

3）Nginx 的事件处理模型

request：Nginx 中 http 请求。

基本的 HTTP Web Server 工作模式：

接收请求：逐行读取请求行和请求头，判断段有请求体后，读取请求体
处理请求
返回响应：根据处理结果，生成相应的 HTTP 请求(响应行、响应头、响应体)
Nginx 也是这个套路，整体流程一致。

三、Nginx配置文件

1）配置文件的组成部分：
由一个主配置文件和其他一些辅助配置文件构成这些文件都是纯文本文件全部位于nginx安装目录的conf目录下只有主配置文件nginx.conf是在任何情况下都会被使用。

主配置文件：/etc/nginx/nginx.conf

fascfgi，scgi，uwscgi，mime.types的相关配置：

/etc/logrotate.d/nginx
/etc/nginx/conf.d/default.conf
/etc/nginx/conf.d/example_ssl.conf
/etc/nginx/fastcgi_params
/etc/nginx/koi-utf
/etc/nginx/koi-win
/etc/nginx/mime.types
/etc/nginx/scgi_params
/etc/nginx/uwsgi_params
/etc/nginx/win-utf
/etc/sysconfig/nginx
pid路径：/var/run/nginx.pid
lock路径：var/run/nginx.lock

主程序文件：/usr/sbin/nginx

指令上下文：nginx.conf中的配置信息根据逻辑上的意义，进行分类，分成了多个作用域(配置指令上下文)不同的作用域含有一个或者多个配置项nginx支持的几个指令上下文：

2）主配置文件：
vim /etc/nginx/nginx.conf，对于nginx.conf文件，其由多个块组成，最外面的块是main，main包含Events和HTTP，HTTP包含upstream和多个Server，Server又包含多个location。

各组成部分：main（全局设置）、server（主机设置）、upstream（负载均衡服务器设置/后台真实服务器配置）和 location（URL匹配特定位置的设置。即不同资源的位置）。

main块：设置的指令将影响其他所有设置；---->全局性
server块：其指令主要用于指定主机和端口；
upstream指令：主要用于负载均衡，设置一系列的后端服务器；
location块：用于匹配网页位置。

这四者之间的关系式：server继承main，location继承server，upstream既不会继承其他设置也不会被继承。
在这四个部分当中，每个部分都包含若干指令，这些指令主要包含Nginx的主模块指令、事件模块指令、HTTP核心模块指令，同时每个部分还可以使用其他HTTP模块指令，例如Http SSL模块、HttpGzip Static模块和Http Addition模块等。

Nginx.conf文件具体内容如下：

#定义Nginx运行的用户和用户组,系统中【必须有此用户】,可以是nologin user nginx nginx; ##user是个主模块指令，指定Nginx Worker进程运行用户以及用户组为nginx和nginx组，默认为nobody账号 #启用worker的进程数,通常设置成和cpu的数量相等；设置为auto时，启动worker的数量为当前主机的cpu核心数；worker_processes是个主模块指令，指定了Nginx要开启的进程数。每个Nginx进程平均耗费10M~12M内存 worker_processes 2; #全局错误日志及PID文件；error_log也是个主模块指令，用来定义全局错误日志文件。日志输出级别有debug、info、notice、warn、error、crit可供选择，其中，debug输出日志最为最详细，而crit输出日志最少。pid是个主模块指令，用来指定进程pid的存储文件位置。 error_log /var/log/nginx/error.log; #错误日志定义等级，[ debug | info | notice | warn | error | crit ] pid /var/run/nginx.pid; #一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（系统的值ulimit -n）与nginx进程数相除，但是nginx分配请求并不均匀，所以建议与ulimit -n的值保持一致。 worker_rlimit_nofile 65535; ##worker_rlimit_nofile用于绑定worker进程和CPU， Linux内核2.4以上可用。linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile相应一般填写65535。理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。 #events模块设定工作模式及连接数上限；即设定Nginx的工作模式及连接数上限： events { use epoll; ##epoll是多路复用IO(I/O Multiplexing)中的一种方式,但是仅用于linux2.6以上内核,可以大大提高nginx的性能；poll模型是Linux 2.6以上版本内核中的高性能网络I/O模型，linux建议epoll，如果跑在FreeBSD上面，就用kqueue模型。use是个事件模块指令，用来指定Nginx的工作模式。Nginx支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll。其中select和poll都是标准的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平台上，而kqueue用在BSD系统中。对于Linux系统，epoll工作模式是首选。 worker_connections 1024; ##单个后台worker process进程的最大并发链接数 （最大连接数=连接数*进程数），worker_connections也是个事件模块指令，用于定义Nginx每个进程的最大连接数，默认是1024。最大客户端连接数由worker_processes和worker_connections决定，即Max_client=worker_processes*worker_connections。在作为反向代理时，max_clients变为：max_clients = worker_processes * worker_connections/4。进程的最大连接数受Linux系统进程的最大打开文件数限制，在执行操作系统命令“ulimit -n 65536”后worker_connections的设置才能生效。 # multi_accept on; } #设定http服务器，利用它的反向代理功能提供负载均衡支持 http { #设定mime类型,类型由mime.type文件定义 include /etc/nginx/mime.types; ###include是个主模块指令，实现对配置文件所包含的文件的设定，可以减少主配置文件的复杂度。 default_type application/octet-stream; ###default_type属于HTTP核心模块指令，这里设定默认类型为二进制流，也就是当文件类型未定义时使用这种方式，例如在没有配置PHP环境时，Nginx是不予解析的，此时，用浏览器访问PHP文件就会出现下载窗口。 #设定日志格式 access_log /var/log/nginx/access.log; #sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用， #必须设为 on,如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，以平衡磁盘与网络I/O处理速度，降低系统的uptime. sendfile on; #tcp_nopush on; #连接超时时间 #keepalive_timeout 0; keepalive_timeout 65; tcp_nodelay on; #开启gzip压缩 gzip on; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; #设定请求缓冲 client_header_buffer_size 1k; #客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。可通过命令getconf PAGESIZE获取当前系统分页大小；也有client_header_buffer_size超过4k的情况，要求client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。 large_client_header_buffers 4 4k; open_file_cache max=65535 inactive=60s; #为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。 open_file_cache_valid 80s; #默认值为60，使用字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项目的有效信息 open_file_cache_min_uses 1; #使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如果使用更大的值,文件描述符在cache中总是打开状态. open_file_cache_errors on; #使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误. #包含其它配置文件，如自定义的虚拟主机 include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; #虚拟主机配置 server { #侦听80端口 listen 80; #定义使用www.xx.com访问，域名可以有多个，用空格隔开 server_name www.xx.com; #设定本虚拟主机的访问日志 access_log logs/www.xx.com.access.log main; access_log /usr/local/nginx/logs/host.access.404.log log404; # 解决server_name太长时报错could not build server_names_hash, you should increase server_names_hash_bucket_size: 32 server_names_hash_bucket_size 64; #上传文件大小限制 默认1M client_max_body_size 100m; #默认请求 location / { root /root; #定义服务器的默认网站根目录位置 index index.php index.html index.htm; #定义首页索引文件的名称 fastcgi_pass www.xx.com; fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name; include /etc/nginx/fastcgi_params; } # 定义错误提示页面 error_page 500 502 503 504 /50x.html; location = /50x.html { root /root; } #静态文件，nginx自己处理 location ~ ^/(images|javascript|js|css|flash|media|static)/ { root /var/www/virtual/htdocs; #过期30天，静态文件不怎么更新，过期可以设大一点，如果频繁更新，则可以设置得小一点。 expires 30d; } #PHP 脚本请求全部转发到 FastCGI处理. 使用FastCGI默认配置. location ~ \.php$ { root /root; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /home/www/www$fastcgi_script_name; include fastcgi_params; } #JS和CSS缓存时间设置 location ~ .*.(js|css)?$ { expires 1h; } #设定查看Nginx状态的地址 location /NginxStatus { stub_status on; access_log on; auth_basic "NginxStatus"; auth_basic_user_file conf/htpasswd; } # #本地动静分离反向代理配置，所有jsp的页面均交由tomcat或resin处理 location ~ .(jsp|jspx|do)?$ { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:10080; } #禁止访问 .htxxx 文件 location ~ /\.ht { deny all; } #日志格式设定 #$remote_addr与$http_x_forwarded_for用以记录客户端的ip地址； #$remote_user：用来记录客户端用户名称； #$time_local： 用来记录访问时间与时区； #$request： 用来记录请求的url与http协议； #$status： 用来记录请求状态；成功是200， #$body_bytes_sent ：记录发送给客户端文件主体内容大小； #$http_referer：用来记录从那个页面链接访问过来的； #$http_user_agent：记录客户浏览器的相关信息； #通常web服务器放在反向代理的后面，这样就不能获取到客户的IP地址了，通过$remote_add拿到的IP地址是反向代理服务器的iP地址。反向代理服务器在转发请求的http头信息中，可以增加x_forwarded_for信息，用以记录原有客户端的IP地址和原来客户端的请求的服务器地址。 log_format access '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" $http_x_forwarded_for'; } }

Nginx的负载均衡和代理配置

#设定http服务器，利用它的**反向代理功能**提供**负载均衡**支持 http { #设定mime类型,类型由mime.type文件定义 include /etc/nginx/mime.types; default_type application/octet-stream; #设定日志格式 access_log /var/log/nginx/access.log; #省略上文有的一些配置节点 #。。。。。。。。。。 #设定负载均衡的服务器列表 upstream mysvr { ##指定nginx后端真实服务器，基本就是tomcat服务器；指定堕胎 #weigth参数表示权值，权值越高被分配到的几率越大 server 192.168.8.1x:3128 weight=5;#本机上的Squid开启3128端口 server 192.168.8.2x:80 weight=1; server 192.168.8.3x:80 weight=6; } upstream mysvr2 { #weigth参数表示权值，权值越高被分配到的几率越大 server 192.168.8.x:80 weight=1; server 192.168.8.x:80 weight=6; } #第一个虚拟服务器 server { #侦听192.168.8.x的80端口 listen 80; server_name 192.168.8.x; #对aspx后缀的进行负载均衡请求 location ~ .*\.aspx$ { root /root; #定义服务器的默认网站根目录位置 index index.php index.html index.htm; #定义首页索引文件的名称 proxy_pass http://mysvr ; #请求转向mysvr 定义的服务器列表 #以下是一些反向代理的配置. proxy_redirect off; #后端的Web服务器可以通过X-Forwarded-For 获取用户真实IP proxy_set_header Host $host; ## proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; #允许客户端请求的最大单文件字节数， client_body_buffer_size 128k; #缓冲区代理缓冲用户端请求的最大字节数，注释该指令，会使用默认的client_body_buffer_size设置，也就是操作系统页面大小的两倍，8k或者16k，这时提交一个比较大，200k左右的图片，都返回500 Internal Server Error错误 proxy_intercept_errors on; #nginx阻止HTTP应答代码为400或者更高的应答 proxy_connect_timeout 90; #nginx跟后端服务器连接超时时间(代理连接超时)，发起握手等候响应超时时间 proxy_send_timeout 90; #后端服务器数据回传时间(代理发送超时)，就是在规定时间之内后端服务器必须传完所有的数据 proxy_read_timeout 90; #连接成功后，后端服务器响应时间(代理接收超时)，即等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间） proxy_buffer_size 4k; #设置代理服务器（nginx）保存用户头信息的缓冲区大小 proxy_buffers 4 32k; #proxy_buffers缓冲区，网页平均在32k以下的话，这样设置 proxy_busy_buffers_size 64k; #高负荷下缓冲大小（proxy_buffers*2） proxy_temp_file_write_size 64k; #设定缓存文件夹大小，大于这个值，将从upstream服务器传 } } }

负载均衡服务器配置示例2：

upstream mysvr{server192.168.10.130:8080;//之后分别在130和131上配置nginx服务器 server192.168.10.131:8080;ip_hash;}server{listen8080;server_name www.mysvr.com;location /{proxy_pass http://mysvr/;proxy_set_header Host$host;}upstream mysvr2{server192.168.253.131:8082;server192.168.253.130:8082;ip_hash;}server{listen8080;server_name www.mysvr2.com;location /{proxy_pass http://mysvr2/;proxy_set_header Host$host;}

Nginx.conf文件结构大致：

... #全局块 events { #events块 ... } http #http块 { ... #http全局块 server #server块 { ... #server全局块 location [PATTERN] #location块 { ... } location [PATTERN] { ... } } server { ... } ... #http全局块 }

1、全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。

2、events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。

3、http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。

4、server块：配置虚拟主机的相关参数，一个http中可以有多个server。

5、location块：配置请求的路由，以及各种页面的处理情况。

eg1：Nginx心跳检测示例：

upstream sms{server10.13.25.201:8080max_fails=2fail_timeout=30s;server10.13.25.201:8090max_fails=2fail_timeout=30s;}#在30s内（fail_timeout，默认值为10s），与服务端通讯失败2次（max_fails，默认值为1，设置为0则认为服务端一直可用），则认为服务器不可用；不可用服务器在30s内与服务端通讯成功2次，则认为服务器恢复；从而自动维护server的状态。server{listen80;server_name localhost;location /web{proxy_pass http://sms;}}

当upstream中的一台服务器响应失败时， Nginx会将请求转发给下一台服务器，直到所有的服务器都发送过该请求，如果此时依然无法获得成功的响应，客户端将收到最后一台服务器返回的响应结果。（参见）

四、Nginx.conf配置分区解析

1）Nginx的全局配置：

2）HTTP服务器配置:：

include是个主模块指令，实现对配置文件所包含的文件的设定，可以减少主配置文件的复杂度。类似于Apache中的include方法。
default_type属于HTTP核心模块指令，这里设定默认类型为二进制流，也就是当文件类型未定义时使用这种方式，例如在没有配置PHP环境时，Nginx是不予解析的，此时，用浏览器访问PHP文件就会出现下载窗口。

3）日志格式配置：

log_format是Nginx的HttpLog模块指令，用于指定Nginx日志的输出格式。main为此日志输出格式的名称
client_max_body_size用来设置允许客户端请求的最大的单个文件字节数；
client_header_buffer_size用于指定来自客户端请求头的headerbuffer大小。对于大多数请求，1K的缓冲区大小已经足够，如果自定义了消息头或有更大的Cookie，可以增加缓冲区大小。这里设置为32K；
large_client_header_buffers用来指定客户端请求中较大的消息头的缓存最大数量和大小， “4”为个数，“128K”为大小，最大缓存量为4个128K；
sendfile参数用于开启高效文件传输模式。将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞；
keepalive_timeout设置客户端连接保持活动的超时时间。在超过这个时间之后，服务器会关闭该连接；
client_header_timeout设置客户端请求头读取超时时间。如果超过这个时间，客户端还没有发送任何数据，Nginx将返回“Request time out（408）”错误；
client_body_timeout设置客户端请求主体读取超时时间。如果超过这个时间，客户端还没有发送任何数据，Nginx将返回“Request time out（408）”错误，默认值是60；
send_timeout指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间，如果超过这个时间，客户端没有任何活动，Nginx将会关闭连接。

#日志JSON格式化配置log_format json_analyticsescape=json'{''"msec": "$msec", '# request unixtime in seconds with a milliseconds resolution'"connection": "$connection", '# connection serial number'"connection_requests": "$connection_requests", '# number of requests made in connection'"pid": "$pid", '# process pid'"host": "$host", ''"remote_addr": "$remote_addr", '# client IP'"remote_user": "$remote_user", '# client HTTP username'"remote_port": "$remote_port", '# client port'"time_local": "$time_local", ''"time_iso8601": "$time_iso8601", '# local time in the ISO 8601 standard format'"request_method": "$request_method", '# request method'"request": "$request", '# full path no arguments if the request'"request_uri": "$request_uri", '# full path and arguments if the request'"request_id": "$request_id", '# the unique request id'"request_length": "$request_length", '# request length (including headers and body)'"request_time": $request_time, ''"args": "$args", '# args'"response_status": "$status", '# response status code'"body_bytes_sent": "$body_bytes_sent", '# the number of body bytes exclude headers sent to a client'"bytes_sent": "$bytes_sent", '# the number of bytes sent to a client'"http_version": "$server_protocol", ''"http_referer": "$http_referer", '# HTTP referer'"http_user_agent": "$http_user_agent", '# user agent'"http_x_forwarded_for": "$http_x_forwarded_for", '# http_x_forwarded_for'"http_x_forwarded_proto": "$http_x_forwarded_proto", ''"http_host": "$http_host", '# the request Host: header'"server_name": "$server_name", '# the name of the vhost serving the request'"request_time": "$request_time", '# request processing time in seconds with msec resolution'"upstream": "$upstream_addr", '# upstream backend server for proxied requests'"upstream_connect_time": "$upstream_connect_time", '# upstream handshake time incl. TLS'"upstream_header_time": "$upstream_header_time", '# time spent receiving upstream headers'"upstream_response_time": "$upstream_response_time", '# time spend receiving upstream body'"upstream_response_length": "$upstream_response_length", '# upstream response length'"upstream_cache_status": "$upstream_cache_status", '# cache HIT/MISS where applicable'"ssl_protocol": "$ssl_protocol", '# TLS protocol'"ssl_cipher": "$ssl_cipher", '# TLS cipher'"scheme": "$scheme", '# http or https'"server_protocol": "$server_protocol", '# request protocol, like HTTP/1.1 or HTTP/2.0'"pipe": "$pipe", '# "p" if request was pipelined, "." otherwise'"gzip_ratio": "$gzip_ratio", ''"http_cf_ray": "$http_cf_ray"''}';access_log /var/log/nginx/access.log json_analytics;

4）Http Gzip模块配置：

HttpGzip模块支持在线实时压缩输出数据流。
执行：nginx -V输出结果有：–with-http_gzip_static_module时，表编译时安装了gzip模块；就可在配置文件中配置该功能。
【配置项介绍】：
gzip用于设置开启或者关闭gzip模块，“gzip on”表示开启GZIP压缩，实时压缩输出数据流；
gzip_min_length设置允许压缩的页面最小字节数，页面字节数从header头的Content-Length中获取。默认值是0，不管页面多大都进行压缩。建议设置成大于1K的字节数，小于1K可能会越压越大；
gzip_buffers表示申请4个单位为16K的内存作为压缩结果流缓存，默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果；
gzip_http_version用于设置识别HTTP协议版本，默认是1.1，目前大部分浏览器已经支持GZIP解压，使用默认即可；
gzip_comp_level用来指定GZIP压缩比，1 压缩比最小，处理速度最快；9 压缩比最大，传输速度快，但处理最慢，也比较消耗cpu资源；
gzip_types用来指定压缩的类型，无论是否指定，“text/html”类型总是会被压缩的；
gzip_vary选项可以让前端的缓存服务器缓存经过GZIP压缩的页面，例如用Squid缓存经过Nginx压缩的数据。

5）负载均衡配置：

upstream是Nginx的HTTP Upstream模块，这个模块通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡。

在上图的设定中，通过upstream指令指定了一个负载均衡器的名称cszhi.com。这个名称可以任意指定，在后面需要的地方直接调用即可。

Nginx的负载均衡模块目前支持4种调度算法，其中后两项属于第三方的调度方法。

轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某台服务器宕机，故障系统被自动剔除，使用户访问不受影响；
Weight：指定轮询权值，Weight值越大，分配到的访问机率越高，主要用于后端每个服务器性能不均的情况下；
ip_hash：每个请求按访问IP的hash结果分配，这样来自同一个IP的访客固定访问一个后端服务器，有效解决了动态网页存在的session共享问题；
fair：比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持fair的，如果需要使用这种调度算法，必须下载Nginx的upstream_fair模块；
url_hash：按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率。Nginx本身是不支持url_hash的，如果需要使用这种调度算法，必须安装Nginx 的hash软件包。
在HTTP Upstream模块中，可以通过server指令**指定后端服务器的IP地址和端口**，同时还可以设定每个后端服务器在负载均衡调度中的状态。常用的状态有：

down：表示当前的server暂时不参与负载均衡；
backup：预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻；
max_fails：允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误；
fail_timeout：在经历了max_fails次失败后，暂停服务的时间。max_fails可以和fail_timeout一起使用。

注意，当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能是weight和backup。

示例：

#在http节点下，加入upstream节点 upstream linux{ server 10.0.0.77 weight=5; server 10.0.0.88 weight=10; } #指定轮询几率，weight和訪问比率成正比，用于后端服务器性能不均的情况 upstream favresin{ ip_hash; server 10.0.0.10:8080; server 10.0.0.11:8080; } #每一个请求按訪问ip的hash结果分配。这样每一个訪客固定訪问一个后端服务器，能够解决session的问题 upstream favresin{ server 10.0.0.10:8080; server 10.0.0.11:8080; fair; } #按后端服务器的响应时间来分配请求。响应时间短的优先分配 upstream resinserver{ server 10.0.0.10:7777; server 10.0.0.11:8888; hash $request_uri; hash_method crc32; } #按訪问url的hash结果来分配请求，使每一个url定向到同一个后端服务器。后端服务器为缓存时比較有效，在upstream中加入hash语句。server语句中不能写入weight等其他的參数，hash_method是使用的hash算法 upstream bakend{ #定义负载均衡设备的Ip及设备状态 ip_hash; ## server 10.0.0.11:9090 down; #单前的server临时不參与负载. server 10.0.0.11:8080 weight=2; server 10.0.0.11:6060; server 10.0.0.11:7070 backup; #其他全部的非backup机器down或者忙时，才请求backup机器，相当于热备 } ##将server节点下的location节点中的proxy_pass配置为：http:// + upstream名称， location / { root html; index index.html index.htm; proxy_pass http://linux; ##这里与upstream里的服务器名称一致 }

6）server虚拟主机配置

【参数说明】：

server：标志定义虚拟主机开始；
listen用于指定虚拟主机的服务端口
server_name用来指定IP地址或者域名，多个域名之间用空格分开。
index用于设定访问的默认首页地址；
root指令用于指定虚拟主机的网页根目录，这个目录可以是相对路径，也可以是绝对路径。
Charset用于设置网页的默认编码格式。
access_log用来指定此虚拟主机的访问日志存放路径，最后的main用于指定访问日志的输出格式。