Nginx学习总结：常用module(二)

斜体下划线，表示建议采用默认配置，无需显式的配置

一、ngx_core_module

    1、accept_mutex 【on | off】

        上下文：events

    默认为“on”，在worker进程accpet客户端链接时，是否为“互斥”？如果为on，则当有新链接时，worker进程将会依次接收，否则workers将同时“竞争”（当链接的存量较小时，这种竞争会浪费较多的系统资源）。

         accept_mutex_delay 【time】：默认值为“500ms”；当accept_mutex开启时，如果一个worker进程正在accept新的链接，那么其他worker如果也需要尝试accept时需要的最大等待时间。

    2、include 【file | mask】

       上下文：main

    无默认值，表示需要加载的“额外”配置文件列表，当nginx同时为多种server代理时（比如图片服务器，应用服务器），为了避免单个conf文件过于繁杂，我们可以将不同的server配置拆分到各自的conf文件中；比如我们将图片服务器的配置单独放在image.conf，将api的放在api.conf，那么nginx.conf再将它们include。

    3、multi_accpet 【on | off】

        上线文：events

    默认值为“off”，如果队列中有多个请求，那么是否允许一个worker批量accept多个链接，默认一次只能接收一个链接。

    4、use 【method】

        上下文：events

    nginx使用何种“链接处理”方法，通常我们不需要显式的声明，默认情况下nginx将会选择当前平台上最高效的方式；目前比较常见的有：

        1）select：比较低效的方式，如果平台上没有更加高效的方式，那么将会选择select。

        2）poll：同上。

        3）kqueue：一种比较高效的方法，通常在BSD平台上比较常用，比如Mac OS。

        4）epoll：linux 2.6+平台上比较高效的方法。我们在Centos上经常使用这种IO模型。

    5、worker_connections 【number】

        上下文：events

    默认值为512（建议设置为65535，即足够大）；一个worker进程能够同时打开的连接数，nginx需要同时与Client和后端的server建立链接，这个值为这两者之和；同时此值不能超过“worker_limit_nofile”，此值表示nginx进程最多所能打开的文件个数。

    6、worker_processes 【number | auto】

         上下文：main

     默认值为1，可选值为“auto”；用来定义nginx worker进程的个数，此参数值受限于CPU的核数、磁盘的个数（并行写入能力），通常此值设定为CPU的核数，或者设定为“auto”让nginx自己去判定。在nginx启动后，可以通过“ps -ef | grep nginx”查看到一组worker进程。

    8、worker_rlimit_nofile 【number】

        上下文：main

    一个worker进程所能打开的最大文件个数，本人通常设置为65535（通常这个值已经足够大了），或者不设定此值，有系统决定。可以通过修改系统的limits.conf文件来限定进程所能打来的最大文件数量。

