Nginx学习总结概述(一)

    Nginx是目前比较主流的HTTP反向代理服务器(其企业版提供了基于TCP层的反向代理插件),对于构建大型分布式web应用,具有举足轻重的作用。简单来说,nginx有2个主要的功能:动/静态资源分离、负载均衡。

    动/静态资源分离:nginx支持正则表达式以区分静态资源或者动态资源,其中动态资源可以进一步转发给后端的proxy server,而静态资源则可以在nginx层面使用本地缓存策略或者重定向(类CDN)到其他nginx上。

    负载均衡:对于动态资源而言,如果有多个proxy server,那么nginx将会根据一定的算法选择合适的server,并转发请求,最终将客户端request相对均衡的分发给多个server。

    Nginx作为“单点”,面向客户端请求,并将请求转发给后端的某个server,因为server可以有多个,那么从整体而言,提升了站点的“资源整合”能力,提升了站点的整体吞吐能力;但因为受限于nginx本身的IO模型,并没有“降低”对物理资源的消耗(即性能开支);通常nginx作为整个站点的“避雷针”和导流通道,它应该被架设在物理资源较为优越的机器上,比如8U物理机,32核心,64G内存,对磁盘要求相对较低,对CPU、内存、网卡带宽有较高的要求,因为nginx不仅需要和客户端请求建立链接,而且还需要与后端proxy server建立链接并且负责流量输入、输出(这和LVS、Haproxy有本质区别),这种双倍的链接建立,就要求机器具有较高的内存和CPU,如果你的nginx还有大量的“静态资源”cache,还需要使用高速、高容量的磁盘。因为nginx节点最终为所有proxy server流量的总和,那么它应该具有更高的网卡带宽。

    为了避免资源竞争,应该避免nginx和web server部署在同一个节点上,因为web server通常为CPU和内存高耗型,这会大大降低nginx的代理能力。

    1) 在中小型应用中(PV在KW级别,单一垂直web应用),通常一个nginx代理多个(组)server即可。

    2)对于大中型应用,一个nginx将无法支撑全部的流量,我们将会采用多个nginx代理(复制了1)中的架构模型),并在nginx前端继续构建高性能的分流设备,比如LVS、Haproxy等更低层的软/硬件负载均衡器,这种负载均衡器通常只是“转发”,而不涉及到流量的输出,所以转发效率将会更高,承载能力更强。

    3)无论何时,我们也不希望nginx存在单点故障问题,那么通常我们还需要使用keepalived(其他同类型技术,VIP)来提高nginx节点的可用性,即Master-backup模式。

    4)当有多个nginx时,为了提升后端server的代理能力,通常还会让多个nginx之间交叉重叠代理后端的server。


Nginx学习总结概述(一)
 

