nginx架构与基础概念

不念不忘少年蓝@ 2021-06-30 08:22 387阅读 0赞

## 1.`Nginx`架构 ##

`Nginx`高性能，与其架构有关。

`Nginx`架构： `nginx`运行时，在`unix`系统中以`daemon`形式在后台运行，后台进程包含一个`master`进程和多个`worker`进程。`Nginx`以多进程形式工作，也支持多线程方式，丹`nginx`默认采用多进程方式，也是主流方式。

### 1.1`Nginx`多进程模式 ###

多进程模式，会有一个`master`进程和多个`worker`进程。

`Master`进程管理`worker`进程，包括：

接收来自外界的信号；

向各`worker`进程发送信号；

监控`work`进程状态；

当`worker`退出后（异常情况下），自动重新启动新`worker`进程。

多个`worker`进程之间对等，竞争来自客户端的请求，一个请求，只会在一个`worker`中处理，一个`worker`进程不会处理其他进程的请求。

`Worker`进程个数的设置，一般设置与机器`cpu`核数一致。

进程模式的好处：

每个`worker`进程相互独立，无需加锁，节省锁开销；

采用独立的进程，不会相互影响，一个进程退出，其他进程服务不会中断；

`Worker`异常退出，会导致当前`worker`上的所有请求失败，不过不会影响所有请求，降低了风险。

多进程模式对并发的支持

每个`worker`只有一个主线程，采用异步非阻塞方式来处理请求，使得`nginx`可以同时处理成千上万个请求。相比`Apache`，每个请求会独占一个工作线程，并发上千时，就同时有几千的线程在处理请求，线程带来的内存占用很大，线程的上下午切换带来的`cpu`开销也大，性能就上不去了。

**异步非阻塞是什么呢？**

一个请求的完整过程：请求过来，建立连接，然后接收数据，接收数据后，再发送数据。

具体到系统底层，就是读写事件，当读写时间没有准备好时，如果不用非阻塞的方式来调用，就得阻塞调用了，事件没准备好，就只能等，等事件准备好再继续。阻塞调用会进入内核等待，让出`cpu`，对单线程的`worker`来说，显然不合适，当网络事件越多时，等待很多，`cpu`利用率上不去。非阻塞就是，事件没有准备好，马上返回`eagain`，表示事件还没准备好，过会儿再来，过一会，再来检查一下事件，直到事件准备好为止，在这期间，你可以先去做其他事情，然后再来看看事件好了没。这时，虽不阻塞了，但是还得不时来检查事件的状态，带来的开销也不小。所以有了异步非阻塞的事件处理机制，具体到系统调用就是像 `select/poll/epoll/kquene`这样的系统调用。提供一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但是可以设置超时时间，在超时时间之内，如果有事件准备好了就返回。这种机制解决了上面的两个问题，以`epoll`为例，当事假没准备好时，放到`epoll`里，事件准备好了，就去读写，当读写返回`eagain`时，将它再次加入`epoll`，这样，只要有事件准备好了，就去处理它，只有当所有事件都没有准备好时，才在`epoll`里等着。这样，就可以支持大量的并发，这里的并发请求，是指未处理完的请求，线程只有一个，同时处理的请求只有一个，只是在请求间不断切换，切换是因为异步事件未准备好，主动让出的。这里的切换没有什么代价，可以理解为在循环处理多个准备好的事件，事实上也是。与多线程相比，这种事件处理方式有很大优势，不需创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常轻量级，没有上下文切换的开销，更多并发，只会占更多的内存而已。现在的网络服务器基本都采用这种方式，也是`nginx`性能高效的主要原因。

推荐设置`worker`数与`cpu`的核数一致，因为更多的`worker`，会导致进程竞争`cpu`资源，从而带来不必要的上下文切换。

### 1.2 操作`nginx` ###

怎样操作运行的`nignx`呢？`master`进程会接收来自外界发来的信号，因此要控制`nginx`，通过`kill`向`master`进程发送信号就可以了。如 `kill –HUP pid`，重启`nginx`，或重新加载配置，而不中断服务。`Master`进程在接到这个信号后，会先重新加载配置文件，然后再启动新的`worker`进程，并向所有老的`worker`进程发信号，不再接收新的请求，并且在处理完所有未处理完的请求后，退出。新的`worker`启动后，就开始接收新的请求。

直接给`master`发信号，是比较老的操作方法，在`nginx0.8`版本后，可以使用命令行参数，方便管理，如`./nginx –s reload` ，重启`nginx`； `./nginx –s stop`，停止`nginx`。这种方式的内部原理是，执行命令时，会启动一个新的`nginx`进程，该进程在解析到`reload`参数后，知道目标是控制`nginx`重新加载配置文件，它会向`master`进程发送信号，接下来的处理，和直接向`master`进程发送信号一样。

### 1.3`Nginx`处理请求 ###

`Worker`进程是怎么处理请求的呢？

一个连接请求过来，每个进程都有可能处理这个连接。`Worker`进程是从`master`进程`fork`出来的，在`master`进程里，先建立好需要`listen`的`socket`（`listenfd`）后，然后再`fork`出多个`worker`进程。所有`worker`进程的`listenfd`会在新连接到来时变得可读，为了保证只有一个进程处理该连接，所有`worker`进程在注册`listenfd`读事件前抢`accept_mutex`，抢到互斥锁的那个进程注册`listenfd`读事件，在读事件里调用`accept`接受该连接。当一个`worker`进程在`accept`这个连接之后，开始读取请求，解析请求，产生数据后，再返回给客户端，最后才断开连接，这就是一个完整的请求处理。一个请求，完全由`worker`处理，且只在一个`worker`里处理。

## 2.`Nginx`基础概念 ##

### 2.1`Connection` ###

`Nginx`中`connection`是对`tcp`连接的封装，包括连接的`socket`，读事件，写事件。