* soft nofile 655350
* hard nofile 655350
##通过ulimit -n查看

 

 二、ngx_http_core_module

    1、chunked_transfer_encoding 【on | off】

        上下文：http，server，location

     默认为“on”，表示开启“分块编码”传输方式，在HTPP/1.1协议中支持；如果客户端不支持（或者不希望使用分段编码），可以将其关闭；我们下文中讲述“keepalive”时会体现“分块编码”的作用。如果此参数为“on”，则会在响应的header中增加“Transfer-Encoding:chunked”。

 

    2、client_body_buffer_size 【size】

        上下文：http，server，location

    32位平台上默认值为“8k”，64位平台为“16k”，即默认值为平台的“memory page”的2倍；设定客户端请求中body数据的缓冲区大小，如果body数据大于此值，那么整个body或者其中一部分将会被写入到一个临时文件。

    client_body_in_file_only 【on | clean | off】：请求的body数据是否只保存在文件中，默认位“off”，表示基于buffer cache + file模式。我们通常在debug请求内容时才会开启“on”，此时数据只保存在file中，且请求结束后不会被清除；“clean”表示body被保存在文件中，但是请求结束后被删除。

    client_body_tmp_path：body数据的临时文件被保存的路径。

    3、client_body_timeout 【time】

        上下文：http，server，location

    默认值为“60s”，对于一个request，nginx在读取body数据时，等待的最长时间；这个时间是read阻塞的时间，而不是整个body读取的时间。如果读取超时，则返回408错误（Request Time-out）。在高并发环境下，建议缩小此值，以便让nginx链接尽快退出（fast failed）。

    4、client_max_body_size 【size】

        上下文：http，server，location

    设置客户端请求body最大数据量，通过请求header中的“Content-Length”指定，默认值为“1M”；如果请求的body数据尺寸超过此值则返回“413”（Request Entry Too Large）。可以将此值设置为“0”来关闭body尺寸的检测；此外，如果你的应用中有小文件上传的需求，那么“client_max_body_size”应该设置的合理，否则可能文件上传失败；同时为了避免恶意请求，最好给这个指定设置合理的上限值。

 

    5、client_header_buffer_size 【size】

        上下文：http，server

    默认值为“1k”，此值基本上可以满足大多数应用；如果你的应用中请求header包含的大量的cookie或者来自WAP客户端，当buffer不足时，那么由“large_client_header_buffers”指令来判定。

    large_client_header_buffers 【number】【size】：

    设置读取较大header时，使用buffer的最大number（个数）和size（尺寸），默认值分别为“4”和“8k”；无论是header的总长度、还是单个field、还是uri的数据长度（get请求）均不能超过最大值，如果uri长度超过阀值则返回414（Request-URI Too large），如果header过大则返回400（Bad Request）错误。这个buffer是按需分配的，如果链接在此次请求结束后转为“keepalive”状态，那么此次请求的buffer将会被清除。

    6、default_type 【mime-type】

        上下文：http，server，location

    定义默认的Response中MIME 类型，默认值为“text/plain”。通常设置为“application/octet-stream”表示任意二进制数据。大家可以搜索“MIME类型对照表”，会得到更多的可选配置。nginx还提供了一个指令“type”，它可以根据请求文件的后缀来匹配各自的“MIME”类型。

 

    types {...}

    上下文：http，server，location

    一个区块，其上下文用于定义MIME类型匹配表：

default_type application/octet-stream;
types {
    text/html html html;
    image/gif gif;
    image/jpeg jpg;
}
location /download {
    #types {}
}

 

    配置样例如上，如果希望“/download”中所有的请求都使用默认“default_type”，即可声明一个空的types区块即可。对于不能在types中匹配的请求，也将使用“default_type”。

 

    7、error_page code ... uri

        上下文：http，server，location

    当后端server发生错误时，跳转到nginx的错误页面。

error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
error_page 400 http://example.org/help.html

 

    

    8、keepalive_disable 【none | browser...】

        上下文：http，server，location

    默认值为“msie6”，即“微软IE浏览器6”；这个指令表示当浏览器行为异常时是否关闭“keepalive”状态的链接，browser参数表示匹配何种浏览器。“msie6”将会关闭IE6之前的浏览器中keepalive

选项（即不使用keeppalive方式），“safari”表示关闭Safari或者类safari浏览器中的keepalive特性，“none”则表示对于任何浏览器都允许开启keepalive（是否开启，由请求决定）。

 

    9、keepalive_timeout  timeout【header_timeout】

        上下文：http，server，location

    默认值为“75s”，对于http而言这个值通常较大。这个参数还是很重要，调节参数值需要足够慎重。第一个“timeout”表示链接将会被server端keepalive的时间，如果为0，则关闭“keepalive”特性（即response中将会添加“Connection:close”），当一个被keepalive的客户端连接在server端（nginx）保持了timeout时间后将会被关闭；“header_timeout”为可选项，客户端用户保持链接的时长，这个值将会被添加到响应的头部，“Keep-Alive:timeout=15”，这两个参数可以不同。

        keepalive_timeout 30 30;

 

    10、limit_except 【method】... {...}

        上下文：location

    一个区块，无默认值；通常和“ngx_http_access_module”配合使用，此指令用于限制请求的method类型，表示“除method之外”的其他类型请求均被拒绝访问，method类型比如“GET”、“POST”、“PUT”、“DELETE”等。

