Nginx的基本属性配置

这篇文章主要讲解了“Nginx的基本属性配置”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Nginx的基本属性配置”吧!

创新互联建站是网站建设技术企业,为成都企业提供专业的成都网站制作、成都网站设计、外贸营销网站建设,网站设计,网站制作,网站改版等技术服务。拥有十多年丰富建站经验和众多成功案例,为您定制适合企业的网站。十多年品质,值得信赖!

1. Nginx服务的基本配置

1.1 用于调试进程和定位问题的配置项
  • 是否以守护进程的方式运行nginx

    # 默认on
    daemon on|off;

  • 是否以master/worker方式工作

    # 默认on,指定了是否以master-worker进程的方式运行,如果设置为off,那么所有的请求将只会由master进程处理
    master_process on|off;

  • error日志的设置

    # 指定了error日志的目录和日志级别,第二个参数用于指定目录,第三个参数用于指定日志级别,总共有:debug、info、notice、warn、error、crit、alert、emerg,这些日志级别中,从左往右优先级依次增大,默认为info
    error_log logs/error.log error;

  • 是否处理几个特殊的调试点

    # 指定了调试点
    debug_points stop|abort

  • 仅对指定的客户端输出debug级别的日志

    debug_connection IP|CIDR

    该参数主要用于events模块中,针对指定的ip或者网段记录debug日志:

    events {
      debug_connection 10.224.66.14;
      debug_connection 10.224.57.0/24;
    }

    需要注意的是,在使用该参数时,必须要确保在进行configure时已经加入了--with-debug参数,否则不会生效;

  • 限制coredump核心转储文件的大小

    worker_rlimit_core size;

    在Linux操作系统中,如果一个进程由于错误或者收到信号而终止时,会将进程执行时的内存内容写入一个文件(core文件),以作为调试之用,这就是所谓的核心转储。在nginx进程宕机时,其就会产生核心转储文件,而且该文件一般都有几个G,因而如果不限制该文件的大小,那么很有可能会把服务器磁盘占满。该参数的作用就是限制核心转储文件的大小的。

  • 指定coredump文件生成目录

    working_directory path;

    该参数指定了在生成核心转储文件时,将该文件存放的目录。

1.2 正常运行的配置项
  • 定义环境变量

    env TESTPATH=/tmp/

    这个配置项可以让用户直接设置操作系统上的环境变量。

  • 嵌入其他配置文件

    include /path/file

    用于将其他的配置文件引入进来,该路径可以是绝对路径,也可以是相对路径,如果是相对路径,则是基于nginx的配置目录而指定的。

  • pid文件的路径

    pid path/file

    用于指定存储nginx的master进程运行所使用的进程id的文件的路径。

  • Nginx的worker进程运行的用户及用户组

    user username [groupName]

    用于指定worker进程运行时所基于的用户和用户组,默认都为nobody,这里如果不指定groupName,那么组名就与用户名一致。

  • 指定nginx的worker进程可以打开的最大句柄描述符个数

    worker_rlimit_nofile limit;

    设置一个worker进程能够打开的最大句柄描述符个数。

  • 限制信号队列

    worker_rlimit_sigpending limit;

    设置了每个用户能够发往nginx的信号队列的大小,如果信号队列已满,那么新发送的信号将会被丢弃。

