简介
APACHE和NGINX是世界上最常见的两个开源Web服务器。它们加在一起，负责为超过50%的互联网流量提供服务。这两种解决方案都能够处理不同的工作负载，并与其他软件配合使用，以提供完整的Web堆栈。
虽然阿帕奇和Nginx有许多共同之处，但它们不应该被认为是完全可以互换的。它们各有长处，本文将介绍它们各自的长处和短处。
概述
在我们深入研究APACHE和Nginx之间的差异之前，让我们先快速了解一下这两个项目的背景和它们的一般特征。
阿帕奇!
阿帕奇HTTP服务器由Robert McCool于1995年创建，自1999年以来一直在阿帕奇软件基金会的指导下开发。由于HTTP网络服务器是基金会的原始项目，也是迄今为止基金会最受欢迎的软件，因此它通常被简称为阿帕奇。
至少从1996年到2016年，阿帕奇网络服务器一直是互联网上最受欢迎的服务器。由于这种受欢迎程度，Apache受益于来自其他软件项目的优秀文档和集成支持。
Apache经常被管理员选择，因为它的灵活性，功能和近乎通用的支持。它可以通过一个动态可扩展的模块系统进行扩展，并且可以直接服务于许多脚本语言，如PHP，而不需要额外的软件。
Nginx
2002年，Igor Sysoev开始在Nginx上工作，以解决C10K问题，这是Web服务器能够处理一万个并发连接的一个突出挑战。Nginx于2004年公开发布，并通过依赖异步，事件驱动的架构实现了这一目标。
自那以后，Nginx的受欢迎程度已经超过了阿帕奇，这是因为它的轻量级占地面积和在最小硬件上轻松扩展的能力。Nginx擅长快速提供静态内容，拥有自己强大的模块系统，并可以根据需要将动态请求代理给其他软件。
Nginx经常被管理员选择，因为它的资源效率和负载下的响应能力，以及它简单明了的配置语法。
连接处理架构
APACHE和Nginx之间的一个不同之处在于它们处理连接和网络流量的具体方式。这可能是他们在负荷下做出反应的方式中最显著的区别。
阿帕奇!
阿帕奇提供了各种多处理模块(阿帕奇称之为这些MPM)，它们规定了如何处理客户端请求。这允许管理员配置其连接处理体系结构。它们是：
- MPM_PREFORK ：该处理模块生成进程，每个进程都有一个线程来处理请求。每个孩子一次可以处理一个连接。只要请求数少于进程数，这种MPM就非常快。但是，在请求数超过进程数后，性能会迅速下降，因此在许多情况下，这不是一个好的选择。每个进程都对内存消耗有很大影响，所以这种MPM很难有效扩展。不过，如果与其他没有考虑线程的组件一起使用，这可能仍然是一个很好的选择。例如，PHP并不总是线程安全的，所以这个MPM被推荐为使用
mod_php的一种安全方式，mod_php是处理这些文件的Apache模块。 - MPM_Worker ：该模块派生进程，每个进程可以管理多个线程。这些线程中的每一个都可以处理单个连接。线程比进程效率高得多，这意味着这种MPM的伸缩性比prefork MPM更好。由于线程比进程多，这也意味着新连接可以立即占用空闲线程，而不必等待空闲进程。
- MPM_EVENT ：该模块在大多数情况下类似于Worker模块，但针对保活连接进行了优化。当使用工作MPM时，只要连接保持活动状态，连接将保持一个线程，而不管请求是否处于活动状态。事件MPM通过留出专用线程来处理保持活动连接并将活动请求传递给其他线程来处理保持活动连接。这使模块不会因保持活动请求而陷入困境，从而可以更快地执行。
Apache为选择不同的连接和请求处理算法提供了灵活的体系结构。提供的选择主要取决于服务器的发展，以及随着互联网格局的变化对并发需求的日益增长。
Nginx
Nginx是在阿帕奇之后出现的，它更多地意识到了站点在规模上面临的并发问题。因此，Nginx从一开始就被设计为使用异步、非阻塞、事件驱动的连接处理算法。
Nginx派生工作进程，每个工作进程可以处理数千个连接。工作进程通过实现连续检查和处理事件的快速循环机制来实现这一点。将实际工作与连接分离，允许每个工作人员仅在触发新事件时才关注连接。
由辅助进程处理的每个连接都放置在事件循环中。在循环内，事件以异步方式处理，从而允许以非阻塞方式处理工作。当连接关闭时，它将从循环中删除。
这种连接处理风格允许Nginx在有限资源的情况下进行扩展。由于服务器是单线程的，并且不会派生进程来处理每个新连接，因此内存和CPU使用率往往保持相对一致，即使在负载较重的时候也是如此。
静态与动态内容对比
就现实世界的用例而言，最常见的Apache和Nginx比较之一是每个服务器处理静态和动态内容请求的方式。
阿帕奇!
阿帕奇服务器可以使用其传统的基于文件的方法处理静态内容。这些操作的性能主要取决于上述MPM方法。
通过将相关语言的处理器嵌入到它的每个Worker实例中，Apache还可以处理动态内容。这允许它在Web服务器本身内执行动态内容，而不必依赖外部组件。可以通过使用可动态加载的模块来启用这些动态处理器。
阿帕奇在内部处理动态内容的能力是LAMP(L INUX-** A** PACHE-* ** M** YSQL-** P** HP)体系结构流行的直接原因，因为PHP代码可以由Web服务器本身本地执行。
Nginx
Nginx没有任何本机处理动态内容的能力。要处理PHP和其他对动态内容的请求，Nginx必须将请求传递给外部库以执行，并等待返回输出。然后可以将结果传递给客户。
这些请求必须由Nginx和外部库使用Nginx知道如何说话的协议之一(http、FastCGI、SCGI、uWSGI、Memcache)进行交换。在实践中，PHP-FPM，是一种FastCGI实现，通常是一个临时解决方案，但在实践中，它并没有与任何特定的语言紧密结合。
然而，这种方法也有一些优点。因为动态解释器没有嵌入到工作进程中，所以它的开销只会用于动态内容。静态内容可以以直截了当的方式提供，只有在需要时才会联系解释器。
分布式配置与集中式配置
在允许基于每个目录的覆盖的方法上，Apacheand Nginx有很大的不同。
阿帕奇!
通过检查和解释内容目录本身的隐藏文件中的指令，Apache包含一个选项，允许在每个目录的基础上进行附加配置。这些文件称为.htacces文件。
由于这些文件本身驻留在内容目录中，因此在处理请求时，Apache会检查所请求文件路径的每个组件中是否有.htacces文件，并应用中找到的指令。这有效地允许分散配置Web服务器，该Web服务器通常用于实现URL重写、访问限制、授权和认证，甚至缓存策略。
虽然以上示例都可以在主APACHE配置文件中配置，但.htacces文件有一些重要的优势。首先，由于每次沿着请求路径找到它们时都会对它们进行解释，因此无需重新加载服务器即可立即实现它们。其次，它使得允许非特权用户控制他们自己的Web内容的某些方面成为可能，而不是让他们控制整个配置文件。
这为某些Web软件(如内容管理系统)提供了一种简单的方法来配置其环境，而无需提供对中央配置文件的访问。共享主机提供商也使用它来保持对主配置的控制，同时让客户端控制其特定的目录。
Nginx
Nginx不解释.htacces文件，也不提供任何机制来评估主配置文件之外的每个目录的配置。最初开发Apache时，在一台服务器上并行运行多个不同的Web部署是有利的，授权权限是有意义的。Nginx开发的时候，单个部署更有可能是集装化的，并附带自己的网络配置，从而将这种需求降至最低。在某些情况下，这可能不如阿帕奇模型灵活，但它确实有自己的优势。
与目录级配置的.htacces系统相比，最显著的改进是性能提高。对于可能允许在任何目录中使用.htacces的典型阿帕奇设置，对于每个请求，服务器将在指向所请求文件的每个父目录中检查这些文件。如果在此搜索过程中找到一个或多个.htacces文件，则必须读取并解释这些文件。通过不允许目录覆盖，Nginx可以通过以下方式更快地满足请求
对每个请求执行单个目录查找和文件读取(假设文件是在常规目录结构中找到的)。
另一个优势是与安全相关的。分发目录级配置访问权限还会将安全责任分配给个人用户，这些用户可能不被信任能够很好地处理此任务。请记住，如果您对这些问题产生共鸣，则可以在Apache中关闭.htacces解释。
文件VS URI解读
Web服务器如何解释请求并将它们映射到系统上的实际资源是这两个服务器的另一个不同之处。
阿帕奇!
Apache提供了将请求解释为文件系统上的物理资源或可能需要更抽象评估的URI位置的能力。一般来说，对于前者，Apache使用<Directory>或<Files>块，而 块。
因为Apache从头开始就被设计为Web服务器，所以默认情况下通常将请求解释为文件系统资源。它首先获取文档根目录，然后将请求的一部分附加到主机和端口号之后，以尝试查找实际的文件。从本质上讲，文件系统层次结构在Web上表示为可用文档树。
当请求与底层文件系统不匹配时，Apache提供了许多替代方案。例如，可以使用Alias指令映射到替代位置。使用<Location>块是使用URI本身而不是文件系统的一种方法。还有一些正则表达式变体可用于在整个文件系统中更灵活地应用配置。
虽然Apache有能力在底层文件系统和其他Web URI上操作，但它非常倾向于使用文件系统方法。这可以在一些设计决策中看到，包括使用.htacces文件进行按目录配置。当请求镜像底层文件系统时，apache docs自己警告不要使用基于URI的块来限制访问。
Nginx
Nginx被创建为既是Web服务器又是代理服务器。由于这两个角色所需的体系结构，它主要使用URI，在必要时转换为文件系统。
这在Nginx配置文件的构造和解释方式中很明显。Nginx不提供为文件系统目录指定配置的机制，而是解析URI本身。
例如，Nginx的主配置块是server和Location块。server块解释被请求的主机，而Location块负责匹配主机和端口之后的URI部分。此时，请求被解释为URI，而不是文件系统上的位置。
对于静态文件，所有请求最终都必须映射到文件系统上的某个位置。首先，Nginx选择将处理请求的服务器和位置块，然后将文档根目录与URI组合在一起，根据指定的配置调整任何必要的内容。
这可能看起来很相似，但将请求主要作为URI而不是文件系统位置进行解析使Nginx能够更轻松地在Web、邮件和代理服务器角色中运行。Nginx通过布局如何响应不同的请求模式进行配置。Nginx在准备好服务请求之前不会检查文件系统，这就解释了为什么它不实现一种形式的.htacces文件。
联合使用APACHE和Nginx
在回顾了Apache和Nginx的优点和局限性之后，您可能会更好地了解哪种服务器更适合您的需求。在某些情况下，可以通过一起使用每台服务器的优势来利用它们。
这种伙伴关系的传统配置是将Nginx作为反向代理放在Apache前面。这将允许Nginx处理所有客户端请求。这利用了Nginx的快速处理速度和并发处理大量连接的能力。
对于Nginx擅长的静态内容，文件或其他指令将快速而直接地提供给客户端。对于动态内容，例如PHP文件，Nginx会将请求代理给Apache，然后后者可以处理结果并返回呈现的页面。然后，Nginx可以将内容传递回客户端。
这种设置对许多人来说都很好用，因为它允许Nginx充当分拣机。它将处理它能处理的所有请求，并传递它本身没有能力处理的请求。通过减少要求ApacheServer处理的请求，我们可以减轻当一个Apache进程或线程被占用时发生的一些阻塞。
此配置还通过根据需要添加额外的后端服务器来促进水平扩展。可以将Nginx配置为将请求传递到多个服务器，从而提高此配置的性能。
结论
Apache和Nginx都是强大、灵活和有能力的。决定哪个服务器最适合您主要是评估您的特定需求和使用您期望看到的模式进行测试的功能。
这些项目之间存在差异，这些差异对在生产中使用任一解决方案所需的原始性能、功能和实现时间都有非常真实的影响。使用最符合您的目标的解决方案。