多进程模式，会有一个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资源，从而带来不必要的上下文切换。

怎样操作运行的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进程发送信号一样。

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

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

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时，就不去尝试获取锁，等于让出获取连接的机会。这样就可以控制多进程间连接的平衡了。

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的优势非常大。

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

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 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架构的高层设计。