1.3 优化性能的配置项
  • nginx的worker进程的个数

    worker_processes 1;

    用于指定nginx运行时worker进程的个数,在nginx运行时,每个worker进程都是单线程运行的,这里需要判断worker进程是否进行了阻塞性操作,如果有这样的操作,那么稍微多配置一些worker进程比较好,如果没有,那么将worker进程数量设置得与CPU数量一样能够得到更好的性能。

  • 绑定nginx的worker进程到指定的CPU内核

    worker_cpu_affinity cpumask [cpumask...]

    将worker进程与指定的CPU进行绑定,这样能够防止多个worker进程抢占同一个CPU,从而避免出现同步问题。如下是一个4核CPU的配置方式:

    worker_processes 4;
    worker_cpu_affinity 1000 0100 0010 0001;

    需要注意的是,worker_cpu_affinity仅对于Linux系统有效。

  • SSL硬件加速

    ssl_engine device;

    如果服务器上有SSL硬件加速设备,那么就可以进行配置以加快SSL协议的处理速度。用户可以使用OpenSSL提供的命令来查看是否有SSL硬件加速设备:

    openssl engine -t

  • 系统调用gettimeofday的执行频率

    timer_resolution -t

    默认情况下,每次内核的事件调用返回时,都会执行一次gettimeofday,在早期的Linux版本中,获取系统时间都会有一次从内核态到用户态的数据复制,其代价比较高,但是在最新的x86-64体系架构中,gettimeofday仅仅只是一次vsyscall,其仅仅只是对共享内存页中的数据的访问,代价不大。

  • nginx的worker进程优先级

    worker_priority nice;

    用于设置nginx的worker进程的优先级,其中,nice的默认值为0。在Linux操作系统中,当有多个进程在竞争CPU执行资源时,其就会根据每个进程设置的优先级来优先分配执行权限,并且所分配的时间片也要高一些。优先级的值在-20~+19之间,数值越低优先级越高,一般建议将nginx的优先级设置得更低一些,这样才能保证其执行的权限,但是建议不要设置得比内核的进程优先级(其值为-5)还要低。

1.4 事件类配置项
  • 是否打开accept锁

    accept_mutex [on|off]

    accept_mutex参数用于控制是否启用负载均衡锁,其默认值为on,该锁会保证各个worker轮流的、序列化的与新客户端建立连接,并且当某个worker的连接数达到了worker_connections配置的最大连接数的7/8时,该锁会降低该worker将要新建立的连接数,从而保证各个worker的负载均衡。

  • lock文件的路径

    lock_file path/file;

    该参数指定了lock文件的路径。nginx会使用操作系统提供的锁功能,但如果操作系统不支持原子锁,此时才会使用文件锁来实现lock。如果accept_mutex参数设置为off,那么该参数将不会生效。

  • 使用accept锁后到真正建立连接之间的延迟时间

    accept_mutex_delay Nms;

    如果一个worker进程尝试获取锁失败了,那么其就会等待该参数指定的时间段之后再次尝试获取锁,该值默认为500ms。

  • 批量建立新连接

    multi_accept [on|off];

    当事件模型通知此次有新的连接建立请求时,尽可能的对本次调度中客户端发起的的所有TCP请求都建立连接,该值默认为off。

  • 选择事件模型

    use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];

    nginx所选用的事件模型,其会自动使用最适合的模型。在Linux操作系统下支持poll、select和epoll三种,其中epoll的性能是最高的。

  • 每个worker的最大连接数

    worker_connections number;

    指定了每个worker进程能够建立的最大连接数。

2. http核心模块配置

2.1 监听端口
listen address:port[default(deprecated)|default_server|[backlog=num|rcvbuf=size|sndbuf=size|accept_filter=filter|deferred|bind|ipv6only=[on|off]|ssl]]
  • 这里的IP地址和端口号的配置非常灵活,如果不配置端口号,则默认为80端口,而ip地址则可以使用通配符进行匹配,如:

    listen 127.0.0.1:8080;
    listen *:8080;

  • listen的各个参数含义如下:

    • defaultdefault_server:将当前server块作为整个web服务器的默认server块,如果没有server设置了该参数,则将nginx.conf中的第一个server块作为默认server块。设置该参数的原因在于,如果当前请求没有匹配到任意一个server,那么就使用第一个server处理请求;

    • backlog=num:指定了TCP中的backlog队列的大小,默认值为-1。在TCP的三次握手过程中,进程此时还没有开始处理监听句柄,而这些请求都会放在backlog队列中,当backlog队列满时,客户端新的握手请求就会被拒绝;

    • rcvbuf=size:设置监听句柄的SO_RCVBUF参数;

    • sndbuf=size:设置监听句柄的SO_SNDBUF参数;

    • accept_filter:设置accept过滤器,只对FreeBSD操作系统有用;

    • deferred:如果设置了该参数,如果用户发起了TCP连接请求,那么在三次握手成功之后内核也不会调度相应的进程处理请求,而是在用户真正的发送了数据包之后才会将请求发送给具体的进程进行处理;

    • bind:绑定当前端口/地址对,如127.0.0.1:8000,只有同时对一个端口监听多个地址时才会生效;

    • ssl:在当前监听的端口上建立的连接必须基于SSL协议;