一、常用模块

    在nginx 中,有几个常用的模块(module):

  • ngx_http_core_module:核心模块;内置模块。
  • ngx_http_upstream_module:“upstream”模块,内置模块,核心模块;用于请求的“负载均衡”。
  • ngx_http_proxy_module:“请求代理”模块,核心模块;将请求转发给代理Server,或者对请求进行额外的cache操作。
  • ngx_http_rewrite_module:“URL重写”模块,内置模块;根据规则,rewrite特定的URL并转发给代理Server。
  • ngx_http_access_module:“访问控制”模块;“允许”或者“拒绝”特定的IP列表对server的访问,内置模块。
  • ngx_http_limit_conn_module:“访问控制”模块;可以限定每个key(可以为客户端IP)允许的最大并发连接数,内置模块。
  • ngx_http_limit_req_module:“访问控制”模块;可以限定每个key(可以为客户端IP)在单位之间内允许处理的request个数,“流量控制”,内置模块。
  • ngx_http_headers_module:“header”模块;主要是“add_header”和“expired”两个指令,向response中添加header信息,内置模块。
  • ngx_http_charset_module:“字符集”模块;在响应头部的“Content-Type”中增加charset信息,内置模块。
  • ngx_http_addition_module:“增添”模块;在response内容之前或者之后额外添加文本信息,内置模块。
  • ngx_http_sub_module:“后置修改响应”模块;可以过滤并替换response内容中特定的字符串,附加模块,需要在编译时指定“--with-http_sub_module”。
  • ngx_http_fastcgi_module:将请求发送给“fastcgi”服务器,内置模块。
  • ngx_http_geo_module:“geo”模块;创建一个变量,此变量的值由client ip值决定,对实现小型私有“CDN”方案有参考价值,内置模块。
  • ngx_http_geoip_module:“geo”模块;通过配置(数据源)可以得知client ip所属的“城市”、“区域”等信息,对实现小型私有的CDN有一定的参考价值,附加模块,需要在编译时指定“--with-http_geoip_module”。
  • ngx_http_gzip_module:“gzip”模块;对response使用gzip压缩,对减少数据传输量有益,内置模块。
  • ngx_http_gzip_static_module:“gzip”模块;对response使用gzip压缩,输出为“.gz”文件,附加模块,需要在编译时指定“--with-http_gzip_static_module”。
  • ngx_http_image_filter_module:“图片”模块;可以对“JPEG”、“GIF”、“PNG”格式的图片进行裁剪等操作,附加模块,需要在编译时指定“--with-http_image_filter_module”。
  • ngx_http_status_module/ngx_http_stub_status_module:“nginx内部状态”模块;用于获取nginx内部的一些状态统计信息,通常用来获取一些简单的统计数据,其中nginx_http_stub_status_module为附加模块,编译时需要指定“--with-http_stub_status_module”。
  • nginx-http-concat:第三方附加模块,由taobao开发,主要用于合并“静态资源”请求,提升性能,需要额外下载,并在编译时添加“--add-module=/root/software/nginx-http-concat-master”。
  • ngx_cache_purge:第三方附件模块,由frickle提供,当在proxy中使用cache保存静态资源时,那么cache_purge模块提供删除过期数据的功能支持,需要额外下载,并在编译时添加“--add-module=/root/software/ngx_cache_purge”。

二、安装(mac下)

    接下来,我们就尝试安装nginx,从官网下载最新版1.8.0压缩包,并按照如下步骤一次安装,本人所使用的平台为mac OS(很遗憾,mac下安装这些软件,还是相当的费劲)。为了方便起见,我们将上述常用的module一次性全部安装或者加载(避免以后重新增加module带来的麻烦)。下文中所下载的软件都先保存到/usr/local/src下。

    1、下载ngx_cache_purge模块:http://labs.frickle.com/nginx_ngx_cache_purge/,解压后保存在本地目录。

    2、下载ngx-http-concat模块:https://github.com/alibaba/nginx-http-concat,解压后保存在本地目录。

    3、下载nginx并解压,保存在/usr/local/src,重命名为“nginx-1.8.0-src”。

    4、configure操作,通过--prefix指定nginx最终的可执行文件copy到哪个目录,这个目录不需要提前创建。

##进入nginx目录
./configure --prefix=/usr/local/nginx-1.8.0 --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --add-module=/usr/local/src/nginx-http-concat-master --add-module=/usr/local/src/ngx_cache_purge/

   极有可能你会得到一个错误“./configure: error: the HTTP rewrite module requires the PCRE library.”,这意味着如果需要安装rewrite模块,那么就需要安装PCRE包(perl正则表达式)。

##mac系统,linux下均可使用此编译安装的方式
##首先下载pcre包:http://www.pcre.org/,解压
##进入解压包
sudo ./configure --prefix=/usr/local
sudo make
sudo make install

    然后你还会得到一个错误“./configure: error: the HTTP image filter module requires the GD library.”,GD包主要用于图形处理,这个需要手动安装。安装GD之前,需要依次安装libpng、libjpeg,freetype,zlib(mac下不需要安装,默认已经有了)。