location /update {
    limit_except DELETE POST {
        allow all;
    }
}

 

    

    如上述配置，表示“/update”除了“DELETE”、“POST”方式之外，其他类型的请求将被拒绝。

 

    11、limit_rate 【rate】

        上下文：http，server，location

    默认值为“0”；流量速率限制，表示每秒向Client输出的数据字节数，“0”表示关闭流量速率控制。这个限制针对每个请求，而非整体，如果一个客户端同时开启2个链接，那么整体的速率应该是设定值的2倍。这个参数的设定需要权衡，如果关闭限制，那么请求的数据将会尽可能快的被发送；此外，对于基于“下载”、“数据流”类型的应用，我们需要限定到一个合适的值，已避免带宽的局限性等外在因素，导致响应数据的输出分配不均。如果是普通的web应用，建议关闭此值。

    limit_rate_after 【number】：默认值为0，表示在响应输出一定的数据量之后，再进行流量速率限制，配置“limit_rate”。

location /video {
    limit_rate 1m;
    limit_rate_after 10m;
}

 

 

    12、location

        上下文：server，location

    这个指令已经非常熟悉了，即匹配uri，并执行location内部的设定。location可以定义为“字符串前缀”类型，或者正则表达式。正则表达式以“~”开头（大小写无关），或者“~*”开头（大小写敏感）；在匹配uri时，nginx首先使用“前缀字符串”类型（比如“location /images {}”）,如果有多个location匹配成功，则选取“前缀最长”的那个，并记住它，此后继续使用正则表达式匹配，按照正则表达式在配置文件中声明的顺序逐个匹配，如果匹配成功则终止匹配，且使用此location中的配置，否则使用先前匹配的“字符串前缀”location配置。到此为止，你可能会问，为什么不首先匹配正则表达式，成功就执行，否则再匹配“字符串前缀”？请看下文。

    如果在匹配“前缀字符串”时，其匹配的最长前缀location包含“^~”修饰符，则不再匹配正则表达式，直接使用此location配置。

    如果“前缀字符串”包含“=”修饰符，则表示精确匹配，它是一种速度最快的匹配方式，如果匹配成功，则不再进行正则表达式匹配。

    注意：“~”、“~*”、“=”、“^~”这些修饰符后面有个空格，然后跟上表达式。

location / {
    A;
}
location = / {
    B;
}
location /doc {
    C;
}
location ^~ /images {
    D;
}
location ~* \.(git|jpg|jpeg)$ {
    E;
} 

 

    1）对于“/index.html”，则会匹配B，带有“=”修饰符的精确匹配将会被选中，且终止后续匹配。

    2）对于“/doc/index.html”，则会匹配C，最长前缀匹配，因为后续没有符合的正则表达式，则最终选取C。

    3）对于“/image/1.jpg”，则选取D；首先根据“最长前缀”匹配D，因为D包含“^~”修饰符，则终止匹配，这也意味着正则表达式E不会参与匹配，最终选择D。

    4）对于“/doc/1.jpg”，则选择E；首选根据“最长前缀”匹配到A，但是A没有包含终止符，则继续匹配正则表达式，那么E匹配成功，最终选择E。

 

    13、port_in_redirect 【on | off】

        上下文：http，server，location

    默认值为“on”，表示当nginx在处理“redirect”相关操作时，是否将当前“server”配置侦听的端口，作为redirect时URL拼装的一部分。

    server_name_in_redirect 【on | off】：

    默认值为“off”，表示在redirect时，是否将“server_name”指令中匹配的server名称作为URL拼装的一部分；如果为“off”，则使用请求头部“Host”信息，如果“Host”为空，则使用server的IP。

