1、nginx特性以及功能
2、nginx的架构及工作过程
3、nginx作为web服务器的配置
一、nginx特性以及功能
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler（俄文：Рамблер）使用。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。
nginx特性：
基本功能：
静态资源的web服务器，能缓存打开的文件描述符；
反向代理服务器，缓存、负载均衡；
支持FastCGI
模块化，非DSO机制，过滤器gzip，SSI和图像大小调整等
支持SSL
扩展功能：
基于名称和IP做虚拟主机
支持keepalive
支持平滑配置更新或程序版本升级
定制访问日志，支持使用日志缓存以提高性能
支持url rewrite
支持路径别名
支持基于IP及用户的认证；
支持速率限制，并发限制等；
二、nginx的架构及工作过程（nginx为什么能轻量高效工作）
1、nginx的工作模型
nginx的基本架构：
一个master, 生成一个或多个worker
事件驱动：kqueue, epoll, /dev/poll
消息通知：select, poll, rt signals
支持sendfile, sendfile64
文件AIO
支持mmap
nginx是一个非阻塞、事件驱动、一个master多个worker，一个worker响应多个用户请求的模型
2、nginx的进程处理过程
nginx在启动后，在unix系统中会以daemon的方式在后台运行，后台进程包含一个master进程和多个worker进程。
master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。
worker进程则是处理基本的网络事件。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。
worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致。更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，具有cpu绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效。
3、nginx如何避免惊群效应
惊群现象：
每个worker进程都是从master进程fork过来。在master进程里面，先建立好需要listen的socket之后，然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。一般来说，当一个连接进来后，所有在accept在这个socket上面的进程，都会收到通知，而只有一个进程可以accept这个连接，其它的则accept失败。
nginx如何避免惊群效应：
nginx提供了accept_mutex，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显式地关掉，默认是打开的。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
那么，nginx采用这种进程模型有什么好处呢？当然，好处肯定会很多了。首先，对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查找时，也会方便很多。其次，采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。
因此启动work的个数应该小于或等于CPU的个数，避免引起资源的竞争。
4、nginx的异步非阻塞工作机制
传统的基于进程和线程的模型在处理并发连接的时候针对每个连接会调用一个独立的进程或线程，并且阻塞在网络或I/O操作上面。根据应用程序的不同，它们对内存和CPU的使用效率非常低。产生一个新的进程或线程需要一个新的运行时环境，包括堆和栈的分配，以及运行时的上下文。因此需要额外的CPU开销来创建这些环境，过多的线程以及上下文切换最终会导致性能的下降。所有这些状况在Apache上都可以见到。
Nginx从一开始就旨在成为一个专门的工具来提高服务器的性能，密度和以及资源利用率，同时保证网站的动态增长，因此Nginx采取了不同的模型。它的设计灵感来自于各种各样的操作系统中不断发展的基于事件的机制。因此，模块化，事件驱动，异步，单线程，非阻塞的架构成为了nginx的基石。
Nginx大量使用多路复用和事件通知，并将特定任务分配到独立的进程。Nginx通过一个高效率的、数量有限的单线程进程的运行环(worker)来处理连接。正是在内部有这些worker，Nginx才能处理每秒成千上万的并发连接。
nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。想想apache的常用工作方式（apache也有异步非阻塞版本，但因其与自带某些模块冲突，所以不常用），每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。
为什么nginx可以采用异步非阻塞的方式来处理呢，或者异步非阻塞到底是怎么回事呢？我们先回到原点，看看一个请求的完整过程。首先，请求过来，要建立连接，然后再接收数据，接收数据后，再发送数据。具体到系统底层，就是读写事件，而当读写事件没有准备好时，必然不可操作，如果不用非阻塞的方式来调用，那就得阻塞调用了，事件没有准备好，那就只能等了，等事件准备好了，你再继续吧。阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了。
好吧，你说加进程数，这跟apache的线程模型有什么区别，注意，别增加无谓的上下文切换 ？所以，在nginx里面，最忌讳阻塞的系统调用了。不要阻塞，那就非阻塞喽。非阻塞就是，事件没有准备好，马上返回EAGAIN，告诉你，事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的。所以，才会有了异步非阻塞的事件处理机制，具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。
它们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制正好解决了我们上面的两个问题，拿epoll为例(在后面的例子中，我们多以epoll为例子，以代表这一类函数)，当事件没准备好时，放到epoll里面，事件准备好了，我们就去读写，当读写返回EAGAIN时，我们将它再次加入到epoll里面。这样，只要有事件准备好了，我们就去处理它，只有当所有事件都没准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，
只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已。 我之前有对连接数进行过测试，在24G内存的机器上，处理的并发请求数达到过200万。现在的网络服务器基本都采用这种方式，这也是nginx性能高效的主要原因。
三、nginx作为web服务器的配置
1、nginx的安装
默认base源中并没有nginx的安装文件，epel源才有，可以使用官方提供的预编译的rpm直接安装，也可以编译安装
nginx的安装配置：
官方的预制包：
http://nginx.org/packages/centos/7/x86_64/RPMS/
编译安装：
# yum install pcre-devel openssl-devel zlib-devel
# useradd -r nginx
# ./configure --prefix=/usr/local/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_dav_module --with-http_stub_status_module --with-threads --with-file-aio
# make && make install
2、nginx的配置
配置文件的组成部分：
主配置文件：nginx.conf
include conf.d/*.conf
fastcgi， uwsgi，scgi等协议相关的配置文件
mime.types：支持的mime类型
注意：
(1) 指令必须以分号结尾；
(2) 支持使用配置变量；
内建变量：由Nginx模块引入，可直接引用；
自定义变量：由用户使用set命令定义；
set variable_name value;
引用变量：$variable_name
主配置文件结构：
main block：主配置段，也即全局配置段；
event {
...
}：事件驱动相关的配置；
http {
...
}：http/https 协议相关的配置段；
[root@localhost ~]# grep -v "^[[:space:]]*#" /etc/nginx/nginx.conf |grep -v ‘^$‘
worker_processes 1; #main段
events {#event段
worker_connections 1024;
}
http { #http段
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
} 下面来对配置按照已得的功能来进行分类归纳：
nginx的配置（main）：
正常运行的配置： 1、user username [groupname]; 指定运行worker进程的用户和组 2、pid /path/to/pidfile_name; 指定nginx的pid文件 3、worker_rlimit_nofile #; 指定一个worker进程所能够打开的最大文件句柄数； 4、worker_rlimit_sigpending #; 设定每个用户能够发往worker进程的信号的数量； 优化性能相关的配置： 1、worker_processes #; worker进程的个数；通常其数值应该为CPU的物理核心数减1； 2、worker_cpu_affinity cpumask ...; 0000 0001 0010 0100 1000 0011：表示第一和第二颗 worker_processes 6; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000; 3、ssl_engine device; 在存在ssl硬件加速器的服务器上，指定所使用的ssl硬件加速设备； 4、timer_resolution t; 每次内核事件调用返回时，都会使用gettimeofday()来更新nginx缓存时钟；timer_resolution用于定义每隔多久才会由gettimeofday()更新一次缓存时钟；x86-64系统上，gettimeofday()代价已经很小，可以忽略此配置； 5、worker_priority nice; -20,19之间的值；
事件相关的配置
1、accept_mutex [on|off] 是否打开Ningx的负载均衡锁；此锁能够让多个worker进轮流地、序列化地与新的客户端建立连接；而通常当一个worker进程的负载达到其上限的7/8，master就尽可能不再将请求调度此worker； 2、lock_file /path/to/lock_file; lock文件 3、accept_mutex_delay #ms; accept锁模式中，一个worker进程为取得accept锁的等待时长；如果某worker进程在某次试图取得锁时失败了，至少要等待#ms才能再一次请求锁； 4、multi_accept on|off; 是否允许一次性地响应多个用户请求；默认为Off; 5、use [epoll|rtsig|select|poll]; 定义使用的事件模型，建议让nginx自动选择； 6、worker_connections #; 每个worker能够并发响应最大请求数；
用于调试、定位问题: 只调试nginx时使用
1、daemon on|off; 是否让ningx运行后台；默认为on，调试时可以设置为off，使得所有信息去接输出控制台； 2、master_process on|off 是否以master/worker模式运行nginx；默认为on；调试时可设置off以方便追踪； 3、error_log /path/to/error_log level; 错误日志文件及其级别；默认为error级别；调试时可以使用debug级别，但要求在编译时必须使用--with-debug启用debug功能；
nginx的http web功能：
必须使用虚拟机来配置站点；每个虚拟主机使用一个server {}段配置；
server {
}
非虚拟主机的配置或公共配置，需要定义在server之外，http之内；
http {
directive value;
...
server {
}
server {
}
...
}虚拟主机相关的配置：
1、server {}
定义一个虚拟主机；nginx支持使用基于主机名或IP的虚拟主机；
2、listen
listen address[:port];
listen port
default_server：定义此server为http中默认的server；如果所有的server中没有任何一个listen使用此参数，那么第一个server即为默认server;
rcvbuf=SIZE: 接收缓冲大小；
sndbuf=SIZE: 发送缓冲大小；
ssl: https server；
3、server_name [...];
server_name可以跟多个主机名，名称中可以使用通配符和正则表达式(通常以~开头)；当nginx收到一个请求时，会取出其首部的server的值，而后跟众server_name进行比较；
比较优先次序方式：
(1) 先做精确匹配；www.magedu.com
(2) 左侧通配符匹配；*.magedu.com
(3) 右侧通配符匹配；www.abc.com, www.*
(4) 正则表达式匹配: ~^.*\.magedu\.com$
4、server_name_hash_bucket_size 32|64|128;
为了实现快速主机查找，nginx使用hash表来保存主机名；
5、(1)location [ = | ~ | ~* | ^~ ] uri { ... }
(2)location @name { ... }
功能：允许根据用户请求的URI来匹配指定的各location以进行访问配置；匹配到时，将被location块中的配置所处理
=：精确匹配；
~：正则表达式模式匹配，匹配时区分字符大小写
~*：正则表达式模式匹配，匹配时忽略字符大小写
^~: URI前半部分匹配，匹配时忽略字符大小写。不检查正则表达式
匹配优先级：
= (大于) ^~ (大于) ~ (大于) 不带符号
location / :表示以/开头的URL都可以匹配文件路径定义：
1、root path
设置web资源路径；用于指定请求的根文档目录；
location / {
root /www/htdocs;（本机的文件路径）
}
location ^~ /images/ {
root /web;
}
root: root/URI/
2、alias path
只能用于location中，用于路径别名；
location / {
root /www/htdocs;
}
location ^~ /images/ {
alias /web;
}
3、index file ...;
定义默认页面，可参跟多个值；
4、error_page code ... [=[response]] uri;
错误页重定向：当对于某个请求返回错误时，如果匹配上了error_page指令中设定的code，则重定向到新的URI中。
错误页面重定向；
例：error_page 404 /404.html;当用户请求一个不存在的资源是，会自动跳转到自定义的404.html页面。
注意跳转的状态码还是原来的状态码，即使是跳转成功！
5、try_files path1 [path2 ...] uri;
自左至右尝试读取由path所指定路径，在第一次找到即停止并返回；如果所有path均不存在，则返回最后一个uri;
location ~* ^/documents/(.*)$ {
root /www/htdocs;
try_files $uri /docu/$1 /temp.html;
}
网络连接相关的设置：
1、keepalive_timeout time; 保持连接的超时时长；默认为75秒,0表示禁止长连接； 2、keepalive_requests n; 在一次长连接上允许承载的最大请求数； 3、keepalive_disable [msie6 | safari | none ] 对指定的浏览器禁止使用长连接； 4、tcp_nodelay on|off 对keepalive连接是否使用TCP_NODELAY选项；启用该选项表示即使请求的数据很小也会发送，不用等凑数才发送。 5、client_header_timeout time; 读取http请求首部的超时时长； 6、client_body_timeout time; 读取http请求包体的超时时长； 7、send_timeout time; 发送响应报文的超时时长；
对客户端请求的限制：
1、limit_except method ... { ... }
指定对范围之外的其它方法的访问控制；
limit_except GET {
allow 172.16.0.0/16;
deny all;
}
2、client_max_body_size SIZE;
http请求包体的最大值；常用于限定客户所能够请求的最大包体；根据请求首部中的Content-Length来检测，以避免无用的传输；
3、limit_rate speed;
限制客户端每秒钟传输的字节数；默认为0，表示没有限制；
4、limit_rate_after time;
nginx向客户发送响应报文时，如果时长超出了此处指定的时长，则后续的发送过程开始限速；
5、用户认证示例
location /admin/ {
root /www/b.org;
auth_basic "admin area";
auth_basic_user_file /etc/nginx/.htpasswd;
}文件操作的优化：
1、sendfile on|off 是否启用sendfile功能； 2、aio on|off 是否启用aio功能； 3、open_file_cache max=N [inactive=time]|off 是否打开文件缓存功能； max: 缓存条目的最大值；当满了以后将根据LRU算法进行置换； inactive: 某缓存条目在指定时长时没有被访问过时，将自动被删除；默认为60s; 缓存的信息包括： 文件句柄、文件大小和上次修改时间； 已经打开的目录结构； 没有找到或没有访问权限的信息； 4、open_file_cache_errors on|off 是否缓存文件找不到或没有权限访问等相关信息； 5、open_file_cache_valid time; 多长时间检查一次缓存中的条目是否超出非活动时长，默认为60s; 6、open_file_cache_min_use #; 在inactive指定的时长内被访问超此处指定的次数地，才不会被删除；
对客户端请求的特殊处理：
1、ignore_invalid_headers on|off 是否忽略不合法的http首部；默认为on; off意味着请求首部中出现不合规的首部将拒绝响应；只能用于server和http; 2、log_not_found on|off 是否将文件找不到的信息也记录进错误日志中； 3、resolver address; 指定nginx使用的dns服务器地址； 4、resover_timeout time; 指定DNS解析超时时长，默认为30s; 5、server_tokens on|off; 是否在错误页面中显示nginx的版本号；
内存及磁盘资源分配：
1、client_body_in_file_only on|clean|off HTTP的包体是否存储在磁盘文件中；非off表示存储，即使包体大小为0也会创建一个磁盘文件；on表示请求结束后包体文件不会被删除，clean表示会被删除； 2、client_body_in_single_buffer on|off; HTTP的包体是否存储在内存buffer当中；默认为off； 3、cleint_body_buffer_size size; nginx接收HTTP包体的内存缓冲区大小(默认是16K)； 4、client_body_temp_path dir-path [level1 [level2 [level3]]]; HTTP包体存放的临时目录(如果body_buffer缓冲区已满时生效)； 例：client_body_temp_path /var/tmp/client/ 1 2 2 表示16*256*256的小区域来进行存储缓存的文件 5、client_header_buffer_size size; 正常情况下接收用户请求的http报文header部分时分配的buffer大小；默认为1k; 6、large_client_header_buffers number size; 存储超大Http请求首部的内存buffer大小及个数； 7、connection_pool_size size; nginx对于每个建立成功的tcp连接都会预先分配一个内存池，此处即用于设定此内存池的初始大小；默认为256； 8、request_pool_size size; nginx在处理每个http请求时会预先分配一个内存池，此处即用于设定此内存池的初始大小；默认为4k;
日志模块
1、log_format name string ...; string可以使用nginx核心模块及其它模块内嵌的变量； 2、access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]]; access_log off; 访问日志文件路径，格式及相关的缓冲的配置； buffer=size flush=time 3、open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time]; open_log_file_cache off; 缓存各日志文件相关的元数据信息； max：缓存的最大文件描述符数量； min_users：在inactive指定的时长内访问大于等于此值方可被当作活动项； inactive：非活动时长； valid：验正缓存中各缓存项是否为活动项的时间间隔；
URL重写和防盗链
1、防盗链
(1) 定义合规的引用
valid_referers none | blocked | server_names | string ...;
(2) 拒绝不合规的引用
if ($invalid_referer) {
rewrite ^/.*$ http://www.b.org/403.html
}
2、URL rewrite
rewrite regex replacement [flag];
eg.
location / {
root /www/b.org;
rewrite ^/images/(.*)$ /imgs/$1 last;
rewirte ^/imgs/(.*)$ /images/$1;
}
http://www.b.org/images/a.jpg --> http://www.b.org/imgs/a.jpg
last: 一旦被当前规则匹配并重写后立即停止检查后续的其它rewrite的规则，而后通过重写后的规则重新发起请求；
break: 一旦被当前规则匹配并重写后立即停止后续的其它rewrite的规则，而后继续由nginx进行后续操作；
redirect: 返回302临时重定向；
permanent: 返回301永久重定向；
location /download/ {
rewrite ^(/download/.*)/media/(.*)\..*$ $1/media/$2.mp3 break;
}
nginx最多循环10次，超出之后会返回500错误；
注意：一般将rewrite写在location中时都使用break标志，或者将rewrite写在if上下文中；
rewrite_log on|off
是否把重写过程记录在错误日志中；默认为notice级别；默认为off；
return code:
用于结束rewrite规则，并且为客户返回状态码；可以使用的状态码有204, 400, 402-406, 500-504等；
文件压缩：
1、gzip on | off; 是否开启压缩功能，只有ON时，下面的选项才起效果，一般的生产环境都是启动压缩 2、gzip_comp_level level; 文件的压缩等级 3、gzip_disable regex ...; 定义来自某类浏览器的文件不进行压缩 4、gzip_min_length length; 启用压缩功能的响应报文大小阈值； 5、gzip_buffers number size; 支持实现压缩功能时为其配置的缓冲区数量及每个缓存区的大小； 6、gzip_proxied off | expired | no-cache | no-store | private | no_last_mo dified | no_etag | auth | any ...; nginx作为代理服务器接收到从被代理服务器发送的响应报文后，在何种条件下启用压缩功能的； off：对代理的请求不启用 no-cache, no-store，private：表示从被代理服务器收到的响应报文首部的Cache-Control的值为此三者中任何一个，则启用压缩功能； 7、gzip_types mime-type ...; 压缩过滤器，仅对此处设定的MIME类型的内容启用压缩功能；
fcgi相关：
1、fastcgi_pass address;
address为fastcgi server的地址；location, if in location；
2、fastcgi_index name;
fastcgi默认的主页资源;
3、fastcgi_param parameter value [if_not_empty];
Sets a parameter that should be passed to the FastCGI server. The value can contain text, variables, and their combination.
配置示例1：
前提：配置好fpm server和mariadb-server服务；
location ~* \.php$ {
root /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name; #注意script_filename的目录位置
include fastcgi_params;
}
配置示例2：通过/pm_status和/ping来获取fpm server状态信息；
location ~* ^/(pm_status|ping)$ {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
}
4、fastcgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=ti
定义fastcgi的缓存；缓存位置为磁盘上的文件系统，由path所指定路径来定义；
levels=levels：缓存目录的层级数量，以及每一级的目录数量；levels=ONE:TWO:THREE
leves=1:2:2
keys_zone=name:size
k/v映射的内存空间的名称及大小
inactive=time
非活动时长
max_size=size
磁盘上用于缓存数据的缓存空间上限
5、fastcgi_cache zone | off;
调用指定的缓存空间来缓存数据；http, server, location
6、fastcgi_cache_key string;
定义用作缓存项的key的字符串；
7、fastcgi_cache_methods GET | HEAD | POST ...;
为哪些请求方法使用缓存；
8、fastcgi_cache_min_uses number;
缓存空间中的缓存项在inactive定义的非活动时间内至少要被访问到此处所指定的次数方可被认作活动项；
9、fastcgi_cache_valid [code ...] time;
不同的响应码各自的缓存时长；
示例：
http {
...
fastcgi_cache_path /var/cache/nginx/fastcgi_cache levels=1:2:1 keys_zone=fcgi:20m inactive=120s;
...
server {
...
location ~* \.php$ {
...
fastcgi_cache fcgi;
fastcgi_cache_key $request_uri;
fastcgi_cache_valid 200 302 10m;
fastcgi_cache_valid 301 1h;
fastcgi_cache_valid any 1m;
...
}
...
}
...
}ssl相关的设置
1、ssl on | off;
Enables the HTTPS protocol for the given virtual server.
2、ssl_certificate file;
当前虚拟主机使用PEM格式的证书文件；
3、ssl_certificate_key file;
当前虚拟主机上与其证书匹配的私钥文件；
4、ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
支持ssl协议版本，默认为后三个；
5、ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
builtin[:size]：使用OpenSSL内建的缓存，此缓存为每worker进程私有；
[shared:name:size]：在各worker之间使用一个共享的缓存；
6、ssl_session_timeout time;
客户端一侧的连接可以复用ssl session cache中缓存 的ssl参数的有效时长；
配置示例：
server {
listen 443 ssl;
server_name www.domain.com;
root /vhosts/ssl/htdocs;
ssl on;
ssl_certificate /etc/nginx/ssl/nginx.crt; #导入的证书位置
ssl_certificate_key /etc/nginx/ssl/nginx.key; #私钥位置
ssl_session_cache shared:sslcache:20m;
}所有的配置和实例官方网站都有说明，可以直接参考：http://nginx.org/en/docs/
了解nginx的基本配置后，接下来可以进行nginx的实验测试。
本文出自 “6638225” 博客，转载请与作者联系！
原文地址：http://6638225.blog.51cto.com/6628225/1865175
