解剖nginx服务器架构

模块化结构的思想是一个很久的概念，但也正是成熟的思想造就了Nginx的巨大优越性。

我们知道Nginx从总体上来讲是有许多个模块构成的。习惯将Nginx分为5大模块分别为：核心模块，标准HTTP模块，可选HTTP模块，邮件服务模块和第三方模块。

这5个模块由上到下重要性一次递减。

（1）核心模块；

核心模块是Nginx服务器正常运行必不可少的模块，如同操作系统的内核。它提供了Nginx最基本的核心服务。像进程管理、权限控制、错误日志记录等；

（2）标准HTTP模块；

标准HTTP模块支持标准的HTTP的功能；

（3）可选HTTP模块；

可选HTTP模块主要用于扩展标准的HTTP功能，让Nginx能处理一些特殊的服务；

（4）邮件服务模块；

邮件服务模块主要用于支持Nginx的邮件服务；

（5）第三方模块；

第三方模块是为了扩展Nginx服务器应用，完成开发者想要的功能；

*******Nginx中的模块命名有自己的习惯*********

一般以Ngx_作为前缀，——module作为后缀，中间使用一个或者多个英文单词描述模块的工能，例如Ngx_core_module表示该模块提供Nginx的核心功能等；

具体各个模块中包含哪些模块可以自己去源码中查询，这里略过；

从架构设计上说，Nginx服务器是与众不同的。其一在于它的模块化设计；其二也是更重要的一点在于它对与客户端请求的处理机制上；

web服务器和客户端是一对多的关系，Web服务器必须有能力同时为多个客户端提供服务。一般来说完成并行处理请求工作有三种方式：

1.多进程方式；

2.多线程方式；

3.异步方式；

这里简单说明一下这三种方式：

（1）多进程方式

多进程方式指，服务器每当收到一个客户端时。就有服务器主进程生成一个子进程出来和客户端建立连接进行交互。指导连接断开。该子进程就结束了。

多进程方式的优点是设计简单，各个子进程相对独立，处理客户端请求时彼此不受干扰；缺点是操作系统生成一个子进程需要进行内存复制等操作，在资源和时间上会产生一定的开销；当有大量请求时，会导致系统性能下降；

（2）多线程方式

多线程方式指每当服务器接收到一个请求后，会由服务器主进程派生出一个线程出来和客户端进行交互。由于操作系统产生出一个线程的开销远远小于一个进程的开销。故多线程方式在很大程度上减轻了Web服务器对系统资源的要求。但同时由于多个线程位于一个进程内，可以访问同样的内存空间。所以需要开发者自己对内存进程管理，增大了难度。

（3）异步方式

异步方式适合多进程和多线程完全不同的一种处理客户端请求的方式。这里有几个概念我们需要熟悉一下： 同步，异步，阻塞，非阻塞 ；

在网络通信中同步和异步是描述通信模式的概念。

同步：发送方发送完请求后，需要等待接收到接收方发回的响应，才能发送下一个请求；所有请求在服务端得到同步，发送方和接收方的步调是一致的；

异步 ：和同步机制相反，在异步机制中，发送方发出一个请求后，不等接收方响应这个请求，就继续发送下一个请求；所有来自发送方的请求形成一个队列，接收方处理完成后通知发送方；

在进程处理调度方式上用阻塞与非阻塞。在网络通信中主要指套接字socket的阻塞和非阻塞，而socket的实质就是IO操作。

阻塞 ：调用结果返回之前，当前线程从运行状态被挂起，一直等到调用结果返回之后，才进入就绪状态，获取CPU后继续执行。

非阻塞 ：和阻塞方式正好相反，如果调用结果不能马上返回，当前线程也不会马上返回，而是立即返回执行下一个调用。

因此就衍生出4中方式：同步阻塞，同步非阻塞，异步阻塞，异步非阻塞

这里简单解释一下异步非阻塞：发送方向接收方发送请求后，不用等待响应，可以继续其他工作；接收方处理请求时进行的IO操作如果不能马上得到结果，也不必等待，而是马上返回去去做其他事情。当IO操作完成以后，将完成状态和结果通知接收方，接收方再响应发送方。

与此同时Nginx服务器处理请求是怎样的呢？？？