##libpng,在sourceforge.net上搜索“libpng”,下载tar.xz文件,解压,并执行如下命令
sudo ./configure --prefix=/usr/local
sudo make
sudo make install
##libjpeg,在http://www.ijg.org/files目录下,下载jpegsrc.v9a.tar.gz(或者下载最新的压缩包,不要下载源文件版) 
sudo ./configure --prefix=/usr/local
sudo make
sudo make install
##freetype,在sourceforge.net上搜索“freetype”,下载tar.bz2文件,并解压。
sudo ./configure --prefix=/usr/local
sudo make
sudo make install
##libgd:https://bitbucket.org/libgd/gd-libgd/downloads,下载tar.xz格式文件,如果你知道如何编译,也可以在libgd.org下载源码。
sudo ./configure --prefix=/usr/local --with-jpeg=/usr/local --with-png=/usr/local --with-freetype=/usr/local
sudo make
sudo make install

    在安装libgd时,必须指定jpeg,png,freetype这些lib的位置,否则此后在nginx安装时会报错:

Undefined symbols for architecture x86_64:
  "_gdImageCreateFromPngPtr", referenced from:
      _ngx_http_image_resize in ngx_http_image_filter_module.o
  "_gdImagePngPtr", referenced from:
      _ngx_http_image_resize in ngx_http_image_filter_module.o
ld: symbol(s) not found for architecture x86_64

    上述lib安装完毕之后,然后再次运行3)中的nginx的configure指令,应该就没有错误,然后依次执行“make” “make install”,此后我们会在“/usr/local/nginx-1.8.0”目录下看到相关的可执行文件、配置文件等。如果确实安装成功,那么我们此前的“nginx-1.8.0-src”即可删除,此后的操作只需要在安装后的文件中进行即可。

    5、测试运行

    进入sbin目录,执行“./nginx”,启动nginx,如果出错,请到logs目录下查看原因。然后在浏览器中输入“127.0.0.1”(无需端口),你将会得到nginx的欢迎页。

    接下来,我们将依次介绍nginx的几个常用的模块,在认识如何配置nginx的同时,简单了解nginx的工作原理。

    我们可以通过“./nginx -V”查看nginx的configure信息。

    “./nginx -t”用于检测配置文件是否合法。

    “./nginx -s stop”:关闭。

    “./nginx -s quit”:优雅关闭。

    “./nginx -s reopen”:重新打开log文件

    “./nginx -s reload”:重新加载配置信息,我们在修改了conf文件之后,通常使用reload即可直接加载,无需重启nginx。

    nginx会启动一个master进程,和“worker_processes”个worker进程,其中master进程主要的作用就是“加载、评定配置信息”、“维护worker进程”,worker进程用于处理实际的request,nginx基于平台的event模型,向worker进程分发request。    

    当master进程收到reload信号时,首先检测配置文件的合法性,然后尝试使用新的配置信息;如果成功,master将启动新的worker进程,并向原来的worker进程发消息请求他们shutdown,此后request将会被抓发给新的worker进程,对于原来的worker将自己已经accept的请求处理完之后即关闭;如果配置文件有问题,master将会回滚配置的更改,而worker进程不受任何影响。

    6、配置文件样例

#user  nobody;
worker_processes  2;
worker_rlimit_core 256m;
worker_rlimit_nofile 65535;

error_log  logs/error.log  info;

#pid        logs/nginx.pid;

daemon on;
worker_priority 0;