server {
    listen 80;
    server_name example.org www.example.org .example.org
    #port_in_redirect on;
    #server_name_in_redirect off;
    location ~ /s/(.+)$ {
        return 301 /r/$1;
    }
    location /t {
        root html;
    }
}

 

    上述只是一个简单的例子，不过rewrite中还有更加正规的写法。rewrite的URL可以是有nginx根据规则拼装的，也可以指定全限定名的URL。上述2个指令，就是在拼装url的时候使用。

 

    14、send_timeout 【time】

        上下文：http，server，location

    默认值为“60s”，其含义类似于上文中的“read_timeout”；指nginx在响应时，一次write操作被阻塞的最大时间，如果阻塞超时（即客户端未能读取）则导致链接关闭。

    15、sendfile 【on | off】

        上下文：http，server，location

    默认值为“off”；即linux的“sendfile”，当nginx作静态资源代理时，建议开启此参数，可以较大的提升IO输出的能力，减少内存数据copy。

    sendfile_max_chunk 【size】：

    默认值为“0”；用户在sendfile时每次“sendfile()”调用所能传输的数据大小，“0”表示无限制（受限于系统配置）。

 

    16、server_tokens 【on | off】

        上下文：http，server，location

    默认值为“on”；表示是否在响应中增加“Server”头，我们在通常会在响应中看到“Server:nginx/1.8.0”。如果你是个讲究人，可以关闭此特性。

    17、tcp_nodelay 【on | off】

        上下文：http，server，location

    默认值为“on”；同TCP种的“nodelay”选项，建议保持默认。

    18、tcp_nopush 【on | off】

        上下文：http，server，location

    默认值为“off”，是否开启TCP_NOPUSH（在BSD平台下）或者TCP_CORK（Linux） socket选项，仅当“sendfile”开始时才会有效。这个参数的效果与“tcp_nodelay”相悖，即开启nagle算法，为了提高发送的效能，尽可能将数据组合成一个package后才发送。如果你的nginx开启了本地缓存，或者proxy_buffer机制，建议将此值调整为“on”。

    1）将响应的header和文件的开始作为一个packet发送。 2）文件内容封装成“满包”（full packet）发送。

 

三、nginx中常用变量

    1、$http_user_agent：HTTP请求中“userAgent”信息，通常在log时使用。

    2、$http_cookie：HTTP请求中cookie列表信息，通常在log文件、debug时使用。

    3、$args、$query_string：两个指令等同，表示HTTP请求的查询字符串列表。

    4、$arg_name：获取key为“name”的查询字符串。

location /image
    resize $arg_width $arg_height;
}
##http://example.org/image/1.jpg?width=130&height=130

 

    5、$binary_remote_addr：二进制格式的客户端地址，四个字节。

    6、$body_bytes_sent：发送给客户端的字节数，通常在log中使用。

    7、$content_length：请求头部“Content-Length”的值。

    8、$content_type：请求头部“Content-Type”的值。

    9、$cookie_name：解析方式同“$arg_name”，获取key为“name”的cookie值。

    10、$host：请求头中“Host”值，如果此值为空，在上下中中将会使用匹配的“server_name”，如果Host中包含port，$host将会抛弃port部分。

    11、$hostname：“Host”值。

    12、$remote_addr：客户端请求的IP地址，7~15个字节，可读字符串，通常用log日志输出、信息传递等。$binary_remote_addr通常在nginx内部使用，便于cache存储或者比较。

    14、$remote_port：客户端端口。

    15、$request：整个请求线。包括协议、域名、uri和查询字符串。

    16、$request_body：

    17、$request_uri：请求的uri部分，包括查询字符串。

    18、$scheme：请求的协议，http或者https。

    19、$uri：请求的uri，不包括查询字符串。比如“http://example.org/image/1.jpeg”，那么其uri为“/image/1.jpeg”。

    20、$server_name：接收请求的web server的名称。

    21、$server_port：接收请求的web server的端口。

 

 