`Nginx`怎么处理一个连接的呢？`nginx`在启动时，会解析配置文件，得到需要监听的端口与`ip`，然后在`nginx`的`master`进程里，先初始化这个监控的`socket`，然后再`fork`出多个子进程，子进程竞争`accept`新的连接。此时，客户端就可以像`nginx`发起连接了，当客户端与服务器通过三次握手建立好一个连接，`nginx`的某一个子进程会`accept`成功，得到这个`socket`，然后创建`nginx`对连接的封装，接着，设置读写事件处理函数并添加读写事件来与客户端进行数据的交换。最后，`nginx`或客户端主动关掉连接。

`Nginx`也可以作为客户端来请求其他`server`的数据，此时，与其它`server`创建的连接，也封装在`ngx_connection`中。

`Nginx`中，每个进程会有一个连接数的最大上限，这个上限与系统对`fd`的限制不一样。操作系统中，使用`ulimit -n`,可以得到一个进程所能打开的`fd`的最大数，即`nofile`，因为每个`socket`会占用一个`fd`，所以这个会限制进程的最大连接数，`fd`用完后，再创建`socket`，就会失败。`Nginx`通过设置`worker_connections`来设置每个进程支持的最大连接数，如果该值大于`nofile`，那么实际的最大连接数是`nofile`，`nginx`会有警告。`Nginx`在实现时，是通过一个连接池来管理的，每个`worker`进程都有一个独立的连接池，连接池大小是`worker_connections`。这里连接池里面保存的其实不是真实的连接，只是一个`worker_connections`大小的`ngx_connection_t`结构的数组。`Nginx`通过一个链表`free_connections`来保存所有的空闲`ngx_connection_t`.每次获取一个连接时，就从空闲连接链表中获取一个，用完后，再放回空闲连接链表里面。

`Worker_connections`,表示每个`worker`所能建立连接的最大值，一个`nginx`能建立的最大连接数是：`worker_connections * worker_processes`.因此对于`HTTP`请求本地资源，最大并发可以是 `worker_connections * worker_processes`.而如果是`HTTP`作为反向代理来说，最大并发数是 `worker_connections * worker_processes/2`.因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务器的连接，占用2个连接。

如何保证`worker`进程竞争处理连接的公平呢？

如果某个进程得到`accept`的机会比较多，它的空闲连接会很快用完，如果不提前做一些控制，当`accept`到一个新的`tcp`连接后，因为无法得到空闲连接，而且无法将此连接转交其他进程，最终导致此`tcp`连接得不到处理。而其他进程有空余连接，却没有处理机会。如何解决这个问题呢？

`Nginx`的处理得先打开`accept_mutex`，此时只有获得了`accept_mutex`的进程才会去添加`accept`事件，`nginx`会控制进程是否添加`accept`事件。`Nginx`使用一个叫`ngx_accept_disabled`变量控制是否竞争`accept_mutex`锁。这个变量与`worker`进程的剩余连接数有关，当该变量大于0时，就不去尝试获取锁，等于让出获取连接的机会。这样就可以控制多进程间连接的平衡了。

### 2.2`Keep alive` ###

`http`请求是请求应答式的，如果我们知道每个请求头与相应体的长度，那么我们可以在一个连接上面执行多个请求。即长连接。如果当前请求需要有`body`，那么`nginx`就需要客户端在请求头中指定`content-length`来表面`body`的大小，否则返回`400`错误。那么响应体的长度呢？`http`协议中关于响应`body`长度的确定：

1.  对于`http1.0` 协议来说，如果响应头中有`content-length`头，则以`content-length`的长度就可以知道`body`的长度，客户端在接收`body`时，可以依照这个长度接收数据，接收完后，就表示该请求完成。如果没有`content-length`，客户端会一直接收数据，直到服务端主动端口连接，才表示`body`接收完
2.  对于`http1.1` 协议，如果响应头中`transfer-encoding`为`chunked`传输，表示`body`是流式输出，`body`被分成多个块，每块的开始会标示出当前块的长度，此时，`body`不需要指定长度。如果是非`chunked`传输，而且有`Content-length`，则按照`content-length`来接收数据。否则，非`chunked`且没有`content-length`，则客户端接收数据，知道服务器主动断开。

客户端请求头中`connection`为`close`，表示客户端要关掉长连接，如果是`keep-alive`,则客户端需要打开长连接。客户端的请求中没有`connection`这个头，根据协议，如果是`http1.0`,默认是`close`，如果是`http1.1`，默认是`keep-alive`。如果要`keep-alive`，`nginx`在输出完响应体后，会设置当前连接的`keepalive`属性，然后等待客户端下一次请求，`nginx`设置了`keepalive`的等待最大时间。一般来说，当客户端需要多次访问同一个`server`时，打开`keepalive`的优势非常大。

### 2.3`Pipe` ###

`http1.1`中引入`Pipeline`，就是流水线作业，可以看做是`keepalive`的升华。`Pipeline`也是基于长连接的。目前就是利用一个连接做多次请求，如果客户端要提交多个请求，对于`keepalive`，第二个请求，必须要等到第一个请求的响应接收完后，才能发起。得到两个响应的时间至少是`2*RTT`。而对于`pipeline`，客户端不必等到第一个请求处理完，就可以发起第二个请求。得到两个响应的时间可能能够达到`1*RTT`。`Nginx`是直接支持`pipeline`的。`Nginx`对`pipeline`中的多个请求的处理不是并行的，而是一个接一个的处理，只是在处理第一个请求的时候，客户端就可以发起第二个请求。这样，`nginx`利用`pipeline`可以减少从处理完一个请求后到等待第二个请求的请求头数据的时间。

## 3.`Nginx`怎么用（安装与配置） ##

具体参见http://seanlook.com/2015/05/17/nginx-install-and-config/

或者http://blog.csdn.net/guodongxiaren/article/details/40950249