Nginx服务器的一个显著的优势就是能够同时处理大量的并发请求。它结合多进程机制和异步机制。异步机制使用的是异步非阻塞方式。（Master-Worker)。

每个工作进程使用异步非阻塞方式，可以处理多个客户端请求。当某个工作进程接收到客户端的请求以后，调用IO进行处理，如果不能立即得到结果，就去处理其他的请求；而客户端在此期间也无需等待响应，可以去处理其他事情；当IO返回时，就会通知此工作进程；该进程得到通知，暂时挂起当前处理的失误去响应客户端请求。

也就是：

Nginx采用异步非阻塞方式来处理请求，处理请求具体到系统底层就是读写事件（所谓阻塞调用方式即请求事件还没准备好，线程只能一直去等，等事件准备好了再处理；而非阻塞即事件没准备好，马上返回ENGAIN,告诉你事件还没准准备好，而在这期间可以先去做其他事，再回头看看事件准备好了吗，时不时会看，需要的开销也是不小的）

异步可以理解为循环处理多个准备好的事件，不会导致无谓的资源浪费，当有更多的并发数只会占用更多的内存而已

从上面我们可以知道，Nginx服务器的工作进程调用IO后，就取进行其他工作了；当IO调用返回后，会通知工作进程。 但IO调用时如何把自己的状态通知给工作进程的呢？？

一般解决这个问题有两种方法：

（1）让工作进程在进行其他工作的过程中间隔一段时间就去检查一下IO的状态，如果完成就响应客户端，如果未完成，继续工作。

（2）IO调用在完成后能主动通知工作进程。

当然最好的就是用第二种方法了；像select/poll/epoll等这样的系统调用就是用来支持第二种解决方案的。这些系统调用也常被称为事件驱动模型。他们提供了一种机制就只让进程同时处理多个并发请求，不用关心IO调用的具体状态。IO调用完全由事件驱动模型来管理。

Nginx中的事件驱动模型

就是用事件驱动处理库（多路IO复用），最常用的就是select模型，poll模型，epoll模型。

关于这三个模型的详解在这里可以看到：https://segmentfault.com/a/1190000003063859

通过这个上面的简单讲解，再加上服务器的架构的了解，可以对Nginx有一个简单的了解，希望对之后的源码剖析有帮助。

大致上Nginx的架构就是这样：

1.Nginx启动后，会产生一个主进程，主进程执行一系列的工作后会产生一个或者多个工作进程；

2.在客户端请求动态站点的过程中，Nginx服务器还涉及和后端服务器的通信。Nginx将接收到的Web请求通过代理转发到后端服务器，由后端服务器进行数据处理和组织；

3.Nginx为了提高对请求的响应效率，降低网络压力，采用了缓存机制，将 历史 应答数据缓存到本地。保障对缓存文件的快速访问；

##工作进程##

工作进程的主要工作有以下几项：

接收客户端请求；

将请求一次送入各个功能模块进行过滤处理；

IO调用，获取响应数据；

与后端服务器通信，接收后端服务器处理结果；

数据缓存

响应客户端请求；

##进程交互##

Nginx服务器在使用Master-Worker模型时，会涉及到主进程和工作进程的交互和工作进程之间的交互。这两类交互都依赖于管道机制。

1.Master-Worker交互

这条管道与普通的管道不同，它是由主进程指向工作进程的单向管道，包含主进程向工作进程发出的指令，工作进程ID等；同时主进程与外界通过信号通信；

2.worker-worker交互

这种交互是和Master-Worker交互是基本一致的。但是会通过主进程。工作进程之间是相互隔离的，所以当工作进程W1需要向工作进程W2发指令时，首先找到W2的进程ID，然后将正确的指令写入指向W2的通道。W2收到信号采取相应的措施。

这里提及的参数是和IPv4网络有关的Linux内核参数。我们可以将这些内核参数的值追加到Linux系统的/etc/sysctl.conf文件中，然后使用如下命令使修改生效：

这些常用的参数包括以下这些。

** 1. net.core.netdev_max_backlog参数 **

net.core.netdev_max_backlog，表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。一般默认值为128（可能不同的Linux系统该数值也不同）。Nginx服务器中定义的NGX_LISTEN_BACKLOG默认为511.我们可以将它调整一下：

** 2.net.core.somaxconn参数 **