events {
    #use epoll;
    use kqueue;#linux 请使用epoll
    accept_mutex on;
    accept_mutex_delay 500ms;
    worker_connections  65535;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  65;

    server {
        listen       80;
        server_name  localhost;
        access_log  logs/localhost.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        error_page  404              /404.html;
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

    include vhosts/*.conf;
}

    上面的配置信息应该是最基本的,基本上nginx能够对静态页面做代理,下文中所有的模块都基于这个配置模板。

三、代理简析

    nginx一个重要的能力就是静态文件的代理(或cache),包括html、images等,这些静态文件通常放置在本地,比如:/data/www(一些html文件,css,js等),/data/images(图片文件)。

location / {
    root   html;
    #index  index.html index.htm;
}

location /images {
    root /data;
}

    root”表示文件所在的本地路径,最终请求的uri将会被添加到root路径之后,形成完整的文件路径,比如“127.0.0.1/images/header.jpg”,其uri为“images/header.jpg”,那么最终将会访问本地的“/data/images/header.jpg”(如果本地文件没有访问权限,将会抛出“Permission denied”)。此处还涉及到location的匹配优先级的问题,就像“/images/header.jpg”对于location为“/”和“/images”都匹配,在这种情况下,nginx将会选择“最长前缀”的哪一个,即“/images”;此外,location还能支持正则表达式,所以匹配的规则将会比较复杂,我们稍后详解location。

    对于动态代理,需要配置一个(或一组,通过upstream模块支持)web server,nginx接收客户端请求(可以对header进行修改),然后传递给web server,并等待接收proxy server的响应内容,然后再把response发送给客户端(可以对response的内容或者header进行修改),在此过程中,nginx需要与客户端、web server均要建立链接,nginx就像一个“转发桥”,只是负责将请求,根据location或者其他规则,匹配到一个合适的web server上。

server {
    listen 80 default_server;
    server_name localhost;
    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

    proxy_pass将请求转发给web server,不过这个指令还有更多的意义,我们稍后详解upstream、proxy模块。动态代理,即实际处理请求(响应数据的server)的server在运行时通过一定的算法计算得到的,而且还可以根据请求的参数特征来修改response的内容;通常我们会指定多个web server,根据一定的“负载均衡”算法选取其中一个负责处理实际的请求。

    “server_name”这个指令非常有用,nginx通常根据http请求header中的“Host”字段与“server_name”列表匹配,判定使用哪个“server”配置,然后根据uri匹配location,判定将次request交给哪个web server处理。关于server_name的匹配规则,还需要一定的了解。(如下部分配置样例中省略了部分无关的信息)

server {
    listen 80;
    server_name example.org www.example.org;
}
server {
    listen 80;
    server_name *.example.org;
}
server {
    listen 80;
    server_name mail.*;
}
server {
    listen 80;
    server_name ~^(?<name>.+)\.example\.net$;
}

  

    对于指定的请求,nginx从header中host值,将按照如下顺序进行匹配:

    1)精确的全限定名:比如server_name为“www.exmaple.org”,“example.org”。

    2)以“*”开头的最长的通配名称:比如server_name为“*.exmaple.org”。

    3)以“*”结束的最长的通配名称:比如server_name为“mail.*”。

    4)首个匹配的正则表达式。nginx中正则表达式以“~”或者“~*”开头,我们稍后详解nginx的正则格式。

    注意,在nginx中,通配表达式和正则表达式被认为是不同的,通配表达式必须以“*”开头或者结束,且“*”不能在字符串的中间出现,比如“www.*.example.org”是不合法的;否则应该在正则表达式中使用“*”,比如“~^w.*\.exmaple\.org$”,注意如果在正则表达式中使用字符串“.”,应该需要转义为“\.”,否则“.”是被作为正则表达式中特殊模式(即匹配任意字符串);通配表达式,“*”可以匹配任意多个部分,比如“*.example.org”可以匹配“www.exmaple.org”、“www.sub.exmaple.org”;那么对于“.example.org”这种格式被认为是一种特殊的正则表达式,它可以匹配“exmaple.org”、“*.example.org”。

    上文中提到,nginx中正则表达式必须以“~”开头(或者~*开头,表示字符大小写敏感)、“^”、“$”结尾,这三个特殊符号构成nginx(或者说是PCRE)正则表达式,否则被认为是普通的“全限定名”。如果你了解过正则表达式,其实这些还是非常容易理解的,不过如果正则表达式中包括“{”、“}”表示匹配次数区间,那么整个表达式都需要用引号包含,否则会编译错误。

server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"

    正则表达式中可以使用"?<name>"这种格式,在PCRE中称为“命名捕获”(named captures),那么“name”可以作为当前context中的一个变量使用。在nginx中还可以使用“数字”类型的命名捕获。

##参数方式
server {
    server_name ~^(www\.)?(?<domain>.+)$;
    location / {
         root /sites/$domain;
    }
}

##数字方式,效果等同
server {
    server_name ~^(www\.)?(.+)$;
    location / {
        root /sites/$2;
    }
}

    我们还需要对待那些特殊的情况,比如请求的header中没有“Host”或者为空,那么可以用一个空字符串来匹配这种请求:

server {
    server_name example.org www.example.org "" 192.168.1.1;
}

    当然有些时候,我们还会使用IP去访问一个nginx(没有配置host解析,通常在测试环境),那么我们我们请求的“Host”就是一个IP字符串,那么我们仍然可以按照这种规则配置server_name。

server {
    listen 80 default_server;
    server_name _;
}

    如上述例子所示,“default_server”表示为如果没有任何匹配的server_name时,将选择此server来处理。其中server_name如果配置为“_”,则表示此server匹配所有的“Host”,这些Host仅为那些不能通过“精确全限定名”、“通配表达式”、“正则表达式”匹配的。

    根据server侦听的端口号,将会把“精确匹配”、“以*开头的通配表达式”、“以*结尾的通配表达式”保存在三个hashtable中(cache),这个hashtable的大小可以通过配置文件调整;针对一个host,将会首先使用“精确匹配”,如果没有找到相应的server_name,将会从“以*开头的通配表达式”中查找,然后再从“已*结尾的通配表达式”中查找;从“通配表达式”的hashtable中查找,要慢于“精确匹配”,不过对于“.example.org”这种格式会被保存在“通配表达式”的hashtable中,而不是保存在“精确匹配”的hashtable中。对于“正则表达式”时最慢的一种方式,也是最后参与匹配的,将会根据它们在配置文件中的顺序,依次去匹配。基于这些原因,比较好的办法就是尽可能的使用“精确全限定名”,比如:

server {
    server_name example.org www.example.org *.example.org;
}
server {
    server_name sub.example.org;
}

    而不是像这样简单的配置:

server {
    server_name .example.org;
}

    如果你定义了较多的server配置或者较长的server_name字符串,那么就需要通过“server_names_hash_max_size”(会影响server_name的个数)、“server_names_hash_bucket_size”(影响server_name的字符串长度)来调整配置,否则会抛出错误,我们不需要贸然去调整这两个参数,直到它出错。

四、负载均衡

    使用nginx,其实还对其“负载均衡”的特性比较看重。通常我们有多个web server对等部署,nginx将会通过“负载均衡”模块将请求转发给合适的web server,最终提升了web站点的整体吞吐能力,同时也提高了可用性。需要注意,nginx目前是Http层面的负载均衡器,在1.9V之后将提供TCP层面的负载均衡支持。如下为nginx内置的负载均衡算法

    1)round-robin:轮询,request将会依次有序的分发给web server。one by one!默认使用此算法。

    2)least-connected:最小连接数,请求将会被分发给当前链接数最小的server。配置名“least_conn”。

    3)ip-hash:根据请求的客户端IP作为hashing key,来判定选择哪个server。配置名“ip_hash”。

http {
    upstream backend {
        ##least_conn;
        server 192.168.1.110 weight=3;
        server 192.168.1.120;
    }
    server {
        listen 80 default_server;
        #
        server_name _;
        location / {
            proxy_pass http://backend;
        }
    }
}

    上述配置,就是一个简单的“负载均衡”的样例,首先在一个“upstream”区块中声明server列表,然后在proxy_pass指令中使用它;如果没有声明“负载均衡”算法,那么默认就是用“round-robin”,其他可选值为“least_conn”、“ip_hash”,“负载均衡”算法需要在upstream区块的首行声明。

    “least_conn”算法可以让全局的性能开支,在多个server之间趋于平衡,因为不同的server可能在物理性能上就有差距,而且不同的request处理耗时也不尽相同;如果希望处理比较快的server能够尽可能的接收更多的请求,那些负载较高的server也能稳步推进(后续我们会提到流量控制),那么“least_conn”算法将非常适合。通常我们在production环境中,均采用此算法。

    “least_conn”和“round-robin”算法,将会把一个客户端(来自同一个IP)的请求分发给不同的server上,这在某些情况下并不妥,比如“粘性session”,同一个客户端的请求应该被转发给同一个server(除非此server失效后,才会被转发到其他server),否则session会话中的数据将会丢失。那么“ip_hash”算法将比较适合。不过基于残酷的现实,粘性session的设计方案并不通用。

    能够影响负载均衡策略的还有一个重要的参数:权重;“权重”用来标记某个server承载请求的“优先级”,通常权重越高的server将优先获得客户端请求,事实上“权重”也是表示一个server“承载”能力的大小,我们通常可以对硬件配置较高的server给予较高的权重,这有点像粗颗粒的“虚拟化”,如果一个server的硬件配置是另一个的2倍,那么可以将权重值设置为其2倍。

    默认upstream中所有的server权重都一样,那么“负载均衡”算法将平等对待它们。

upstream backend {
    server 192.168.1.110 weight=3 max_fails=3 fail_timeout=10s;
    server 192.168.1.120;
    server 192.168.1.130;
}

    对于上述配置,每5个请求,将有3个分发给“192.168.1.110”,其他两个server各一个。上述提到的三种负载均衡算法中,都可以使用weight。

    “健康监测”对于负载均衡是必须的,这是提供可用性、“故障迁移”的必要手段。比如当某个server失效,请求未能正常处理,那么我们应该将分发给那些“正常”的server,并将故障的server从列表中移除,直到它恢复,以避免后续更多的请求处理失败。nginx当与一个server建立链接失败后,会在“fail_timeout”时间内最多尝试“max_fails”次,如果仍为失败,则将次server标记为“failed”,并从服务列表中移除。默认“max_fails”为1,如果“max_fails”为0,则表示关闭“健康检测”;“fail_timeout”(默认位10s)表示检测多久后被标记为“failed”,nginx会以优雅的方式检测那些失效的server,如果它们再次上线,则将它们标记为“alive”,即可继续提供服务。

    更多的关于“负载均衡”配置方式,我们将在下文“upstream”模块中详解。

五、计量单位

    nginx配置文件中,对于表示“数据尺寸”的数字后,可以跟上“k”、“m”、“g”等单位缩写字母,无单位后缀表示“字节”。对于表示“时间”的数字,可以使用“ms”、“s”、“m”(分钟)、h、d(天)、w(周)、M(月)、y(年),我们还能以组合的方式使用它们,比如“1h 30m”,表示一小时30分钟,相当于“90m”或者“5400s”,无单位后缀表示“秒”。如下例:

proxy_cache_path  /home/proxy_cache_path levels=1:2 keys_zone=cache_one:64m inactive=1d max_size=30g;

    

六、HTTPS配置

    https突然风靡起来,就连小论坛也开始用https,显的很技术派,似乎它的低性能的缺点并没有想象的那么可怕。在实际环境中,nginx和后端的web server均可以支持htps,为了架构的简单性,以及不希望web协议干扰程序的实现,我们通常在nginx这一次支持https,而在web server层(比如tomcat)则继续使用http协议。配置样例如下:

upstream backend
 {
    server   192.168.1.110:8080;
    server   192.168.1.120:8080;
 }
server {
    listen 80;
    server_name www.example.com example.com;
    rewrite ^/(.*)$  https://$host/$1 last;
 }
 
server {
    listen 443;
    server_name www.example.com example.com;
    ssl on;
    ssl_certificate      /usr/local/nginx/conf/ssl/example.com_bundle.crt;
    ssl_certificate_key  /usr/local/nginx/conf/ssl/example.com.key;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout  5m;
    keepalive_timeout 60;
    ssl_protocols  SSLv3 TLSv1 TLSv1.2 TLSv1.1;
    ssl_ciphers HIGH:!aNULL:!MD5:!EXPORT56:!EXP;
    ssl_prefer_server_ciphers   on;

    location / {
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
        proxy_pass http://backend;
    }
}

    无论如何,你在使用HTTPS之前,需要开启SSL,如果是线上应用,还需要从第三方机构购买一个合法的认证包(如果自己生成,其实并没有什么卵用),这个包里将会包含crt和key两个文件,然后根据上述nginx样例将文件的路径配置正确即可,需要提醒,nginx需要有访问这两个文件的权限。

    SSL操作需要消耗额外的CPU资源,主要在SSL握手阶段,有2种方式可以减少每个客户端的这种操作:1)开启链接的keepalive选项(http 1.1),那么一个客户端可以通过一个(次)链接发送多个请求,事实上达成了链接重用的目的,减少了创建链接和“握手”的次数。 2)重用SSL session参数,以避免此后的子链接再进行握手操作,通过“ssl_session_cache”配置,session将会被保存在cache中,可以在workers进程之间共享,1M的cache空间可以保存大概4000个sessions,缓存生命周期默认为5分钟,可以通过“ssl_session_cache”修改。“ssl_session_cache shared:SSL:10m”表示cache可以在多个workers进程之间共享,cache名位“SSL”,缓存大小为10M(数据尺寸,不是10分钟)。

    上述配置,任何http请求都会被rewrite成https,不过在proxy_pass分发给后端web server时使用http协议,这是一种比较常用的方式,所以让你的网站支持https,只需要在nginx层做认证即可,不需要调整web server的配置。

七、其他

    在描述nginx的指令之前,我们基本熟悉了nginx指令的配置方式:“<指令名称> 值 [可选参数名=参数值];”,以“;”结束,一个区块我们可以包含多个指令,那么这种区块称为context(上线文),nginx中常用的区块有“http”、“events”、“server”、“upstream”、“location”等,最外层的context称之为“main”,context通常是有继承关系,比如“location”需要包含在“server”中。“#”表示行注释。 

    在nginx配置文件中,如果配置项表示路径,比如“root /data/images”,如果为相对路径,则起始与nginx根目录。

    一个指令可以被配置在多个context下,比如“root”:

http {
    root /data/www;
    server {
        listen 80;
        server_name localhost;
        root /data/www/html;
        location / {
              root html;
             index index.html index.htm;
        }
    }
}

    那么根据context的继承关系,子context的指令将覆盖其父context,同理,其他指令也将是如此。

八、nginx常规配置模板

#user  www www;
worker_processes auto;
error_log  /home/wwwlogs/nginx_error.log crit;
#pid        /usr/local/nginx/nginx.pid;

#Specifies the value for maximum file descriptors that can be opened by this process.
worker_rlimit_nofile 655350;

events
	{
		use epoll;
		worker_connections 655350;
	}

http
	{
		include       mime.types;
		default_type  application/octet-stream;

		server_names_hash_bucket_size 128;
		client_header_buffer_size 32k;
		large_client_header_buffers 4 32k;
		client_max_body_size 50m;
		server_tokens off;

		sendfile on;
		tcp_nopush     on;

		keepalive_timeout 60;

		tcp_nodelay on;

		fastcgi_connect_timeout 300;
		fastcgi_send_timeout 300;
		fastcgi_read_timeout 300;
		fastcgi_buffer_size 64k;
		fastcgi_buffers 4 64k;
		fastcgi_busy_buffers_size 128k;
		fastcgi_temp_file_write_size 256k;
		proxy_connect_timeout 600;
		proxy_read_timeout 600;
		proxy_send_timeout 600;
		proxy_buffer_size 64k;
		proxy_buffers   4 32k;
		proxy_busy_buffers_size 64k;
		proxy_temp_file_write_size 64k;
		
		gzip on;
		gzip_min_length  1k;
		gzip_buffers     4 16k;
		gzip_http_version 1.0;
		gzip_comp_level 2;
		gzip_types 	 text/plain application/x-javascript text/css application/xml text/xml application/json;
		gzip_vary on;
		log_format  access '$remote_addr - $remote_user [$time_local] $host '
                                   '"$request" $status $body_bytes_sent $request_time '
                                   '"$http_referer" "$http_user_agent" "$http_x_forwarded_for"'
                                   '$upstream_addr $upstream_status $upstream_response_time' ;
        server {
            listen 80;
            server_name  _;
            return 403;
        }
        include vhost/*.conf;
}

    以“exmaple.org”为例,如下为基于upstream负载均衡模式的配置:

upstream example_backend {
          server   127.0.0.1:9080;
	      server   192.168.1.198:9080;
 }
server {
        listen 80;
        server_name www.example.org example.com .example.org;
    
    location / {
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
        proxy_pass http://example_backend;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    access_log  logs/www.example.org.log;
    location ~ .*\.(gif|jpg|jpeg|png|bmp|ico|swf|xml|css|js)$ {
        proxy_pass      http://example_backend;
        proxy_set_header        Host    $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        expires 15d;
    }
    location ~ .*\.(jhtml)$ {
        proxy_pass      http://example_backend;
        proxy_set_header        Host    $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        expires -1;
    }
}

    上述配置中,对后端web server返回的静态类型文件,让浏览器缓存15天,对于jhtml格式的动态文件不缓存。

九、基于HTTPS配置核心配置

upstream example_backend {
    server   127.0.0.1:9080;
    server   192.168.1.198:9080;
 }
server {
        listen 80;
        server_name www.example.org example.org;
        rewrite ^/(.*)$  https://$host/$1 last;
 }
server {
    listen 443;
    server_name www.example.org example.org;

    ssl on;
    ssl_certificate      /usr/local/nginx/conf/ssl/example.crt;
    ssl_certificate_key  /usr/local/nginx/conf/ssl/example.key;
    ssl_session_timeout  5m;
    ssl_protocols  SSLv3 TLSv1 TLSv1.2 TLSv1.1;
    ssl_ciphers HIGH:!aNULL:!MD5:!EXPORT56:!EXP;
    ssl_prefer_server_ciphers   on;

    location / {
        ...
    }
}

十、对于文件系统而言,基于nginx缓存的配置

upstream static_backend {
    server 192.168.1.198:8080;
	server 127.0.0.1:8080;
}
#设置Web缓存区名称为cache_one,内存缓存空间大小为256MB,1天没有被访问的内容自动清除,硬盘缓存空间大小为30GB。
proxy_temp_path   /home/proxy_temp_dir;
proxy_cache_path  /home/proxy_cache_path levels=1:2 keys_zone=cache_one:256m inactive=1d max_size=30g;

server {
    listen       80;
    server_name static.example.org;
    location / {
	        proxy_next_upstream http_502 http_504 error timeout invalid_header;
        	proxy_cache cache_one;#nginx本地cache开启
        	proxy_cache_valid 200 304 30d;
        	proxy_cache_valid 301 302 404 1m;
        	proxy_cache_valid any 1m;
        	proxy_cache_key $host$request_uri;

		add_header X-Proxy-Cache $upstream_cache_status;
        	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_set_header X-Forwarded-For $remote_addr;
       		proxy_set_header If-Modified-Since $http_if_modified_since;

		expires 30d;#客户端缓存,在header中增加“Expires”
		add_header Cache-Control public;
		proxy_pass http://static_backend;
        	if_modified_since before;
        }
    #location ~ /purge(/.*) {
        # allow 127.0.0.1;
        # allow 192.168.1.0/24;
        # deny  all;
        # proxy_cache_purge cache_one $host$1$is_args$args;
    # }
    #https://github.com/FRiCKLE/ngx_cache_purge/
    access_log  /home/wwwlogs/static.example.org.log  access;
}

相关推荐