安装`nginx`

yum install nginx-1.6.3

### 3.1`Nginx.conf` 配置 ###

`Nginx`配置文件主要有4部分，`main`(全局设置)、`server`（主机设置）、`upstream`（上游服务器设置，主要为反向代理，负载均衡相关配置）和`location`（`url`匹配特定位置的设置），每部分包含若干指令。

`Main`部分的设置影响其他所有部分的设置；

`Server`部分主要用于指定虚拟机主机域名，ip和端口；

`Upstream`的指令用于设置一系列的后端服务器，设置反向代理及后端服务器的负载均衡；

`Location`部分用于匹配网页位置（如，跟目录“/”,”/images”等）。

它们之间的关系是，`server`继承`main`，`location`继承`server`，`upstream`既不会继承指令也不会被继承。

## 4.1 为什么高并发重要 ##

和十年前相比，目前的互联网已经难以想象的广泛应用和普及。从NCSA用`Apache`搭的`web`服务器提供的可点击的文本HTML，已然进化成超过20亿人在线的通信媒介。随着永久在线的个人电脑，移动终端以及平板电脑的增多，互联网在快速变化，经济系统也完全数字有线化。提供实时可用信息和娱乐的在线服务变得更加复杂精巧。在线业务的安全需求也急剧变化。网站比从前更加复杂，需要在工程上做的更具有健壮性和可伸缩性。

并发总是网站架构最大的挑战之一。由于web服务的兴起，并发的数量级在不断增长。热门网站为几十万甚至几百万的同时在线用户提供服务并不寻常。十年前，并发的主要原因是由于客户端接入速度慢–用户使用`ADSL`或者拨号商务。现在，并发是由移动终端和新应用架构所带来，这些应用通常基于持久连接来为客户端提供新闻，微博，通知等服务。另一个重要的因素就是现代浏览器行为变了，他们浏览网站的时候会同时打开4到6个连接来加快页面加载速度。

举例说明一下慢客户端的问题，假设一个`Apache`网站产生小于`100KB`的响应–包含文本或图片的网页。生成这个页面可能需要1秒钟，但是如果网速只有`80kbps`（10KB/s），需要花10秒才能把这个页面发送到客户端。基本上，`web`服务器相对快速的推送`100KB`数据，然后需要等待10秒发送数据之后才能关闭连接。那么现在如果有1000个同时连接的客户端请求相同的页面，那么如果为每个客户端分配1MB内存，就需要`1000MB`内存来为这1000个客户端提供这个页面。实际上，一个典型的基于`Apache`的web服务器通常为每个连接分配`1MB`内存，而移动通信的有效速度也通常是几十kbps。虽然借助于增加操作系统内核`socket`缓冲区大小，可以优化发送数据给慢客户端的场景，但是这并不是一个常规的解决方案，并且会带来无法预料的副作用。

随着持久连接的使用，并发处理的问题更加明显。为了避免新建`HTTP`连接所带来的延时，客户端需要保持连接，这样web服务器就需要为每个连接上的客户端分配一定数量的内存。

因此，为了处理持续增长的用户带来的负载和更高量级的并发，网站需要大量高效的组件。而另一方面，`web`服务器软件运行在诸如硬件（CPU，内存，磁盘），网络带宽，应用和数据存储架构等之上，这些基础设施显然也很重要。因而，随着同时在线数和每秒请求数的增长，web服务器性能也应该能够非线性扩展。

### `Apache`不再适用? ###

`Apache web`服务器软件发源于`1990`年代，目前在互联网网站上占有率第一。`Apache`的架构适合当时的操作系统和硬件，并且也符合当时的互联网状况：一个网站通常使用一台物理服务器运行一个`Apache`实例。`2000`年之后，显然这种单服务器模型已经无法简单扩展来满足日益增长的`web`服务需求。虽然`Apache`为新功能开发提供了坚实的基础，但他为每个新连接派生一个进程的做法（译注：`Apache`从`2.4`版本起已经支持事件模型），不适合网站的非线性扩展。最终，`Apache`成为一个通用的`web`服务器软件，聚焦于功能多样化，第三方扩展开发，以及`web`应用开发的通用性。然而，当硬件成本越来越低，每个连接消耗的CPU和内存越来越多，使用这样功能繁多的单一软件不再具有可伸缩性。

因而，当服务器硬件、操作系统和网络设施不再成为网站增长的主要限制因素时，网站开发者开始寻求更高效的手段来架设`web`服务器。大约十年前，著名软件工程师`Daniel Kegel`提出：“是时候让`web`服务器支持同时处理`10000`客户端了”，并且预言了现在称为云服务的技术。`Kegel`的`C10K`设想明显推动了许多人尝试解决这个问题–通过优化`web`服务器软件来支持大规模客户端连接的并发处理，`nginx`是其中做的最成功者之一。

为了解决`10000`个并发连接的`C10K`问题，`nginx`基于一个完全不同的架构—更适合每秒同时连接数和请求数非线性增长。`Nginx`基于事件模型，而没有模仿`Apache`为每个请求派生新进程或线程的做法。最终结果就是即使负载增加了，内存和`CPU`使用事件始终保持可预期。`Nginx`使用普通的硬件就能在一个服务器上处理数万的并发连接。

`Nginx`的第一个版本发布之后，一般被用来同`Apache`一同部署，`HTML、CSS、JavaScript`脚本和图片等静态内容由`nginx`处理，来降低`Apache`应用服务器的并发和延时。随着开发演进的过程，`nginx`增加了`FastCGI`、`uswge`和`SCGI`等协议的支持，以及对分布式内存对象缓存系统如`memcached`的支持。也增加了其他有用的功能，例如支持负载均衡和缓存的反向代理。这些附加功能使`nginx`成为一个高效的工具集，用于构建可伸缩的`web`基础设施。

