初探nginx架构以及配置

时间 2020-02-18

标签初探 nginx 架构以及配置栏目 Nginx 繁體版

原文原文链接

一、nginx特性以及功能php

二、nginx的架构及工做过程html

三、nginx做为web服务器的配置node

1、nginx特性以及功能nginx

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler（俄文：Рамблер）使用。其特色是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。web

nginx特性：正则表达式

基本功能：算法

静态资源的web服务器，能缓存打开的文件描述符；apache

反向代理服务器，缓存、负载均衡；编程

支持FastCGIc#

模块化，非DSO机制，过滤器gzip，SSI和图像大小调整等

支持SSL

扩展功能：

基于名称和IP作虚拟主机

支持keepalive

支持平滑配置更新或程序版本升级

定制访问日志，支持使用日志缓存以提升性能

支持url rewrite

支持路径别名

支持基于IP及用户的认证；

支持速率限制，并发限制等；

2、nginx的架构及工做过程（nginx为何能轻量高效工做）

一、nginx的工做模型

nginx的基本架构：

一个master, 生成一个或多个worker

事件驱动：kqueue, epoll, /dev/poll

消息通知：select, poll, rt signals

支持sendfile, sendfile64

文件AIO

支持mmap

nginx是一个非阻塞、事件驱动、一个master多个worker，一个worker响应多个用户请求的模型

二、nginx的进程处理过程

nginx在启动后，在unix系统中会以daemon的方式在后台运行，后台进程包含一个master进程和多个worker进程。

master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常状况下)，会自动从新启动新的worker进程。

　　worker进程则是处理基本的网络事件。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。

　　worker进程的个数是能够设置的，通常咱们会设置与机器cpu核数一致。更多的worker数，只会致使进程来竞争cpu资源了，从而带来没必要要的上下文切换。并且，nginx为了更好的利用多核特性，具备cpu绑定选项，咱们能够将某一个进程绑定在某一个核上，这样就不会由于进程的切换带来cache的失效。

三、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的个数，避免引发资源的竞争。

四、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性能高效的主要缘由。

更多文章请关注个人博客

3、nginx做为web服务器的配置

一、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

二、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）：

正常运行的配置：
一、user username [groupname];
    指定运行worker进程的用户和组
二、pid /path/to/pidfile_name;
    指定nginx的pid文件
三、worker_rlimit_nofile #;
    指定一个worker进程所可以打开的最大文件句柄数；
四、worker_rlimit_sigpending #;
    设定每一个用户可以发往worker进程的信号的数量；
优化性能相关的配置：
一、worker_processes #;
    worker进程的个数；一般其数值应该为CPU的物理核心数减1；
二、worker_cpu_affinity cpumask ...;
0000
0001
0010
0100
1000
0011：表示第一和第二颗 
worker_processes 6; 
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000; 
三、ssl_engine device;
    在存在ssl硬件加速器的服务器上，指定所使用的ssl硬件加速设备；
四、timer_resolution t;
    每次内核事件调用返回时，都会使用gettimeofday()来更新nginx缓存时钟；timer_resolution用于定义每隔多久才会由gettimeofday()更新一次缓存时钟；x86-64系统上，gettimeofday()代价已经很小，能够忽略此配置；
五、worker_priority nice;
    -20,19之间的值；

事件相关的配置

一、accept_mutex [on|off]
    是否打开Ningx的负载均衡锁；此锁可以让多个worker进轮流地、序列化地与新的客户端创建链接；而一般当一个worker进程的负载达到其上限的7/8，master就尽量再也不将请求调度此worker；
二、lock_file /path/to/lock_file; 
    lock文件
三、accept_mutex_delay #ms;
    accept锁模式中，一个worker进程为取得accept锁的等待时长；若是某worker进程在某次试图取得锁时失败了，至少要等待#ms才能再一次请求锁；
四、multi_accept on|off;
    是否容许一次性地响应多个用户请求；默认为Off; 
五、use [epoll|rtsig|select|poll];
    定义使用的事件模型，建议让nginx自动选择；
六、worker_connections #;
    每一个worker可以并发响应最大请求数；

用于调试、定位问题: 只调试nginx时使用

一、daemon on|off;
    是否让ningx运行后台；默认为on，调试时能够设置为off，使得全部信息去接输出控制台；
二、master_process on|off
    是否以master/worker模式运行nginx；默认为on；调试时可设置off以方便追踪；
三、error_log /path/to/error_log level;
    错误日志文件及其级别；默认为error级别；调试时可使用debug级别，但要求在编译时必须使用--with-debug启用debug功能；

nginx的http web功能：

必须使用虚拟机来配置站点；每一个虚拟主机使用一个server {}段配置；
server {
}
    非虚拟主机的配置或公共配置，须要定义在server以外，http以内；
http {
directive value;
...
    server {
    }
    server {
    }
...
}