2.2 主机名称
语法:server_name name [...];
默认:server_name "";
配置块:server
  • server_name后可以跟多个主机名称,在处理HTTP请求时,其会将请求中的Host头部的主机名与server块中的主机名进行匹配,如果遇到多个server块中的主机名匹配,那么将会按照如下规则与其进行匹配:

    如果没有找到能够匹配的主机名,那么就会按照如下规则寻找server块:

    • 优先选择在listen项中加入了[default|default_server]的server块;

    • 找到匹配的listen端口的第一个server块;

    • 首先匹配主机名完全匹配的server块;

    • 然后匹配前缀使用通配符的server块;

    • 接着匹配后缀使用通配符的server块;

    • 最后匹配使用正则表达式的server块;、

2.3 server_names_hash_bucket_size
语法:server_names_hash_bucket_size size;
默认:server_names_hash_bucket_size 32|64|128;
配置块:http、server、location
  • server_names_hash_bucket_size的作用主要是进行server name的hash匹配的,在进行hash匹配时,该参数指定了hash表的每个bucket占用的内存大小。

2.4 server_names_hash_max_size
语法:server_names_hash_max_size size;
默认:server_names_hash_max_size 512;
配置块:http、server、location
  • server_names_hash_max_size指定了进行server name查找时使用的hash表的大小,该值越大,那么占用的内存越多,但是查询的效率也越高。

2.5 重定向主机名称的处理
语法:server_name_in_redirect on|off;
默认:server_name_in_redirect on;
配置块:http、server或者location
  • 该配置需要配合server_name使用,在使用on打开时,表示在重定向请求时,会使用server_name里配置的第一个主机名代替原来请求中的Host头部,而使用off关闭时,表示在重定向请求时使用请求本身的Host头部。

2.6 location
语法:location [=|~|~*|^~|@] /uri/{...}
配置块:server
  • location的主要作用是与请求中的URI进行匹配,如果匹配了,就使用location块中的配置来处理用户请求。如下是location的匹配规则:

    • =表示把URI作为字符串,以便于参数中的uri做完全匹配。例如:

      location = / {
        # 只有当用户请求是/时,才会使用该location下的配置
      }

    • ~表示匹配URI时是字母大小写敏感的;

    • ~*表示匹配URI时是字母大小写不敏感的;

    • ^~表示匹配URI时只需要其前半部分与uri参数匹配即可。例如:

      location ^~ /images/ {
        # 以/images/开始的请求都会匹配上
      }

    • @表示仅用于nginx服务内部请求之间的重定向,带有@的location不直接处理用户请求;

    • 可以在uir参数里使用正则表达式。如:

      location ~* \.(gif|jpg|jpeg)$ {
        # 匹配以.gif、.jpg、.jpeg结尾的请求
      }

  • 关于location的匹配需要说明的一点是,location的匹配是有顺序的,当一个请求匹配了多个location时,实际上这个请求会被第一个location处理。

3. 文件路径的定义

3.1 以root方式设置资源路径
语法:root path;
默认:root html;
配置块:http、server、locationo、if
  • 示例如下:

    location /download/ {
      root /opt/web/html/;
    }

    这种配置方式会将/download/开始的请求映射到/opt/web/html/目录下,比如某个请求为/download/test/index.html,那么nginx就会到服务器上查找/opt/web/html/download/test/index.html文件。