2012年2月，`Apache 2.4.x`版本发布。虽然增加了新的并发处理核心模块和代理模块，用于加强可伸缩性和性能，但要说性能、并发能力和资源利用率是否能赶上或超过纯事件驱动模型的`web`服务器还为时尚早。`Apache`新版本具有了更好的性能值得高兴，对于`nginx+Apache`的`web`网站架构，虽然这能够缓解后端潜在的瓶颈，但并不能解决全部问题。

### nginx有更多的优点吗？ ###

部署`nginx`最关键的好处就是能够高性能高效的处理高并发。同时，还有更多有意思的好处。

最近几年，`web`架构拥抱解耦的理念并且将应用层设施从`web`服务器中分离。虽然现在仅仅是将原先基于`LAMP(Linux, Apache, MySQL, PHP, Python or Perl)`所构建的网站，变为基于`LEMP`（`E`表示`Engine x`）的。但是，越来越多的实践是将`web`服务器推入基础设施的边缘，并且用不同的方法整合这些相同或更新的应用和数据库工具集。

`Nginx`很适合做这些工作。他提供了必要的关键功能用于方便将下列功能从应用层剥离到更高效的边缘`web`服务器层：并发、长连接处理、SSL，静态内容、压缩和缓存、连接和请求限速，以及`HTTP`媒体流等。`Nginx`同时也允许直接整合`memcached、Redis`或者其他的`NoSQL`解决方案，增强为处理大规模并发用户的性能。

随着现代编程语言和开发包广泛使用，越来越多的公司改变了应用开发和部署的方式。`Nginx`已经成为这些改变范例之中的最重要的部件之一，并且已经帮助许多公司在预算内快速启动和开发他们的`web`服务。

`Nginx`开发始于2002年，2004年基于`2-clause BSD`授权正式对外发布。自发布起，`Nginx`用户就在不断增长，并且贡献提议，提交`bug`报告、建议和评测报告，这极大的帮助和促进了整个社区的发展。

`Nginx`代码完全用`C`语言从头写成，已经移植到许多体系结构和操作系统，包括：`Linux、FreeBSD、Solaris、Mac OS X、AIX`以及`Microsoft Windows`。`Nginx`有自己的函数库，并且除了`zlib、PCRE`和`OpenSSL`之外，标准模块只使用系统`C`库函数。而且，如果不需要或者考虑到潜在的授权冲突，可以不使用这些第三方库。

谈谈关于`Windows`版本`nginx`。当`nginx`在`Windows`环境下工作时，`Windows`版本的`nginx`更像是概念验证版本，而不是全功能移植。这是由于目前`nginx`和`Windows`内核架构之间交互的某些限制导致。`Windows`版本`ngnix`已知的问题包括：低并发连接数、性能降低、不支持缓存和带宽策略。未来`Windows`版本的`nginx`的功能会更接近主流版本。

## 4.2 `Nginx`架构综览 ##

传统基于进程或线程的模型使用单独的进程或线程处理并发连接，因而会阻塞于网络或`I/O`操作。根据不同的应用，就内存和`CPU`而言，这是非常低效的。派生进程或线程需要准备新的运行环境，包括在内存上分配堆和栈、生成一个新的运行上下文。创建这些东西还需要额外的`CPU`时间，而且过度的上下文切换引起的线程抖动最终会导致性能低下。所有这些复杂性在如`Apache web`服务器的老架构上一览无遗。在提供丰富的通用应用功能和优化服务器资源使用之间需要做一个权衡。

最早的时候，`nginx`希望为动态增长的网站获得更好的性能，并且密集高效的使用服务器资源，所以其使用了另外一个模型。受不断发展的在不同操作系统上开发基于事件模型的技术驱动，最终一个模块化，事件驱动，异步，单线程，非阻塞架构成为`nginx`代码的基础。

`Nginx`大量使用多路复用和事件通知，并且给不同的进程分配不同的任务。数量有限的工作进程（`Worker`）使用高效的单线程循环处理连接。每个`worker`进程每秒可以处理数千个并发连接、请求。

### 代码结构 ###

`Nginx worker`的代码包含核心和功能模块。核心负责维护一个紧凑的事件处理循环，并且在请求处理的每个阶段执行对应的模块代码段。模块完成了大部分展现和应用层功能。包括从网络和存储设备读取、写入，转换内容，进行输出过滤，`SSI(server-side include)`处理，或者如果启用代理则转发请求给后端服务器。

`nginx`模块化的架构允许开发者扩展`web`服务器的功能，而不需要修改`nginx`核心。`Nginx`模块可分为：核心、事件模块，阶段处理器，协议、变量处理器，过滤器，上游和负载均衡器等。目前，`nginx`不支持动态加载模块，即模块代码是和`nginx`核心代码一起编译的。模块动态加载和`ABI`已经计划在将来的某个版本开发。更多关于不同模块角色的详细信息可在14.4章找到。

`Nginx`在`BSD、Linux`和`Solaris`系统上使用`kqueue、epoll`和`event ports`等技术，通过事件通知机制来处理网络连接和内容获取，包括接受、处理和管理连接，并且大大增强了磁盘`IO`性能。目的在于尽可能的提供操作系统建议的手段，用于从网络进出流量，磁盘操作，套接字读取和写入，超时等事件中及时异步地获取反馈。`Nginx`为每个基于`Unix`的操作系统大量优化了这些多路复用和高级`I/O`操作的方法。

图14.1展示了`nginx`架构的高层设计。  
![在这里插入图片描述][20190916172718573.png]　　  
前面提到过，`nginx`不为每个连接派生进程或线程，而是由`worker`进程通过监听共享套接字接受新请求，并且使用高效的循环来处理数千个连接。`Nginx`不使用仲裁器或分发器来分发连接，这个工作由操作系统内核机制完成。监听套接字在启动时就完成初始化，`worker`进程通过这些套接字接受、读取请求和输出响应。