四、ngx_http_access_module

    这个模块中只有2个指令“allow”、“deny”，根据语义，“allow”就是允许访问，“deny”就是拒绝访问。指令发挥效果，跟其在区块中被声明的顺序有关。

server {
    server_name example.org www.example.org .example.org
    location / {
        deny 192.168.1.1;
        allow all;##拒绝192.168.1.1，其他IP均通过
    }
    location /callback {
        allow 192.168.1.0/24;#只允许本地站点网络访问
        deny all;
    }
}

 

 

    1、allow 【address | all】

        上下文：http，server，location，limit_except

    指定允许访问的address。“allow all”表示允许所有address访问。

    2、deny 【address | all】

        上下文：http，server，location，limit_except

    拒绝指定的address访问相关模块，“all”表示拒绝所有。

 

五、ngx_http_charset_module

    主要用来在响应的头部增加“Content-Type”中的编码信息，它还能将响应进行编码。

    1、charset 【charset | off】

        上下文：http，server，location

    默认值为“off”，表示不向“Content-Type”增加编码信息。此指令主要负责将指定的“charset”添加到响应的“Content-Type”头部中。如果此指令设定的“charset”与“source_charset”不同，则会将响应内容进行一次重新编码转换，这对异构系统、乱码故障排查有很大帮助。

    2、override_charset 【on | off】

        上下文：http，server，location

    默认位“off”；当charset开启时，且响应的“Content-Type”中已经包含了字符集信息，是否覆盖！如果响应的“Content-Type”的字符集与charset指令设定的不同，那么将使用响应的字符集作为“source_charset”，并编码转换。

    3、source_charset 【charset】

        上下文：http，server，location

    指定响应的原始字符集编码，如果此值与“charset”指令中设定的不同，则会执行编码转换。如果响应的“Content-Type”指定了charset，那么此值将会替换“source_charset”参与编码转换。

 

六、ngx_http_headers_module

    1、add_header 【name】【value】

        上下文：http、server、location

    向响应的header中增加字段，最常用的就是“add_header Cache-Control max-age=0”。

    2、expires 【modified】【time】

        上下文：http，server，location

    默认值为“off”，可选值“epoch”（1970-01-01 00:00:00）、“max”（10年）；这个指令非常重要，最终向响应的header中添加“Expires”、“Cache-Control”这两个头部，这对控制资源的过期时间、充分利用浏览器缓存而提高站点的访问能力，有重要作用。如果指定的值为负值，最终输出“Cache-Control:no-cache”，否则（包括0）将输出“Cache-Control:max-age=时间秒数”。如果为“off”将不会在响应头上添加上述2个header。

    1）如果location中表明访问本地文件，通过“root”指令指定文件路径，即访问静态资源，此时响应header中还会增加“Last-Modified”、“ETag”字段(HTTP 1.1)。即访问本地静态资源，一定会使用客户端缓存。

    2）如果location中表明访问后端web server，通过“expires”指令可以让响应的header中增加“Expires”和“Cache-Control”。

