ngixn的配置

• 运行中的Nginx进程间的关系
• • master进程的作用
  • worker进程
• Nginx服务的基本配置
• • 用于调试进程和定位问题的配置项
  • 正常运行的配置项
  • 优化性能的配置项
  • event 事件类配置项
• 用HTTP核心模块配置一个静态Web服务器
• • 虚拟主机与请求的分发
  • 文件路径的定义
  • 内存及磁盘资源的分配
  • 网络连接的设置
  • MIME类型的设置
  • 对客户端请求的限制
  • 文件操作的优化
  • 对客户端请求的特殊处理
• 用HTTP proxy module配置一个反向代理服务器
• • 负载均衡的基本配置
  • 反向代理的基本配置

运行中的Nginx进程间的关系

在正式提供服务的产品环境下，部署Nginx时都是使用一个master进程来管理多个worker 进程，一般情况下，worker进程的数量与服务器上的CPU核心数相等。每一个worker进程都是工作的，它们在提供互联网服务，master进程则只有一个任务，那就是负责监控管理worker 进程。worker进程之间通过共享内存、原子操作等一些进程间通信机制来实现负载均衡等功能。

master进程的作用

由于master进程不会对用户请求提供服务，只用于管理真正提供服务的worker进程， 所以master进程可以是唯一的，它仅专注于自己的管理工作，为管理员提供命令行服务， 包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等。master进程需要拥有较大 的权限，例如，通常会利用root用户启动master进程。worker进程的权限要小于或等于master 进程，这样master进程才可以完全地管理worker进程。当任意一个worker进程出现错误从而导致coredump时，master进程会立刻启动新的worker进程继续服务。

worker进程

多个worker进程处理互联网请求不但可以提高服务的健壮性(一个worker进程出错后，其他worker进程仍然可以正常提供服务)，最重要的是，这样可以充分利用现在常见的SMP多核架构，从而实现微观上真正的多核并发处理。因此，用一个进程(master进程)来处理互联网请求肯定是不合适的。另外，为什么要把worker进程数量设置得与CPU核心数量一致呢？这正是Nginx与Apache服务器的不同之处。在Apache上每个进程在一个时刻只处理一个请求，因此，如果希望Web服务器拥有并发处理的请求数更多，就要把Apache的进程或线程数设置得更多，通常会达到一台服务器拥有几百个工作进程，这样大量的进程间切换将带来无谓的系统资源消耗。而Nginx则不然，一个worker进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的worker进程之间处理并发请求时几乎没有同步锁的限制，worker进程通常不会进入睡眠状态，因此，当Nginx上的进程数与CPU核心数相等时（最好每一个worker进程都绑定特定的CPU核心），进程间切换的代价是最小的。
在这里插入图片描述

Nginx服务的基本配置

用于调试进程和定位问题的配置项

1. 是否以守护进程方式运行Nginx
   语法: daemon on|off;
   默认: daemon on;
   守护进程(daemon)是脱离终端并且在后台运行的进程。脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务，因此，默认都是以这种方式运行的。
   不过Nginx还是提供了关闭守护进程的模式，之所以提供这种模式，是为了方便跟踪调 试Nginx，毕竟用gdb调试进程时最烦琐的就是如何继续跟进fork出的子进程了。

2. 是否以master/worker方式工作
   语法: master_process on|off;
   默认: master_process on;

3. error日志的设置
   语法: error_logpathfile level;
   默认: error_log logs/error.log error;

4. 是否处理几个特殊的调试点
   语法: debug_points[stop|abort]
   这个配置项也是用来帮助用户跟踪调试Nginx的。它接受两个参数:stop和abort。通常不会使用这个配置项。

5. 仅对指定的客户端输出debug级别的日志
   语法: debug_connection[IP|CIDR]
   这个配置项实际上属于事件类配置，因此，它必须放在events{…}中才有效。它的值可 以是IP地址或CIDR地址。

6. 限制coredump核心转储文件的大小
   语法: worker_rlimit_core size;

7. 指定coredump文件生成目录
   语法: working_directory path;

正常运行的配置项

1. 定义环境变量
   语法: env VAR|VAR=VALUE
   这个配置项可以让用户直接设置操作系统上的环境变量
2. 引入其他配置文件
   语法: include pathfile;
   include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中，它的参数既可以是绝 对路径，也可以是相对路径(相对于Nginx的配置目录，即nginx.conf所在的目录)
3. pid文件的路径
   语法: pid path/file;
   默认: pid logs/nginx.pid;
4. Nginx worker进程运行的用户及用户组
   语法: user username[groupname];
5. 设置一个worker进程可以打开的最大文件句柄数。
   语法: worker_rlimit_nofile limit;
6. 限制信号队列
   语法: worker_rlimit_sigpending limit;
   设置每个用户发往Nginx的信号队列的大小。也就是说，当某个用户的信号队列满了，
   这个用户再发送的信号量会被丢掉。

优化性能的配置项

• Nginx worker进程个数
  语法: worker_processes number;
  默认: worker_processes 1;
  在master/worker运行方式下，定义worker进程的个数。
  worker进程的数量会直接影响性能。那么，用户配置多少个worker进程才好呢?这实际 上与业务需求有关。
  每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果 这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程;反 之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。
  多worker进程可以充分利用多核系统架构，但若worker进程的数量多于CPU内核数，那 么会增大进程间切换带来的消耗(Linux是抢占式内核)。一般情况下，用户要配置与CPU内 核数相等的worker进程，并且使用worker_cpu_affinity配置来绑定CPU内核。