事件处理循环是`nginx worker`代码中最复杂的部分，它包含复杂的内部调用，并且严重依赖异步任务处理的思想。异步操作通过模块化、事件通知、大量回调函数以及微调定时器等实现。总的来说，基本原则就是尽可能做到非阻塞。`Nginx worker`进程唯一会被阻塞的情形是磁盘性能不足。

由于`nginx`不为每个连接派生进程或线程，所以内存使用在大多数情况下是很节约并且高效的。同时由于不用频繁的生成和销毁进程或线程，所以`nginx`也很节省`CPU`时间。`Nginx`所做的就是检查网络和存储的状态，初始化新连接并添加到主循环，异步处理直到请求结束才从主循环中释放并删除。兼具精心设计的系统调用和诸如内存池等支持接口的精确实现，`nginx`在极端负载的情况下通常能做到中低`CPU`使用率。

`nginx`派生多个`worker`进程处理连接，所以能够很好的利用多核`CPU`。通常一个单独的`worker`进程使用一个处理器核，这样能完全利用多核体系结构，并且避免线程抖动和锁。在一个单线程的`worker`进程内部不存在资源匮乏，并且资源控制机制是隔离的。这个模型也允许在物理存储设备之间进行扩展，提高磁盘利用率以避免磁盘`I/O`导致的阻塞。将工作负载分布到多个`worker`进程上最终能使服务器资源被更高效的利用。

针对某些磁盘使用和`CPU`负载的模式，`nginx worker`进程数应该进行调整。这里的规则比较基本，系统管理员应根据负载多尝试几种配置。通常推荐：如果负载模式是`CPU`密集型，例如处理大量`TCP/IP`协议，使用`SSL`，或者压缩数据等，`nginx worker`进程应该和`CPU`核心数相匹配；如果是磁盘密集型，例如从存储中提供多种内容服务，或者是大量的代理服务，`worker`的进程数应该是1.5到2倍的`CPU`核心数。一些工程师基于独立存储单元的数目来决定`worker`进程数，虽然这个方法的有效性取决于磁盘存储配置的类型，。

`Nginx`开发者在下个版本中要解决的一个主要问题是怎么避免磁盘`I/O`引起的阻塞。目前，如果没有足够的存储性能为一个`worker`进程的磁盘操作提供服务，这个进程就会阻塞在磁盘读写操作上。一些机制和配置指令用于缓解这个磁盘`I/O`阻塞的场景，最显著的是`sendfile`和`AIO`指令，这通常可以大幅提升磁盘性能。应该根据数据集（`data set`），可用内存数，以及底层存储架构等来规划安装`nginx`。

当前的`worker`模型的另一个问题是对嵌入脚本的支持有限。举例来说，标准的`nginx`发布版只支持`Perl`作为嵌入脚本语言。这个原因很简单：嵌入脚本很可能会在任何操作上阻塞或者异常退出，这两个行为都会导致`worker`进程挂住而同时影响数千个连接。将脚本更简单，更可靠地嵌入`nginx`，并且更适合广泛应用的工作已经列入计划。

### `nginx` 进程角色 ###

`Nginx`在内存中运行多个进程，一个`master`进程和多个`worker`进程。同时还有一些特殊用途的进程，例如缓存加载和缓存管理进程。在`nginx 1.x`版本，所有进程都是单线程的，使用共享内存作为进程间通信机制。`Master`进程使用`root`用户权限运行，其他进程使用非特权用户权限运行。

`master`进程负责下列工作：

*  读取和校验配置文件
 *  创建、绑定、关闭套接字
 *  启动、终止、维护所配置的`worker`进程数目
 *  不中断服务刷新配置文件
 *  不中断服务升级程序（启动新程序或在需要时回滚）
 *  重新打开日志文件
 *  编译嵌入`Perl`脚本

`Worker`进程接受、处理来自客户端的连接，提供反向代理和过滤功能以及其他`nginx`所具有的所有功能。由于`worker`进程是`web`服务器每日操作的实际执行者，所以对于监控`nginx`实例行为，系统管理员应该保持关注`worker`进程。

缓存加载进程负责检查磁盘上的缓存数据并且在内存中维护缓存元数据的数据库。基本上，缓存加载进程使用特定分配好的目录结构来管理已经存储在磁盘上的文件，为`nginx`提供准备，它会遍历目录，检查缓存内容元数据，当所有数据可用时就更新相关的共享内存项。

缓存管理进程主要负责缓存过期和失效。它在`nginx`正常工作时常驻内存中，当有异常则由`master`进程重启。

### `Nginx`缓存简介 ###

`Nginx`在文件系统上使用分层数据存储实现缓存。缓存主键可配置，并且可使用不同特定请求参数来控制缓存内容。缓存主键和元数据存储在共享内存段中，缓存加载进程、缓存管理进程和`worker`进程都能访问。目前不支持在内存中缓存文件，但可以用操作系统的虚拟文件系统机制进行优化。每个缓存的响应存储到文件系统上的不同文件，`Nginx`配置指令控制存储的层级（分几级和命名方式）。如果响应需要缓存到缓存目录，就从`URL`的`MD5`哈希值中获取缓存的路径和文件名。

将响应内容缓存到磁盘的过程如下：当`nginx`从后端服务器读取响应时，响应内容先写到缓存目录之外的一个临时文件。`nginx`完成请求处理后，就将这个临时文件重命名并移到缓存目录。如果用于代理功能的临时目录位于另外一个文件系统，则临时文件会被拷贝一次，所以建议将临时目录和缓存目录放到同一个文件系统上。如果需要清除缓存目录，也可以很安全地删除文件。一些第三方扩展可以远程控制缓存内容，而且整合这些功能到主发布版的工作已经列入计划。

## 4.3 `Nginx`配置文件 ##