该参数用于调节系统同时发起的TCP连接数，一般默认值为128。在客户端存在高并发请求的情况下，在默认值较小，可能导致链接超时或者重传问题，我们可以根据实际需要结合并发请求数来调节此值。

** 3.net.ipv4.tcp_max_orphans参数 **

该参数用于设定系统中最多允许存在多少TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，没有与用户文件句柄关联的TCP套接字将立即被复位，同时给出警告信息。这个限制只是为了防止简单的DoS(Denial of Service，拒绝服务)攻击。一般在系统内存比较充足的情况下，可以增大这个参数的赋值：

** 4.net.ipv4.tcp_max_syn_backlog参数 **

该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。一般在系统内存比较充足的情况下，可以增加这个参数的赋值：

** 5.net.ipv4.tcp_timestamps参数 **

该参数用于设置时间戳，这可以避免序列号的卷绕。在一个1Gb/s的链路上，遇到以前用过的序列号的概率很大。当此值赋值为0时，禁用对于TCP时间戳的支持。在默认情况下，TCP协议会让内核接受这种“异常”的数据包。针对Nginx服务器来说，建议将其关闭：

** 6.net.ipv4.tcp_synack_retries参数 **

该参数用于设置内核放弃TCP连接之前向客户端发送SYN+ACK包的数量。为了建立对端的连接服务，服务器和客户端需要进行三次握手，第二次握手期间，内核需要发送SYN并附带一个回应前一个SYN的ACK，这个参数主要影响这个进程，一般赋值为1，即内核放弃连接之前发送一次SYN+ACK包，可以设置其为：

** 7.net.ipv4.tcp_syn_retries参数 **

该参数的作用和上一个参数类似，设置内核放弃建立连接之前发送SYN包的数量，它的赋值和上个参数一样即可：

在Nginx配置文件中，有这样两个指令：worker_processes和worker_cpu_affinity，它们可以针对多核CPU进行配置优化。

** 1.worker_processes指令 **

worker_processes指令用来设置Nginx服务的进程数。官方文档建议此指令一般设置为1即可，赋值太多会影响系统的IO效率，降低Nginx服务器的性能。为了让多核CPU能够很好的并行处理任务，我们可以将worker_processes指令的赋值适当的增大一些，最好是赋值为机器CPU的倍数。当然，这个值并不是越大越好，Nginx进程太多可能增加主进程调度负担，也可能影响系统的IO效率。针对双核CPU，建议设置为2或

4。如果是四核CPU，设置为：

设置好worker_processes指令之后，就很有必要设置worker_cpu_affinity指令。

** 2. worker_cpu_affinity指令 **

worker_cpu_affinity指令用来为每个进程分配CPU的工作内核。这个指令用来为每个进程分配CPU的工作内核。这个指令的设置方法有些麻烦。

如下图所示：

worker_cpu_affinity指令的值是由几组二进制值表示的。其中，每一组代表一个进程，每组中的每一位表示该进程使用CPU的情况，1表示使用，0表示不使用。注意，二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。

如果设置的Nginx服务的进程数为4，CPU为4核，因此会有四组值，并且每组有四位，所以，此指令的设置为：

四组二进制数值分别对应4个进程，第一个进程对应0001，表示使用第一个CPU内核。第二个进程对应0010，表示使用第二个CPU内核，以此类推。

如果将worker_processes指令的值赋值为8，即赋值为CPU内核个数的两倍，则worker_cpu_affinity指令的设置可以是：

如果一台机器的CPU是八核CPU，并且worker_processes指令的值赋值为8，那么worker_cpu_affinity指令的设置可以是：

** 1.keepalive_timeout指令 **

该指令用于设置Nginx服务器与客户端保持连接的超时时间。

这个指令支持两个选项，中间用空格隔开。第一个选项指定客户端连接保持活动的超时时间，在这个时间之后，服务器会关闭此连接。第二个选项可选，其指定了使用Keep-Alive消息头保持活动的有效时间，如果不设置它，Nginx服务器不会向客户端发送Keep-Alive消息头以保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接，超过设置的时间后，客户端就可以关闭连接，而不需要服务器关闭了。你可以根据自己的实际情况设置此值，建议从服务器的访问数量、处理速度以及网络状态方面考虑。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端连接保持活动的时间是60s，60s后服务器与客户端断开连接。使用Keep-Alive消息头保持与客户端某些浏览器（如Mozilla、Konqueror等）的连接时间为50s，50s后浏览器主动与服务器断开连接。