3.2 以alias方式设置资源文件
语法:alias path;
配置块:location;
  • root一样,alias也是配置资源文件路径的,但是alias是location后的路径以别名的方式替换目标路径的指定部分,比如如下配置:

    location /conf {
      alias /usr/local/nginx/conf;
    }

    此时如果一个请求为/conf/index.html,那么其前缀/conf将会与当前location匹配,并且会将alias参数替换请求uri中匹配的部分,也就是转换后的uri为/usr/local/nginx/conf/index.html。

3.3 访问首页
语法:index file...;
默认:index index.html;
配置块:http、server、location
  • 该配置块的主要作用是将用户访问的某个地址映射到首页,在进行首页查找时,会按照顺序查询index参数后的文件,如果存在,则将其返回,如果不存在,则继续查找下一个。比如如下示例:

    location / {
      root path;
      index /index.html /html/index.php /index.php
    }

    当接收到用户的/请求后,其首先会查询/path/index.html文件是否存在,如果不存在,则查询下一个/path/html/index.php是否存在,如果存在,则直接返回,依此类推。

3.4 根据http返回码重定向页面
语法:error_page code[code...][=|=answer-code]uri|@named_location
配置块:http、server、location、if
  • 该配置的主要作用是,如果当前请求返回了指定的状态码,那么就将其重定向到后面的错误页面。如:

    error_page 404 /404.html
    error_page 502 503 504 /50x.html
    error_page 403 http://example.com/forbidden.html
    error_page 404 = @fetch;

    需要注意的是,即使重定向了URI,返回的HTTP状态码还是原来的状态码,如果需要修改状态码,可以使用=来修改原来的状态码,如:

    error_page 404 =200 /empty.gif;
    error_page 404 =403 /forbidden.gif;

    也可以不指定修改后的状态码,而是由重定向后的请求决定其返回的状态码:

    error_page 404 = /empty.gif;

    在重定向后,也可以不修改URI,而是将这个请求重定向到另一个location中进行处理,比如:

    location / {
      error_page 404 @fallback;
    }
    
    location @fallback {
      proxy_pass http://backend;
    }

3.5 是否支持递归的使用error_page
语法:recursive_error_pages [on|off];
默认:recursive_error_pages off;
配置块:http、server、location;
  • 该配置主要用于控制是否支持递归的定义error_page。

3.6 try_files
语法:try_files path2[path3]uri;
配置块:server、location
  • 该参数的主要作用是在用户请求到达之后,会依次尝试其后指定的各个path路径,如果匹配上了,那么就将该路径的值直接返回。如果都没有匹配上,那么就会使用最后的uri作为默认处理路径。示例如:

    try_files /system/maintenance.html $uri $uri/index.html $uri.html @other
    location @other {
      proxy_pass http://backend;
    }

4. 内存及磁盘资源的分配

4.1 http包体只存储到磁盘文件中
语法:client_body_in_file_only on|clean|off;
默认:client_body_in_file_only off;
配置块:http、server、location
  • 当值配置为非off时,用户请求的http包体一律存储到磁盘文件中,即使只有0字节也会存储为文件。当请求结束时,如果配置为on,则这个文件不会被删除,如果配置为clean,则会删除该文件。

4.2 http包体尽量写入到一个内存buffer中
语法:client_body_in_single_buffer on|off;
默认:client_body_in_single_buffer off;
配置块:http、server、location
  • 用户请求的http包体一律存储到内存buffer中,如果存储的包体大小超过了client_body_buffer_size指定的大小,那么该请求还是会存储到磁盘文件中。

4.3 存储http头部的内存buffer大小
语法:client_header_buffer_size size;
默认:client_header_buffer_size 1k;
配置块:http、server
  • 该参数指定了用户请求的http头部的size大小,如果请求头部大小超过了该数值,那么就会将请求就会交由large_client_header_buffers参数定义的buffer处理。

4.4 存储超大http头部的内存buffer大小
语法:large_client_header_buffers number size;
默认:large_client_header_buffers 48k;
配置块:http、server
  • 该参数主要是在用户的请求头部信息超过了client_header_buffer_size所能存储的大小时使用,该参数定义了每个header所能传输的数据的大小,以及最多能够传输多少个header。如果单个header大小超限,则会返回414(Request URI too large)状态码,如果是header个数超限,则会返回400(Bad Request)状态码。