`Nginx`配置系统来自于`Igor Sysoev`使用`Apache`的经验。他认为可扩展的配置系统是`web`服务器的基础。当维护庞大复杂的包括大量的虚拟服务器、目录、位置和数据集等配置时，会遇到可伸缩性问题。对于一个相对大点的网站，系统管理员如果没有在应用层进行恰当的配置，那么这将会是一个噩梦。

所以，`nginx`配置为简化日常维护而设计，并且提供了简单的手段用于`web`服务器将来的扩展。

配置文件是一些文本文件，通常位于`/usr/local/etc/nginx`或`/etc/nginx`。主配置文件通常命名为`nginx.conf`。为了保持整洁，部分配置可以放到单独的文件中，再自动地被包含到主配置文件。但应该注意的是，`nginx`目前不支持`Apache`风格的分布式配置文件（如`.htaccess`文件），所有和`nginx`行为相关的配置都应该位于一个集中的配置文件目录中。

`Master`进程启动时读取和校验这些配置文件。由于`worker`进程是从`master`进程派生的，所以可以使用一份编译好、只读的配置信息。配置信息结构通过常见的虚拟内存管理机制自动共享。

`Nginx`配置具有多个不同的上下文，如：`main, http, server, upstream, location` (以及用于邮件代理的 `mail` ) 等指令块。这些上下文不重叠，例如，一个`location` 指令块是不能放入`main`指令块中。并且，为了避免不必要的歧义，不存在一个类似于“全局web服务器”的配置。`Nginx`配置特意做的整洁和富有逻辑性，允许用户可以建立包含上千个指令的复杂的配置文件。在一次私人谈话中，`Sysoev`说：“全局服务器配置中的位置、目录和其他一些指令是`Apache`中我所不喜欢的特性，所以这就是不在`nginx`实现这些的原因。”

配置语法、格式和定义遵循一个所谓的C风格协定。这种构建配置文件的方法在开源软件和商业软件中有广泛的应用。通过设计，C风格配置很适合嵌套描述，富有逻辑性，易于创建、读取和维护，深受广大工程师喜欢。同时`nginx`的C风格配置也易于自动化。

虽然一些`nginx`配置指令看起来像`Apahce`配置的一部分，但是设置一个`nginx`实例是完全不同的体验。例如，虽然`nginx`支持重写规则，但是系统管理员要手工的转换`Apache`重写配置使之适合`nginx`风格。同样，重写引擎的实现也是不一样的。

通常来说，`nginx`设置也提供了几种原始机制的支持，对于高效的`web`服务器配置很有帮助。有必要简单了解下变量和`try_files`指令，这些差不多是`nginx`所独有的。`Nginx`开发了变量用于提供附加的更强大的机制来控制运行时的`web`服务器配置。变量为快速赋值做了优化，并且在内部预编译为索引。赋值是按需计算的，例如，变量的值通常只在这个请求的生命周期中计算一次，而后缓存起来。变量可在不同的配置指令中使用，为描述条件请求处理行为提供了更多弹性。

`try_files`指令对于用更适当的方式逐渐替换if 条件配置语句是很重要的，并且它设计用来快速高效的尝试不同的`URI`与内容之间的映射。总的来说，`try_files`指令很好用，并且及其高效和有用。推荐读者完整的看看这个指令，并在任何能用的地方用上它。

## 4.4 深入`nginx` ##

前面提到过，`nginx`代码包含核心和其他模块。核心负责提供`web`服务器的基础，`web`和邮件反向代理功能；实现底层网络协议，构建必要的运行环境，并且保证不同模块之间的无缝交互。但是，大部分协议相关以及应用相关的特性是由其他模块完成，而不是核心模块。

在内部，`nginx`通过模块流水线或模块链处理连接。换言之，每个操作都有一个模块做对应的工作。例如：压缩，修改内容，执行`SSI`，通过`FastCGI`或`uwsgi`协议同后端应用服务器通信，以及同`memcached`通信等。

在核心和实际功能模块之间，有两个模块`http`和`mail`。这两个模块在核心和底层组件之间提供了附加抽象层。这些模块处理同各自应用层协议相关的事件序列，如实现`HTTP、SMTP`或`IMAP`。与核心一起，这些上层模块负责以正确的次序调用各自的功能模块。虽然目前`HTTP`协议是作为`http`模块的一部分实现的，但将来计划将其独立为一个功能模块，以支持其他协议，如`SPDY`（参考“SPDY: `An experimental protocol for a faster web`”）。

功能模块可以分为事件模块，阶段处理器，输出过滤器，变量处理器，协议模块，上游和负载均衡器等类型。虽然事件模块和协议也用于`mail`模块，但是这些模块大部分用于补充`nginx`的`HTTP`功能。事件模块提供了基于操作系统的事件通知机制，如`kqueue` 或 `epoll`，这些取决于操作系统的能力和构建配置。协议模块允许`nginx`通过`HTTPS`, `TLS/SSL, SMTP, POP3` 和 `IMAP`等协议通信。

一个典型的`HTTP`请求处理周期如下：

1.  客户端发送`HTTP`请求。
2.  `nginx`核心从配置文件查找匹配该请求的位置，根据这个位置信息选择适当的阶段处理器。
3.  如果配置为反向代理，负载均衡器挑选一个上游服务器用于转发请求。
4.  阶段处理器完成工作，并且传递每个输出缓冲区给第一个过滤器。
5.  第一个过滤器传递输出给第二个过滤器。
6.  第二个过滤器传递输出给第三个等等。
7.  最终响应发送给客户端。

`Nginx`模块是高度可定制化的。它通过一系列指向可执行函数的回调指针来工作。因而，带来的副作用就是为第三方开发者加重了负担，因为他们必须精确的定义模块应怎么运行和何时运行。`Nginx`的`API`和开发者文档都经过优化使之更具有可用性来减轻开发难度。