虚拟主机相关的配置：

一、server {}
    定义一个虚拟主机；nginx支持使用基于主机名或IP的虚拟主机；
二、listen 
    listen address[:port];
    listen port 
    default_server：定义此server为http中默认的server；若是全部的server中没有任何一个listen使用此参数，那么第一个server即为默认server; 
    rcvbuf=SIZE: 接收缓冲大小；
    sndbuf=SIZE: 发送缓冲大小；
    ssl: https server；
三、server_name [...];
    server_name能够跟多个主机名，名称中可使用通配符和正则表达式(一般以~开头)；当nginx收到一个请求时，会取出其首部的server的值，然后跟众server_name进行比较；
    比较优先次序方式：
    (1) 先作精确匹配；www.magedu.com 
    (2) 左侧通配符匹配；*.magedu.com
    (3) 右侧通配符匹配；www.abc.com, www.*
    (4) 正则表达式匹配: ~^.*\.magedu\.com$
四、server_name_hash_bucket_size 32|64|128;
    为了实现快速主机查找，nginx使用hash表来保存主机名；
五、(1)location [ = | ~ | ~* | ^~ ] uri { ... }
   (2)location @name { ... }
   功能：容许根据用户请求的URI来匹配指定的各location以进行访问配置；匹配到时，将被location块中的配置所处理
   =：精确匹配；
   ~：正则表达式模式匹配，匹配时区分字符大小写
   ~*：正则表达式模式匹配，匹配时忽略字符大小写
   ^~: URI前半部分匹配，匹配时忽略字符大小写。不检查正则表达式
   
匹配优先级：
     = (大于) ^~ (大于) ~ (大于) 不带符号
     
location / :表示以/开头的URL均可以匹配

文件路径定义：

一、root path
    设置web资源路径；用于指定请求的根文档目录；
location / {
root /www/htdocs;（本机的文件路径）
}
location ^~ /p_w_picpaths/ {
root /web;
}
root: root/URI/

二、alias path
    只能用于location中，用于路径别名；
location / {
root /www/htdocs;
}
location ^~ /p_w_picpaths/ {
    alias /web;
}

三、index file ...;
    定义默认页面，可参跟多个值；
    
四、error_page code ... [=[response]] uri;
    错误页重定向：当对于某个请求返回错误时，若是匹配上了error_page指令中设定的code，则重定向到新的URI中。
错误页面重定向；
    例：error_page   404  /404.html;当用户请求一个不存在的资源是，会自动跳转到自定义的404.html页面。
注意跳转的状态码仍是原来的状态码，即便是跳转成功！

五、try_files path1 [path2 ...] uri;
    自左至右尝试读取由path所指定路径，在第一次找到即中止并返回；若是全部path均不存在，则返回最后一个uri; 
       location ~* ^/documents/(.*)$ {
           root /www/htdocs;
           try_files $uri /docu/$1 /temp.html;
       }

网络链接相关的设置：

一、keepalive_timeout time;
    保持链接的超时时长；默认为75秒,0表示禁止长链接；
二、keepalive_requests n;
    在一次长链接上容许承载的最大请求数；
三、keepalive_disable [msie6 | safari | none ]
    对指定的浏览器禁止使用长链接；
四、tcp_nodelay on|off
    对keepalive链接是否使用TCP_NODELAY选项；启用该选项表示即便请求的数据很小也会发送，不用等凑数才发送。
五、client_header_timeout time; 
    读取http请求首部的超时时长；
六、client_body_timeout time;
    读取http请求包体的超时时长；
七、send_timeout time;
    发送响应报文的超时时长；

对客户端请求的限制：

一、limit_except method ... { ... }
    指定对范围以外的其它方法的访问控制；
limit_except GET {
    allow 172.16.0.0/16;
    deny all; 
}
二、client_max_body_size SIZE;
    http请求包体的最大值；经常使用于限定客户所可以请求的最大包体；根据请求首部中的Content-Length来检测，以免无用的传输；
三、limit_rate speed;
    限制客户端每秒钟传输的字节数；默认为0，表示没有限制；
四、limit_rate_after time;
    nginx向客户发送响应报文时，若是时长超出了此处指定的时长，则后续的发送过程开始限速；
五、用户认证示例
location /admin/ {
            root /www/b.org;
            auth_basic "admin area";
            auth_basic_user_file /etc/nginx/.htpasswd;
        }

文件操做的优化：

一、sendfile on|off
    是否启用sendfile功能；
二、aio on|off
    是否启用aio功能；
三、open_file_cache max=N [inactive=time]|off
    是否打开文件缓存功能；
    max: 缓存条目的最大值；当满了之后将根据LRU算法进行置换；
    inactive: 某缓存条目在指定时长时没有被访问过期，将自动被删除；默认为60s;
     