4.5 存储http包体的内存buffer的大小
语法:client_body_buffer_size size;
默认:client_body_buffer_size 8k/16k;
配置块:http、server、location
  • 该参数指定了nginx接收用户http请求的包体buffer的大小,如果超过了该大小,那个请求包体将会存储到磁盘文件中。

  • 需要注意的是,如果用户请求的header中包含Content-Length,并且其标识的长度小于上述参数指定的长度,那么就会自动降低此次请求所使用的buffer大小。

4.6 http包体的临时存放目录
语法:client_body_temp_path dir-path[level1[level2[level3]]]
默认:client_body_temp_path client_body_temp;
配置块:http、server、location
  • 该参数的主要作用是指定了存储http包体的磁盘目录,后面的level表示可以有几级子目录,这是因为如果请求比较多,那么生成的文件就会比较多,频繁的访问同一个目录可能会降低性能,因而可以设置多级子目录用于文件的存放;

  • 需要注意的是,上述level参数表示的是所生成的目录名占有目标文件名字符的个数,比如生成的目标文件名为00000123456,而上述参数按如下配置:

    client_body_temp_path /opt/nginx/client_temp 1 2;

    那么nginx就会截取目标文件名的最后1个字符作为一级目录,倒数第二个和第三个总共两个字符作为二级目录,最终文件将会存储在如下目录:

    /opt/nginx/client_temp/6/45/00000123456

  • nginx在生成目标文件时,其文件名是以顺序递增的整数进行命名的。

4.7 connection_pool_size
语法:connection_pool_size size;
默认:connection_pool_size 256;
配置块:http、server
  • 该参数指定了nginx为每个建立成功的TCP连接预先分配的内存池大小,size指定的是预先分配的内存池大小。

  • 该参数需要谨慎配置,因为更大的配置将会消耗服务器更多的内存,而更小的配置将会导致服务器为了扩容而进行更多次的内存分配。

4.8 request_pool_size
语法:request_pool_size size;
默认:request_pool_size 4k;
配置块:http、server
  • nginx在接收到每个http请求时,都会为其申请一个内存池,该参数指定了该内存池的大小,需要注意的是,该内存池本质上就是从上面介绍的connection_pool_size内存池中进行申请;

  • 在每次http请求结束时,其就会销毁该请求申请的内存池,而将其返还给connection_pool_size内存池,而只有在此次TCP连接关闭时才会销毁整个连接的内存池。

5. 网络连接的设置

5.1 读取http头部的超时时间
语法:client_header_timeout time(默认单位:秒);
默认:client_header_timeout 60;
配置块:http、server、location
  • 在客户端与服务器建立连接之后,nginx会读取客户端发来的http头部,如果超过该参数指定的时间还未读取到客户端发来的字节,就会认为其超时了,此时就会向客户端返回408(Request timed out)状态码。

5.2 读取http包体的超时时间
语法:client_body_timeout time(默认单位:秒);
默认:client_body_timeout 60;
配置块:http、server、location
  • 该参数主要作用是指定nginx读取请求包体的超时时间。

5.3 发送响应的超时时间
语法:send_timeout time;
默认:send_timeout 60;
配置块:http、server、location
  • 这个参数主要指定了nginx向客户端发送响应的超时时间,如果客户端一直没有尝试接收数据,那么nginx就会关闭这个连接。

5.4 reset_timeout_connection
语法:reset_timeout_connection on|off;
默认:reset_timeout_connection off;
配置块:http、server、location
  • 如果开启了该参数,在连接超时后,nginx会向客户端发送RST包来直接重置连接,并且会释放服务器上关于该连接的所有缓存数据(如TCP滑动窗口等)。相比于正常关闭的方式,它使得服务器能够避免产生许多处于FIN_WAIT_1FIN_WAIT_2TIME_WAIT状态的TCP连接。

  • 需要注意的是,使用RST重置包关闭连接会带来一些问题,默认情况下不会开启。