一些在`nginx`中插入模块的例子：

*  配置文件读取和处理之前
 *  `Location`和`server`的每个配置指令生效时
 *  `Main`配置初始化时
 *  `Server`配置初始化时
 *  `Server`配置合并到main配置时
 *  `Location`配置初始化或者合并到上级`server`配置时
 *  `Master`进程启动或退出时
 *  新的`worker`进程启动或退出时
 *  处理请求时
 *  过滤响应头和响应体时
 *  挑选，初始化和重新初始化上游服务器时
 *  处理上游服务器响应时
 *  完成与上游服务器的交互时

在`Worker`内部，生成响应的过程如下：

1.  开始`ngx_worker_process_cycle()`
2.  通过操作系统的机制处理事件（如 `epoll` 或 `kqueue`）。
3.  接受事件并调用对应的动作。
4.  处理或转发请求头和请求体。
5.  生成响应内容，并流式发送给客户端。
6.  完成请求处理。
7.  重新初始化定时器和事件。

事件循环自身（步骤5和6）确保增量产生响应并且流式发送给客户端。

更详细的处理HTTP请求过程如下：

1.  初始化请求处理
2.  处理请求头
3.  处理请求体
4.  调用对应的处理器
5.  执行所有的处理阶段

当`nginx`处理一个`HTTP`请求时，会经过多个处理阶段。每个阶段都调用对应的处理器。通常，阶段处理器处理一个请求后产生对应的输出，阶段处理器在配置文件的`location`中定义。

阶段处理器一般做四件事情：获取`location`配置，产生适当的响应，发送响应头，发送响应体。处理器函数有一个参数：描述请求的结构体。请求结构体有许多关于客户端请求的有用信息，例如：请求方法类型，`URI`和请求头等。

当读取完`HTTP`请求头之后，`nginx`查找相关的虚拟服务器配置，如果找到虚拟服务器，请求会经过下面六个阶段：

1.  server rewrite phase
2.  location phase
3.  location rewrite phase (which can bring the request back to the previous phase可以将请求带回到前面的阶段)
4.  access control phase
5.  try\_files phase
6.  log phase

为了给请求生成必要的响应内容，`nginx`传递请求给匹配的内容处理器。根据`location`配置，`nginx`会先尝试无条件处理器，如`perl,proxy_pass,flv,mp4`等。如果这个请求不匹配这几个内容处理器，将会按下面顺序挑选一个处理器：`random index,index,autoindex,gzip_static,static`。

`Nginx`文档中有`Index`模块的详细内容，这个模块只处理结尾为斜杠的请求。如果不匹配`mp4`或`autoindex`模块，则认为响应内容是磁盘上的一个文件或目录（即静态的），这由`static`内容处理器完成服务。如果是目录，将自动重写`URI`保证结尾是一个斜杠（从而发起一个`HTTP`重定向）。

内容处理器产生的内容则被传递到过滤器。过滤器也同`location`相关，一个`location`可配置多个过滤器。过滤器加工处理器产生的输出。处理器的执行顺序在编译时决定，对于原生过滤器，顺序是已经定义好的，对于第三方过滤器，可以在编译阶段设置先后顺序。当前的`nginx`实现中，过滤器只能修改输出的数据，还不能编写修改输入的数据的过滤器。输入过滤器将在将来的版本提供。

过滤器遵循一个特定的设计模式。过滤器被调用后开始工作，调用下一个过滤器直到过滤器链中的最后一个。完成之后，`nginx`结束响应。过滤器不用等待前面的过滤器结束。一旦前一个过滤器提供的输入已经可用，下一个过滤器便可以启动自己的工作（很像Unix中的管道）。因而，在从上游服务器接收到所有的响应之前，所生成的输出响应已经被发送给客户端。

过滤器有`header filter`和`body filter`，`nginx`将响应的`header`和`body`分别发送给相关的过滤器。

`Header filter`包含3个基本步骤：

1.  决定是否处理这个响应
2.  处理响应
3.  调用下一个过滤器

`body filter`转换所生成的内容。`body filter`的一些例子：

*  `SSI`
 *  `XSLT`过滤
 *  图片过滤（例如调整图片大小）
 *  字符集转换
 *  `Gzip`压缩
 *  `Chunked`编码

经过过滤器链之后，响应被发送到`writer`。有两个额外的具有特定功能的过滤器与`writer`相关，`copy filter`和`postpone filter`。`Copy filter`负责将相关的响应内容填充到内存缓冲区，这些响应内容有可能存储在反向代理的临时目录。`Postpone filter`用于子请求处理。

子请求是一个处理请求、响应很重要的机制，同时也是`nginx`最强大的功能之一。通过子请求，`Nginx`可以返回另一个`URL`的响应，这个`URL`与客户端最初请求的`URL`不同。一些`web`框架称之为内部跳转，但`nginx`功能更强，不仅能运行多个子请求并将这些子请求的响应合并成一个，而且还能嵌套和分级。子请求可以产生子-子请求，子-子请求能产生子-子-子请求。子请求可以映射到磁盘文件，其他处理，或者上游服务器。子请求在根据原始响应数据插入附加内容时很有用。例如，`SSI`模块使用一个过滤器解析返回文档的内容，然后用指定`URL`的内容来替换`include`指令。或者做一个过滤器，能够在一个`URL`产生的响应内容之后附加一些新的文档内容。

上游（`upstream`）和负载均衡器同样也值得简单介绍一下。上游用于实现反向代理处理器（`proxy_pass`处理器）。上游模块组装好请求发送给上游服务器（或称为“后端”），然后接收上游服务器返回的响应。这个过程不调用输出过滤器。上游模块仅仅设置回调函数，用于当上游服务器可读或可写时调用。回调函数实现下列功能：