upstream backend {
    server 192.168.1.110;
}
server {
    listen 80;
    server_name example.org www.example.org .example.org;
    location / {
        proxy_pass http://backend;
    }
    location ~ .*\.(jhtml)$ {
        proxy_pass http://backend;
        expires -1;
    }
    location ~ .*\.(gif|jpg|jpeg|png|bmp|ico|css|js)$ {
        proxy_pass http://backend;
        expires 10d;
    }
}

 

    此例展示了对“jhtml”格式的动态页面不缓存，最终响应的头部为“Cache-Control:no-cache”；对于图片、CSS、js这种静态文件缓存10d，此后再次访问将会返回304。

    备注：“Cache-Control:no-cache”是server端（nginx，web server）响应给客户端时增加的header，“Cache-Control:max-age=0”是客户端向server端发请求时使用的header，server端响应时也能使用max-age=0，其效果一样。根据测试，对于静态资源（比如图片，css，javascript），即使nginx不设定expires，后端tomcat也会在响应header中增加“ETage”、“Last-Modified”；的对于静态资源的再次访问，客户端将会发送“Cahce-Control:max-age=0”以及“If-Modified-Since”或者“If-None-Match”，那么nginx将会通过与本地缓存（或者向后端web server发送请求，有它来判断）比较，得知此资源是否修修改，如果没有修改则返回304，那么nginx（或者后端web server）不输出实际数据，只是告知客户端使用本地缓存即可。

 

七、gzip模块

    使用gzip算法压缩响应内容，可以用来帮助减少数据传输的尺寸，gzip对文本类型数据压缩效率非常高，因此在普通的web项目中，强烈建议开启。gzip算法目前主流的现代浏览器都支持（较旧的版本可能不支持，在HTTP1.0下需要注意），gzip会稍微消耗一些CPU资源。

    1、gzip 【on | off】

        上下文：http，server，location

    默认值为“off”，是否开启gzip。

    2、gzip_buffers 【number | size】

        上下文：http，server，location

    在32位平台上默认值为“32 4k”，64位平台上“16 8k”，其中“size”默认为当前平台的一个内存页。设定用于压缩一个请求使用的buffer的大小和数量，

    3、gzip_comp_level 【level】

        上下文：http，server，location

    设置gzip的压缩级别，默认值为1，最大值不得超过9；压缩级别越高，压缩的结果数据越小，解/压缩过程越消耗CPU。

    4、gzip_min_length 【length】

        上下文：http，server，location

    默认为“20”；设定被压缩响应的最小尺寸，只有超过此尺寸的响应才会被压缩，length由响应的“Content-length”决定（通常tomcat会在响应中增加此header，当然开发者也可以在header上手动指定，比如body为outputstream时）。

    5、gzip_http_version 【1.0 | 1.1】

        上下文：http，server，location

    默认值为“1.1”；设定使用gzip的最小HTTP版本，低于此版本则不压缩。

    6、gzip_types 【mime-type】

        上下文：http，server，location

     默认值为“text/html;”；当gzip开启时，只对指定的“MIME”类型的响应使用gzip，但无论如何，“text/html;”类型一定会压缩。

    7、gzip_vary 【on | off】

        上下文：http，server，location

    默认值为“off”；如果nginx开启了“gzip”、“gunzip”、“gzip_static”，且在当前请求中应用，那么是否在响应的中添加“Vary:Accept-Encoding” header；这个header可以帮助我们（以及浏览器）判定请求是否使用gzip。

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;

 

八、gunzip模块

    如果客户端（浏览器）不支持gzip，那么nginx将负责解压那些后端server响应的header中包含“Content-Encoding:gzip”的响应内容。

    1、gunzip 【on | off】

        上下文：http，server，location

    默认为“off”；是否开启“gunzip”特性，如果客户端不支持gzip，那么意味着nginx或者web server返回的请求使用了gzip压缩，浏览器将无法使用。此特性将和“gzip”、“gzip_http_version”、"gzip_disable"、“gzip_proxied”、“gzip_vary”指令配合。如果客户端支持gzip，那么不解压，否则使用gunzip。

    2、gunzip_buffers 【number】 【size】

        上下文：http，server，location

    32位平台默认为“32 4k”，64位平台默认为“16 8k”，其中“size”默认为平台的一个内存页（memory page）。

 