5.5 lingering_close
语法:lingering_close off|on|always;
默认:lingering_close on;
配置块:http、server、location
  • 该配置块控制nginx关闭用户连接的方式。always表示关闭用户连接前必须无条件的处理连接上所有用户发送的数据。off表示关闭连接时完全不管连接上是否有用户准备就绪的数据。on是中间值,一般情况下在关闭连接前都会处理连接上的用户发送的数据,除非某些时候业务上认定这些数据是不需要的,此时就会抛弃这些数据。

5.6 lingering_time
语法:lingering_time time;
默认:lingering_time 30s;
配置块:http、server、location
  • lingering_close启用后,这个配置项主要是针对大文件的传输用的,比如当某个请求传输的数据超过了max_client_body_size时,nginx就会向该客户端发送413(Request entity too large)状态码,但是某些客户端可能不会理会该状态码而还是继续向服务器发送数据,此时nginx就会在该参数的超时时间之后直接关闭该连接。

5.7 lingering_timeout
语法:lingering_timeout time;
默认:lingering_timeout 5s;
配置块:http、server、location
  • lingering_close启用后,nginx在关闭连接前,会检测用户连接上是否还有未处理的数据,如果在该参数指定的时间之后还没有相应的数据到达,那么就会关闭该链接。

5.8 对某些浏览器禁用keepalive功能
语法:keepalive_disable [msie6|safari|none]...
默认:keepalive_disablemsie6 safari
配置块:http、server、location
  • 该参数主要是指定对哪些浏览器禁用keepalive功能,keepalive会在客户端与服务器之间建立一个长连接,这对于发送多个http请求是非常有用的,但是对于IE6和以前版本,还有Safari浏览器在处理POST请求时会有功能性问题,因而对于这些浏览器默认是禁用的。

5.9 keepalive超时时间
语法:keepalive_timeout time(默认单位:秒);
默认:keepalive_timeout 75;
配置块:http、server、location
  • 该参数主要是在一个keepalive连接在指定时长内没有接收到新的请求时,将会关闭该连接。

5.10 keepalive长连接上能够承载的最大请求数
语法:keepalive_requests n;
默认:keepalive_requests 100;
配置块:http、server、location
  • 该参数指定了一个keepalive长连接上能够承载的最大连接数,默认为100。

5.11 tcp_nodelay
语法:tcp_nodelay on|off;
默认:tcp_nodelay on;
配置块:http、server、location
  • 确定对keepalive连接是否使用TCP_NODELAY选项

5.12 tcp_nopush
语法:tcp_nopush on|off;
默认:tcp_nopush off;
配置块:http、server、location
  • 在打开sendfile选项时,确定是否开启FreeBSD系统上的TCP_NOPUSH或者Linux系统上的TCP_CORK功能。打开tcp_nopush后,将会在发送响应时把整个响应包头放到一个TCP包中发送。

6. MIME类型的设置

6.1 MIME type与文件扩展的映射
语法:type {...};
配置块:http、server、location
  • 该配置项定义了MIME type到文件扩展名的映射。多个扩展名可以映射到同一个MIME type。例如:

    types {
      text/html html;
      text/html conf;
      image/gif gif;
      image/jpeg jpg;
    }

6.2 默认MIME type
语法:default_type MIME-type;
默认:default_type text/plain;
配置块:http、server、location
  • 当找不到相应的MIME type与文件扩展名之间的映射时,使用默认的MIME type作为http header的Content-Type

6.3 types_hash_bucket_size
语法:types_hash_max_size size;
默认:types_hash_max_size 1024;
配置块:http、server、location
  • nginx使用了一个散列表来保存MIME type与文件扩展名之间的映射,该参数就是指定该散列表桶的大小的。

6.4 types_hash_max_size
语法:types_hash_max_size size;
默认:types_hash_max_size 1024;
配置块:http、server、location
  • 该参数指定了存储MIME type与文件扩展名的散列的最大大小,该值越大,散列的key就越稀疏,检索速度越快,但是会占用更多的内存;该值越小,占用的内存越小,但是冲突率就会上升,检索越慢。