** 2.send_timeout指令 **

该指令用于设置Nginx服务器响应客户端的超时时间，这个超时时间仅针对两个客户端和服务器之间建立连接后，某次活动之间的时间。如果这个时间后客户端没有任何活动，Nginx服务器将会关闭连接。此指令的设置需要考虑服务器访问数量和网络状况等方面。下面是此指令的设置示例：

该设置表示Nginx服务器与客户端建立连接后，某次会话中服务器等待客户端响应超时10s，就会自动关闭连接。

** 3.client_header_buffer_size指令 **

该指令用于设置Nginx服务器允许的客户端请求头部的缓冲区大小，默认为1KB。此指令的赋值可以根据系统分页大小来设置。分页大小可以用以下命令取得：

有过Nginx服务器工作经验的可能遇到Nginx服务器返回400错误的情况。查找Nginx服务器的400错误原因比较困难，因为此错误并不是每次都会出现，出现错误的时候，通常在浏览器和日志里也看不到任何有关提示信息。根据实际的经验来看，有很大一部分情况是客户端的请求头部过大造成的。请求头部过大，通常是客户单cookie中写入了较大的值引起的。于是适当增大此指令的赋值，允许Nginx服务器接收较大的请求头部，可以改善服务器对客户端的支持能力。一般将此指令赋值为4KB大小，即：

** 4.multi_accept指令 **

该指令用于配置Nginx服务器是否尽可能多的接收客户端的网络连接请求，默认值为off。

本节涉及的指令与Nginx服务器的事件驱动模型密切相关。

其中，number为设置的最大数量。结合worker_processes指令，我们可以计算出Nginx服务器允许同时连接的客户端最大数量Client = worker_processes * worker_connections / 2

在使用Nginx服务器的过程中，笔者曾经遇到过无法访问Nginx服务器的情况，查看日志发现一直在报如下错误:

根据报错信息，推测可能是Nginx服务器的最大访问连接数设置小了。此指令设置的就是Nginx服务器能接受的最大访问量，其中包括前端用户连接也包括其他连接，这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积。此指令一般设置为65535：

此指令的赋值与linux操作系统中进程可以打开的文件句柄数量有关系。按照以上设置修改此项赋值以后，Nginx服务器报以下错误：

究其原因，Linux系统中有一个系统指令open file resource limit，它设置了进程可以打开的文件句柄数量。worker_connections指令的赋值当然不能超过open file resource limit的赋值。可以使用以下命令查看在你的Linux系统中open file resource limit的赋值。

可以通过一下命令将open file resource limit指令的值设为2390251：

这样，Nginx的worker_connections指令赋值为65535就没问题了。

其中，limit为Linux平台事件信号队列的长度上限值。

该指令主要影响事件驱动模型中rfsig模型可以保存的最大信号数。Nginx服务器的每一个工作进程有自己的事件信号队列用于暂存客户端请求发生信号，如果超过长度上线，Nginx服务器自动转用poll模型处理未处理器的客户端请求。为了保证Nginx服务器对客户端请求的高效处理，请大家根据实际的客户端并发请求数量和服务器运行环境的处理能力设定该值。设置示例为：

其中，number为要设置的数量，默认值均为32。

其中，number为要设置的数量，默认值均为512.

使用kequeue_changes方式，可以设置与内核之间传递事件的数量。

其中，number为要设置的数量，默认值均为512。

7.rtsig_signo指令

该指令用于设置rtsig模式使用的两个信号中的第一个，第二个信号是在第一个信号的编号上加1，语法为：

默认的第一个信号设置为SIGRTMIN+10。

提示

在Linux中可以使用一下命令查看系统支持的SIGRTMIN有哪些。

8.rtsig_overflow_* 指令

该指令代表三个具体的指令，分别为rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。这些指令用来控制当rtsig模式中信号队列溢出时Nginx服务器的处理方式，语法结构为：

其中，number是要设定的值。

rtsig_overflow_events指令指定队列溢出时使用poll库处理的事件数，默认值为16。

rtsig_overflow_test指令设定poll库处理完第几件事件后将清空rtsig模型使用的信号队列，默认值为32。

rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了。

---