• 绑定Nginx worker进程到指定的CPU内核
  语法: worker_cpu_affinity cpumask[cpumask…]
  为什么要绑定worker进程到指定的CPU内核呢？假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个 worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。
  例如：

worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;

注意 worker_cpu_affinity配置仅对Linux操作系统有效。Linux操作系统使用 sched_setaffinity()系统调用实现这个功能。

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

openssl engine -t

• 系统调用gettimeofday的执行频率
  语法: timer_resolution t;
  默认情况下，每次内核的事件调用(如epoll、select、poll、kqueue等)返回时，都会执 行一次gettimeofday，实现用内核的时钟来更新Nginx中的缓存时钟。
• Nginx worker进程优先级设置
  语法: worker_priority nice;
  默认: worker_priority 0;
  该配置项用于设置Nginx worker进程的nice优先级。

event 事件类配置项

• 是否打开accept锁
  语法: accept_mutex[on|off]
  默认: accept_mutext on;
  当一个新连接到达时，如果激活了accept_mutex，那么多个Worker将以串行方式来处理，其中有一个Worker会被唤醒，其他的Worker继续保持休眠状态；如果没有激活accept_mutex，那么所有的Worker都会被唤醒，不过只有一个Worker能获取新连接，其它的Worker会重新进入休眠状态，这就是「惊群问题」
• lock文件的路径
  语法: lock_file path/file;
  默认: lock_file logs/nginx.lock;
  accept锁可能需要这个lock文件，如果accept锁关闭，lock_file配置完全不生效。
• 使用accept锁后到真正建立连接之间的延迟时间
  语法: accept_mutex_delay Nms;
  默认: accept_mutex_delay 500ms;
• 批量建立新连接
  语法: multi_accept[on|off];
  默认: multi_accept off;
  当事件模型通知有新连接时，尽可能地对本次调度中客户端发起的所有TCP请求都建立 连接。
• 选择事件模型
  语法: use[kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
  默认: Nginx会自动使用最适合的事件模型。
  对于Linux操作系统来说，可供选择的事件驱动模型有poll、select、epoll三种。epoll当 然是性能最高的一种，在9.6节会解释epoll为什么可以处理大并发连接。
• 每个worker的最大连接数
  语法: worker_connections number;
  定义每个worker进程可以同时处理的最大连接数。

用HTTP核心模块配置一个静态Web服务器

静态Web服务器的主要功能由ngx_http_core_module模块(HTTP框架的主要成员)实现， 当然，一个完整的静态Web服务器还有许多功能是由其他的HTTP模块实现的。
所有的HTTP配置项都必须直属于http块、server块、location块、upstream块或if块等 (HTTP配置项自然必须全部在http{}块之内，这里的“直属于”是指配置项直接所属的大括号 对应的配置块)，同时，在描述每个配置项的功能时，会说明它可以在上述的哪个块中存 在，因为有些配置项可以任意地出现在某一个块中，而有些配置项只能出现在特定的块中。
Nginx为配置一个完整的静态Web服务器提供了非常多的功能，下面会把这些配置项分为以下8类进行详述:虚拟主机与请求的分发、文件路径的定义、内存及磁盘资源的分配、网络连接的设置、MIME类型的设置、对客户端请求的限制、文件操作的优化、对客户端请求的特殊处理。

虚拟主机与请求的分发

由于IP地址的数量有限，因此经常存在多个主机域名对应着同一个IP地址的情况，这时 在nginx.conf中就可以按照server_name(对应用户请求中的主机域名)并通过server块来定义 虚拟主机，每个server块就是一个虚拟主机，它只处理与之相对应的主机域名请求。这样， 一台服务器上的Nginx就能以不同的方式处理访问不同主机域名的HTTP请求了。

• 监听端口
  语法: listen port
  默认 80
  配置块: server

• backlog=num ：表示TCP中backlog队列的大小。默认为–1，表示不予设置。在TCP建 立三次握手过程中，进程还没有开始处理监听句柄，这时backlog队列将会放置这些新连接。 可如果backlog队列已满，还有新的客户端试图通过三次握手建立TCP连接，这时客户端将会 建立连接失败。

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

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

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

• deferred:在设置该参数后，若用户发起建立连接请求，并且完成了TCP的三次握手， 内核也不会为了这次的连接调度worker进程来处理，只有用户真的发送请求数据时(内核已 经在网卡中收到请求数据包)，内核才会唤醒worker进程处理这个连接。这个参数适用于大 并发的情况下，它减轻了worker进程的负担。当请求数据来临时，worker进程才会开始处理 这个连接。只有确认上面所说的应用场景符合自己的业务需求时，才可以使用deferred配置。

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

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

• 主机名称
  server_name name[…];
  默认: server_name"";
  配置块: server
  server_name后可以跟多个主机名称，如server_name www.a.com、 www.b.com;
  在开始处理一个HTTP请求时，Nginx会取出header头中的Host，与每个server中的 server_name进行匹配，以此决定到底由哪一个server块来处理这个请求。有可能一个Host与 多个server块中的server_name都匹配，这时就会根据匹配优先级来选择实际处理的server块。 server_name与Host的匹配优先级如下:
  1)首先选择所有字符串完全匹配的server_name，如www.a.com
  2)其次选择通配符在前面的server_name，如*.a.com
  3)再次选择通配符在后面的server_name，如www.a.* 。
  4)最后选择使用正则表达式才匹配的server_name，如~^.testweb.com$。
  如果Host与所有的server_name都不匹配，这时将会按下列顺序选 择处理的server块。
  1)优先选择在listen配置项后加入[default|default_server]的server块
  2)找到匹配listen端口的第一个server块
  如果server_name后跟着空字符串(如server_name""