7. 对客户端请求的限制

7.1 按http方法名限制用户请求
语法:limit_except method...{...}
配置块:location
  • 该配置项的主要作用是限制某些方法的请求的访问,后面的参数可取GET、HEAD、POST、DELETE、MKCOL、COPY、MOVE、OPTIONS、PROPFIND、PROPPATCH、LOCK、UNLOCK或者PATCH。示例如:

    limit_except GET {
      allow 192.168.1.0/32;
      deny all;
    }

    上述配置将会限制所有的GET请求的访问,而允许其他方法的请求。

7.2 http请求包体的最大值
语法:client_max_body_size size;
默认:client_max_body_size 1m;
配置块:http、server、location
  • 该参数指定了http请求的最大包体的大小,nginx会根据请求header中的Content-Length所表示的长度来判断其与当前参数是否符合,如果不符合,则直接返回给客户端413(Request too large)状态码。

7.3 对请求的限速
语法:limit_rate speed;
默认:limit_rate 0;
配置块:http、server、location、if
  • 该配置主要是对客户端的请求进行每秒传输的字节大小进行限速,默认为0,表示不限速;

  • 针对不同的客户端,可以使用$limit_rate参数执行不同的限速策略。如:

    server {
      if ($slow) {
        set $limit_rate 4k;
      }
    }

7.4 limit_rate_after
语法:limit_rate_after time;
默认:limit_rate_after 1m;
配置块:http、server、location、if
  • 该参数表示nginx向客户端发送的响应大小超过limit_rate_after指定的值之后才开始限速。

8. 文件操作的优化

8.1 sendfile系统调用
语法:sendfile on|off;
默认:sendfile off;
配置块:http、server、location
  • 该参数用于打开Linux上的sendfile系统调用,在发送数据到网卡上时,它减少了两次在用户态与内核态之间的数据拷贝过程,而直接在磁盘读取数据之后发送到网卡上,从而提升数据发送效率。

8.2 AIO系统调用
语法:aio on|off;
默认:aio off;
配置块:http、server、location
  • 该参数指定了是否在FreeBSD或Linux系统上启动内核级别的异步文件I/O功能,需要注意的是,其与sendfile功能是互斥的。

8.3 directio
语法:directio size|off;
默认:directio off;
配置块:http、server、location
  • 该配置项在FreeBSD和Linux系统上使用O_DIRECT选项去读取文件,缓冲区大小为size,通常对大文件的读取速度有优化作用。注意,它与sendfile指令是互斥的。

8.4 directio_alignment
语法:directio_alignment size;
默认:directio_alignment 512;
配置块:http、server、location
  • 它与directio配合使用,指定以directio方式读取文件时的对其方式。一般情况下,512B已经足够了,但对于一些高性能文件系统,如Linux下的XFS文件系统,可能需要设置4KB作为对齐方式。

8.5 打开文件缓存
语法:open_file_cache max=N[inactive=time]|off;
默认:open_file_cache off;
配置块:http、server、location
  • 文件缓存会在内存中存储以下三种信息:

    • 文件句柄、文件大小和上次修改时间;

    • 已经打开过的目录结构;

    • 没有找到的或者没有权限操作的文件信息;

  • 上面的配置项的三个参数的含义如下:

    • max:表示内存中存储元素的最大个数。当达到最大限制数量后,将采用LRU算法从缓存中淘汰最近最少使用的元素;

    • inactive:表示在inactive指定的时间段内没有被访问过的元素将会被淘汰。默认时间为60秒;

    • off:关闭缓存功能。

  • 示例如下:

    open_file_cache max=1000 inactive=20s;

8.6 是否缓存打开文件错误的信息
语法:open_file_cache_errors on|off;
默认:open_file_cache_errors off;
配置块:http、server、location
  • 该配置项表示是否对打开文件时找不到文件或者权限错误等信息进行缓存。