九、ngx_http_limit_conn_module

    这是一个很好的运维模块，用来限定每个指定的“key”下最大连接数，比较典型的是控制每个客户端IP的并发链接数。并不是所有的链接都计算在内，只计算那些已经有一个请求被server处理且整个header已经被read的链接。

    1、limit_conn 【zone】 【number】

        上下文：http，server，location

     指定使用的zone的名称（由“limit_conn_zone”来声明zone），以及通过“number”指定key允许的最大链接数。当超过这个阀值时，server将会返回503错误代码。

    2、limit_conn_status 【code】

        上下文：http，server，location

    默认值为“503”；对于那些超过limit的请求，将会返回此code。

    3、limit_conn_zone 【key】 【zone=name:size】

        上下文：http，server，location

    设定一个内存共享空间zone，指定它的名称和空间大小；“zone”根据保存每个key关联的链接的状态，这些状态包括当前链接数。“key”可以为“text”、变量或者它们的组合。

limit_conn_zone $binary_remote_addr zone=addr:10m;

    此配置的意思为：zone的名称为“addr”，大小为10M，将客户端IP作为“key”，这zone保存每个客户端IP的链接数。同时需要强调，使用“$binary_remote_addr”作为key来限定连接数，是绝大多数应用常用的手段（当然，还有其他的设定方式，比如“$server_name”，每个web server支撑的连接数）。“$binary_remote_addr”和“$remote_addr”变量都可以表示客户端地址，其中“$binary_remote_addr”（二进制格式）只需要4个字节，而“$remote_addr”是可读字符串大概需要7~15个字节，所以对于cache存储而言，占用较少的字节更加便于存储而且二进制格式易于比较。

http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;
    server {
        location /download {
            limit_conn addr 3;
        }
    }
}

 

十、ngx_http_limit_req_module

    同“limit_conn”模块一样（请参考上述），limit_req模块，针对每个key限定请求处理的速率（rate），比较典型的是，按照客户端IP，限定此IP下请求的处理速率。模型采用了“leaky bucket”（漏桶模型）方式，内部基于queue实现，这种模型的基本原理为：指定一个容量为“burst”的桶，桶底有一个“洞”，水以不确定的速率加入桶中，以固定的速率从洞中流出；如果桶满以后，水将溢出。

    1、limit_req 【zone=name】【burst=number】【nodelay】

        上下文：http，server，location

     指定使用的zone名称，burst的容量大小。默认情况下burst值为0。

    2、limit_req_zone 【key】 【zone=name:size】【rate=rate】

        上下文：http

    设定共享空间zone，指定zone的名称和大小，以及限定的速率。其中“key”可以为文本、变量或者二者的组合；通常“key”为“$binary_remote_addr”，即限定每个客户端IP的请求处理速率。

    3、limit_req_status 【code】

        上下文：http

    默认为“503”；对于那些过量的请求，将会拒绝并返回503错误。

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

server {
    location /search {
        limit_req zone=one burst=5;
    }
}

    上述配置表明，共享空间名为“one”，大小为10M，此zone下每个IP只允许每秒一个请求，对于“/search”路径而言，其burst容量为5，即允许5个请求等待处理，对于后续“过量”的请求，将会被拒绝并返回503错误。

 

十一、ngx_http_stub_status_module

    这个对运维有些帮助，简单而言，就是能够通过一个url获取nginx当前的基本状态信息，它可以对一些监控平台输出数据。

location /_basic_status {
    stub_status;
    allow 192.168.1.1/24;
    deny all;
}

 

   输出结果中数据解释：

    1）Active connections：当前活跃的链接数，包括那些等待处理的链接。

    2）accepts：已经被nginx worker接收的链接数。

    3）handled：已经被处理的链接数。

    4）requests：客户端请求数。

    5）Reading：nginx正在read请求header的链接数。

    6）Writing：nginx正在写入响应给客户端的链接数。

    7）Waiting：等待请求的、空闲的客户端链接数。

 

评论

1 楼 hongyuan89 2015-12-17  

good，楼主总记得非常好，赞