*  准备请求缓冲区（或缓冲区链），用于发送给上游服务器
 *  重新初始化、重置与上游服务器之间的连接（应在重新发起请求之前）
 *  处理上游服务器响应的首字节，并且保存响应内容的指针
 *  放弃请求（当客户端过早关闭连接时）
 *  结束请求（当`nginx`完成读取上游服务器响应时）
 *  修整响应体内容（例如除去空白）

如果上游服务器大于一个，负载均衡器模块可附加在`proxy_pass`处理器上，用于提供选择上游服务器的能力。负载均衡器注册了一个配置文件指令，提供附加的上游服务器初始化功能（通过`DNS`解析上游服务器名字等），初始化连接结构体，决定如何路由请求，并且更新状态信息。目前，`nginx`支持两种标准的上游服务器负载均衡规则：轮询和`ip`哈希。

上游模块和负载均衡处理机制的算法能检测上游服务器异常，并将新请求重新路由到可用的上游服务器，还有更多的工作计划加强这个功能。总之，负载均衡器的改进计划更多些，下个版本的`nginx`将大幅度提升在不同上游服务器之间分发负载和健康检测的机制。

还有一些有意思的模块在配置文件中提供了额外的变量供使用。这些变量通过不同的模块生成和更新，有两个模块完全用于变量：`geo`和`map`。`geo`模块用于更方便的基于`IP`地址追踪客户端地址，这个模块可以根据客户端`IP`地址生成任意变量。另一个`map`模块允许从一个变量生成另一个变量，提供将主机名和其他变量方便的进行映射的基本能力。这类模块称为变量处理器。

`nginx worker`进程实现的内存分配机制从某方面来说来自于`Apache`。`Nginx`内存管理的高层描述：对于每个连接，必要的内存缓冲区是动态分配的，用于存储或操纵请求、响应的头和体，当连接关闭时释放。很重要的一点是`nginx`尽可能的去避免在内存中拷贝数据，大部分的数据通过指针进行传递，而不是调用`memcpy`。

更深入一点，当一个模块产生响应时，这些响应内容放入内存缓冲区，并被添加到一个缓冲区链。这个缓冲区链同样适用于子请求处理。由于根据模块类型不同存在多个处理场景，所以`nginx`中的缓冲区链相当复杂。例如，在实现`body filter`模块时，精确的管理缓冲区是很棘手的。这个模块同一时间只能处理缓冲区链中的一个缓冲区，它必须决定是否覆盖输入缓冲区，是否用新分配的缓冲区替换这个缓冲区，或者在这个缓冲区之前或之后插入一个新缓冲区。更复杂的情况，有时一个模块收到的数据需要多个缓冲区存储，因此它必须处理一个不完整的缓冲区链。但是由于目前`nginx`仅提供了底层API用于操纵缓冲区链，所以开发者应该真正掌握`nginx`这一晦涩难懂的部分之后，再去开发第三方模块。

上面提到的内容中需要注意的一点，内存缓冲区是为连接的整个生命周期分配的，所以对于长连接需要消耗额外的内存。同时，对于空闲的`keep alive`连接，`nginx`仅消耗`550`字节内存。将来的`nginx`版本可能进行优化以使长连接重用和共用内存缓冲区。

内存分配管理的任务由`nginx`内存池分配器完成。共享内存区用于存放接受互斥锁(`accept mutex`)，缓存元数据，`SSL`会话缓存，以及和带宽策略管理（限速）相关的信息。`Nginx`实现了`slab`分配器用于管理共享内存，提供了一系列锁机制（互斥锁和信号量），以允许安全地并发使用共享内存。为了组织复杂的数据结构，`nginx`也提供了红黑树的实现。红黑树用于在内存中保存缓存元数据，查找非正则`location`定义，以及其他一些任务。

不幸的是，上述内容从未以一致并且简单的方式介绍过，以致开发第三方模块的工作相当复杂。虽然有一些`nginx`内部实现的好文档，例如，`Evan Miller`写的，但是这些文档需要做很多还原工作，`nginx`模块的开发还是像变魔术一样。

虽然开发第三方模块是如此困难，`nginx`社区最近还是涌现大量有用的第三方模块。例如，将`Lua`解释器嵌入`nginx`，负载均衡附加模块，完整的`Web DAV`支持，高级缓存控制，以及其他本章作者所鼓励和将来支持的有趣的第三方工作。

## 4.5 优秀实践 ##

`Igor Sysoev`开始编写`nginx`时，大部分构建互联网的软件都已经存在，这些软件的架构一般遵循传统服务器和网络硬件、操作系统、以及过去互联网架构的定义。但是这并未阻止`Igor`考虑在`web`服务器领域做进一步的工作。所以，显然第一个优秀实践是：总有提升空间。

带着开发更好`web`软件的想法，`Igor`花了很多时间开发原始代码结构，并研究在多个操作系统下优化代码的不同手段。十年后，考虑到1.0版本已经经过十年活跃开发，Igor开发了2.0版本原型。很明显，这个新架构的初始原型和代码结构，对于软件的后续开发及其重要。

另外值得提到的一点是聚焦开发。`Nginx` 的`windows`版本是个好例子，说明无论在开发者的核心技能或应用目标上避免稀释开发工作是值得的。同样努力加强`nginx`重写引擎对现存遗留配置的后向兼容能力，也是值得的。

最后特别值得提到的是，尽管`nginx`开发者社区并不大，`nginx`的第三方模块和扩展还是成为`nginx`受欢迎的一个很重要的因素。`Nginx`用户社区和作者们很感谢`Evan Miller`, `Piotr Sikora, Valery Kholodkov, Zhang Yichun (agentzh)`以及其他优秀软件工程师所做的工作。

英文原文：http://www.aosabook.org/en/nginx.html

中文参考：http://www.ituring.com.cn/article/4436

[20190916172718573.png]: /images/20210626/e63f3c2a3e574229ad204a3b86d87749.png