8.7 不被淘汰的最小访问次数
语法:open_file_cache_min_uses number;
默认:open_file_cache_min_uses 1;
配置块:http、server、location
  • 该参数与open_file_cache配合使用,如果在指定时间内访问该文件的次数小于该参数指定的次数,那么该文件还是会被淘汰。

8.8 检验缓存中元素有效性的频率
语法:open_file_cache_valid time;
默认:open_file_cahce_valid 60s;
配置块:http、server、location
  • 该参数指定了每间隔多长时间检查一下缓存中数据的有效性,默认为60秒。

9. 对客户端请求的特殊处理

9.1 忽略不合法的http头部
语法:ignore_invalid_headers on|off;
默认:ignore_invalid_headers on;
配置块:http、server
  • 如果将其设置为off,那么当客户端请求中有不合法的header时,就会直接响应400(Bad Request);如果将其设置为on,那么就会忽略此header。

9.2 http头部是否允许下划线
语法:underscores_in_headers on|off;
默认:underscores_in_headers off;
配置块:http、server
  • 该参数指定了http头部中是否能够带有下划线,默认是不允许。

9.3 对If-Modified-Since头部的处理策略
语法:if_modified_since [off|exact|before];
默认:if_modified_since exact;
配置块:http、server、location
  • If-Modified-Since头部主要是浏览器处于性能考虑而作的一个缓存策略,浏览器在请求过一份文件之后,会将该文件在本地缓存,并记录缓存时间,在下次请求时会在If-Modified-Since头部中带上上次缓存的时间,服务器在接收到该请求时,会将服务器文件的修改时间与请求中的时间进行比较,如果文件在这之后有过修改,那么服务器就会正常的返回文件内容以及200状态码,如果文件没有修改过,那么说明浏览器中缓存的文件是最新的,此时就会返回304(Not Modified)状态码。

  • 该配置参数有三个选项,其含义分别如下:

    • off:表示忽略用户请求中的If-Modified-Since头部,在每次请求时都将文件内容返回,此时响应状态码为200;

    • exact:将If-Modified-Since头部包含的时间与将要返回的文件的上次修改时间做精确比较,如果没有匹配上,则返回200和文件的实际内容,如果匹配上了,则表示文件内容已经是最新的,此时就会返回304(Not Modified)状态码,浏览器收到后会直接读取本地缓存;

    • before:这个是比exact更宽松的策略,只要文件的上次修改时间在用户请求的If-Modified-Since头部指定的时间之前,那么就会向客户端返回304(Not Modified)状态码。

9.4 文件未找到时是否返回error日志
语法:log_not_found on|off;
默认:log_not_found on;
配置块:http、server、location
  • 该配置的主要作用在于,当用户请求某个文件时,如果该文件不存在,是否将这条信息记录在error日志中,主要用于定位问题。

9.5 merge_slashes
语法:merge_slashes on|off;
默认:merge_slashes on;
配置块:http、server、location
  • 该配置项表示是否合并相邻的/,例如//test///a.txt,在配置为on时,会将其匹配为location/test/a.txt;如果配置为off,则不会匹配,URI将仍然是//test///a.txt

9.6 DNS解析地址
语法:resolver address...;
配置块:http、server、location
  • 设置DNS名字解析服务器的地址,如:

    resolver 127.0.0.1 192.0.2.1;

9.7 DNS解析的超时时间
语法:resolver_timeout time;
默认:resolver_timeout 30s;
配置块:http、server、location
  • 次配置项表示DNS解析的超时时间

9.8 返回错误页面时是否在server中注明nginx版本
语法:server_tokens on|off;
默认:server_tokens on;
配置块:http、server、location
  • 表示在返回错误页面时是否在Server头部中返回具体的nginx版本,这主要是为了定位问题方便。

感谢各位的阅读,以上就是“Nginx的基本属性配置”的内容了,经过本文的学习后,相信大家对Nginx的基本属性配置这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!


本文名称:Nginx的基本属性配置
文章起源:http://scyanting.com/article/jsoiso.html