缓存的信息包括：
    文件句柄、文件大小和上次修改时间；
    已经打开的目录结构；
    没有找到或没有访问权限的信息；
四、open_file_cache_errors on|off
    是否缓存文件找不到或没有权限访问等相关信息；
五、open_file_cache_valid time;
    多长时间检查一次缓存中的条目是否超出非活动时长，默认为60s; 
六、open_file_cache_min_use #;
    在inactive指定的时长内被访问超此处指定的次数地，才不会被删除；

对客户端请求的特殊处理：

一、ignore_invalid_headers on|off
    是否忽略不合法的http首部；默认为on; off意味着请求首部中出现不合规的首部将拒绝响应；只能用于server和http; 
二、log_not_found on|off
    是否将文件找不到的信息也记录进错误日志中；
三、resolver address;
    指定nginx使用的dns服务器地址；
四、resover_timeout time;
    指定DNS解析超时时长，默认为30s; 
五、server_tokens on|off;
    是否在错误页面中显示nginx的版本号；

内存及磁盘资源分配：

一、client_body_in_file_only on|clean|off
    HTTP的包体是否存储在磁盘文件中；非off表示存储，即便包体大小为0也会建立一个磁盘文件；on表示请求结束后包体文件不会被删除，clean表示会被删除；
二、client_body_in_single_buffer on|off;
    HTTP的包体是否存储在内存buffer当中；默认为off；
三、cleint_body_buffer_size size;
    nginx接收HTTP包体的内存缓冲区大小(默认是16K)；
四、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的小区域来进行存储缓存的文件
五、client_header_buffer_size size;
    正常状况下接收用户请求的http报文header部分时分配的buffer大小；默认为1k;
六、large_client_header_buffers number size; 
    存储超大Http请求首部的内存buffer大小及个数；
七、connection_pool_size size;
    nginx对于每一个创建成功的tcp链接都会预先分配一个内存池，此处即用于设定此内存池的初始大小；默认为256；
八、request_pool_size size;
    nginx在处理每一个http请求时会预先分配一个内存池，此处即用于设定此内存池的初始大小；默认为4k;

日志模块

一、log_format name string ...;
    string可使用nginx核心模块及其它模块内嵌的变量；
二、access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
    access_log off;
    访问日志文件路径，格式及相关的缓冲的配置；
    buffer=size
    flush=time 
三、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) 定义合规的引用
    valid_referers none | blocked | server_names | string ...;
    (2) 拒毫不合规的引用
    if  ($invalid_referer) {
    rewrite ^/.*$ http://www.b.org/403.html 
    } 
    二、URL rewrite
    rewrite regex replacement [flag];
eg.
   location / {
   root /www/b.org;
   rewrite ^/p_w_picpaths/(.*)$ /imgs/$1 last; 
   rewirte ^/imgs/(.*)$ /p_w_picpaths/$1;
   }
   http://www.b.org/p_w_picpaths/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等；

文件压缩：

一、gzip on | off;
    是否开启压缩功能，只有ON时，下面的选项才起效果，通常的生产环境都是启动压缩
二、gzip_comp_level level;
    文件的压缩等级
三、gzip_disable regex ...;
    定义来自某类浏览器的文件不进行压缩
四、gzip_min_length length;
    启用压缩功能的响应报文大小阈值； 
五、gzip_buffers number size;
    支持实现压缩功能时为其配置的缓冲区数量及每一个缓存区的大小；
六、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的值为此三者中任何一个，则启用压缩功能；
七、gzip_types mime-type ...;
    压缩过滤器，仅对此处设定的MIME类型的内容启用压缩功能；

fcgi相关：

一、fastcgi_pass address;
    address为fastcgi server的地址；location, if in location；
二、fastcgi_index name;
    fastcgi默认的主页资源; 
三、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;
}

四、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
    磁盘上用于缓存数据的缓存空间上限
五、fastcgi_cache zone | off;
    调用指定的缓存空间来缓存数据；http, server, location
六、fastcgi_cache_key string;
    定义用做缓存项的key的字符串；
七、fastcgi_cache_methods GET | HEAD | POST ...;
    为哪些请求方法使用缓存；
八、fastcgi_cache_min_uses number;
    缓存空间中的缓存项在inactive定义的非活动时间内至少要被访问到此处所指定的次数方可被认做活动项；
九、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相关的设置

一、ssl on | off;
    Enables the HTTPS protocol for the given virtual server.
二、ssl_certificate file;
    当前虚拟主机使用PEM格式的证书文件；
三、ssl_certificate_key file;
    当前虚拟主机上与其证书匹配的私钥文件；
四、ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
    支持ssl协议版本，默认为后三个；
五、ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
builtin[:size]：使用OpenSSL内建的缓存，此缓存为每worker进程私有；
[shared:name:size]：在各worker之间使用一个共享的缓存；
六、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的实验测试。

OK，更多文章请关注个人博客。