介绍
Apache和Nginx是世界上两个最常见的开源Web服务器。 在一起，他们负责服务超过50％的流量在互联网上。 这两种解决方案都能够处理各种工作负载，并与其他软件合作，提供完整的Web。
虽然Apache和Nginx有许多共同点，但它们不应该被认为是完全可互换的。 每个都以自己的方式出色，重要的是要了解您可能需要重新评估您的选择的Web服务器的情况。 本文将专门讨论每个服务器在各个领域如何堆叠。
总体概述
在我们深入探讨Apache和Nginx之间的差异之前，让我们快速了解这两个项目的背景及其一般特性。
Apache
Apache HTTP Server是由Robert McCool于1995年创建的，自1999年以来一直在Apache软件基金会的指导下开发。由于HTTP Web服务器是基金会的原始项目，是迄今为止最受欢迎的软件，简称为“Apache”。
Apache Web服务器自1996年以来一直是互联网上最受欢迎的服务器。由于这种流行，Apache受益于伟大的文档和其他软件项目的集成支持。
Apache通常由管理员选择其灵活性，功能和广泛的支持。 它通过可动态加载的模块系统是可扩展的，并且可以处理大量的解释语言，而无需连接到单独的软件。
Nginx
在2002年，Igor Sysoev开始在Nginx上工作，作为解决C10K问题，这是一个挑战，Web服务器开始处理一万个并发连接作为现代网络的要求。 最初的公开发布是在2004年完成的，通过依赖一个异步的，事件驱动的架构来实现这个目标。
Nginx自从它的发布以来，由于其轻量级的资源利用和其在最小硬件上轻松扩展的能力已经变得流行。 Nginx擅长快速提供静态内容，旨在将动态请求传递到更适合这些目的的其他软件。
Nginx通常由管理员在负载下选择其资源效率和响应度。 倡导者欢迎Nginx的核心Web服务器和代理功能的重点。
连接处理架构
Apache和Nginx之间的一个巨大区别是它们处理连接和流量的实际方式。 这提供了或许在它们响应不同交通状况的方式的最显着的差异。
Apache
Apache提供了多种多处理模块（Apache调用这些MPM），它们决定如何处理客户端请求。 基本上，这允许管理员轻松地换出其连接处理体系结构。 这些是：
- mpm_prefork：该处理模块产生进程使用一个线程每个来处理请求。 每个孩子一次可以处理单个连接。 只要请求的数量少于进程的数量，这个MPM是非常快的。 但是，在请求超过进程数后，性能会快速下降，因此在许多情况下这不是一个好的选择。 每个进程对RAM消耗有显着影响，因此这个MPM难以有效地扩展。 这可能仍然是一个好的选择，虽然如果与其他组件使用，不是用线程构建。 举例来说，PHP是不是线程安全的，所以这个MPM被推荐为有工作的唯一安全的方法
mod_php，Apache的模块来处理这些文件。 - mpm_worker：该模块派生可在每个管理多个线程的进程。 这些线程中的每一个可以处理单个连接。 线程比进程更有效率，这意味着这个MPM比prefork的MPM更好。 由于线程比进程多，这也意味着新连接可以立即获取一个空闲线程，而不必等待一个空闲进程。
- mpm_event：此模块是类似于在大多数情况下，工人模块，但进行了优化，以处理保持活动连接。 当使用工作者MPM时，只要连接保持活动，连接将保持线程，而不管是否主动地进行请求。 事件MPM通过留出专用线程来处理保持活动连接并将活动请求传递到其他线程来保持活动连接。 这保持模块不被保持活动请求阻塞，允许更快的执行。 这与Apache 2.4的发布标志着稳定。
如您所见，Apache提供了一种灵活的架构，用于选择不同的连接和请求处理算法。 提供的选择主要是服务器的演变和随着互联网景观的变化对并发的需求的增加的功能。
Nginx
Nginx在Apache之后进入现场，更加意识到将面临大规模网站的并发性问题。 利用这些知识，Nginx从头开始设计，使用异步，非阻塞，事件驱动的连接处理算法。
Nginx生成工作进程，每个进程可以处理数千个连接。 工作进程通过实现连续检查和处理事件的快速循环机制来实现这一点。 将实际工作与连接分离允许每个工人仅在触发新事件时才关注连接。
由工作者处理的每个连接被放置在事件循环中，其中它们与其他连接一起存在。 在循环内，事件被异步处理，允许以非阻塞方式处理工作。 当连接关闭时，它将从环路中删除。
这种连接处理方式允许Nginx在有限的资源上扩展到令人难以置信的程度。 由于服务器是单线程的，并且不产生处理每个新连接的进程，所以即使在高负载时，内存和CPU使用趋向于保持相对一致。
静态与动态内容
在真实世界的用例中，Apache和Nginx之间最常见的比较是每个服务器处理静态和动态内容请求的方式。
Apache
Apache服务器可以使用其常规的基于文件的方法处理静态内容。 这些操作的性能主要是上述MPM方法的函数。
Apache还可以通过将所讨论的语言的处理器嵌入到其每个工作者实例中来处理动态内容。 这允许它在web服务器自身内执行动态内容，而不必依赖外部组件。 这些动态处理器可以通过使用动态可加载模块来启用。
Apache在内部处理动态内容的能力意味着动态处理的配置往往更简单。 通信不需要与附加的软件协调，并且如果内容需求改变，模块可以容易地被交换。
Nginx
Nginx没有任何能力来本地处理动态内容。 为了处理PHP和其他对动态内容的请求，Nginx必须传递到外部处理器进行执行，并等待渲染的内容被发回。 然后可以将结果中继到客户端。
对于管理员，这意味着必须通过Nginx知道如何说话（http，FastCGI，SCGI，uWSGI，memcache）的Nginx和处理器之间的通信配置。 这可能使事情稍微复杂，特别是当试图预期允许的连接的数量时，因为将对每个对处理器的调用使用附加的连接。
然而，该方法也具有一些优点。 由于动态解释器没有嵌入在工作进程中，它的开销将只存在于动态内容。 静态内容可以以直接的方式提供，并且只有在需要时才与解释器联系。 Apache也可以以这种方式运行，但这样做消除了上一节中的好处。
分布式vs集中式配置
对于管理员来说，这两个软件之间最明显的区别之一是内容目录中是否允许目录级配置。
Apache
Apache包括一个选项，通过检查和解释内容目录本身中隐藏文件中的指令，允许在每个目录上进行额外配置。 这些文件被称为.htaccess文件。
由于这些文件所驻留的内容目录本身内，处理请求时，Apache检查路径为所需的文件的各成分.htaccess文件并应用中找到的指令。 这有效地允许web服务器的分散配置，其通常用于实现URL重写，访问限制，授权和认证，甚至缓存策略。
虽然上述例子都可以在Apache主配置文件中配置.htaccess文件有一些重要的优点。 首先，因为每次在请求路径中找到它们时，它们被解释，所以它们被立即实现而不重新加载服务器。 第二，它允许非特权用户控制他们自己的web内容的某些方面，而不给他们控制整个配置文件。
这为某些网络软件（如内容管理系统）提供了一种简单的方法来配置其环境，而无需提供对中央配置文件的访问。 共享主机提供商还使用这一功能来保留对主配置的控制，同时允许客户端控制其特定目录。
Nginx
nginx的不解释.htaccess文件，也不用于评估主配置文件之外的每个目录的配置提供任何机制。 这可能比Apache模型更不灵活，但它确实有自己的优势。
在最显着的改进.htaccess目录级配置的系统来提高性能。 对于一个典型的Apache设置，可能会允许.htaccess在任何目录中，服务器将检查这些文件中的每个领导到所请求的文件中的父目录，为每个请求。 如果一个或多个.htaccess这个搜索过程中发现的文件，他们必须阅读和解释。 通过不允许目录覆盖，Nginx可以更快地提供请求
对每个请求进行单个目录查找和文件读取（假定该文件在常规目录结构中找到）。
另一个优点是安全相关。 分发目录级配置访问还将安全责任分配给个人用户，他们可能不被信任来很好地处理此任务。 确保管理员维护对整个Web服务器的控制可以防止当向其他方提供访问时可能发生的一些安全错误。
请记住，它有可能关闭.htaccess解释了Apache，如果这些问题与你的共鸣。
文件与基于URI的解释
Web服务器如何解释请求并将它们映射到系统上的实际资源是这两个服务器不同的另一个领域。
Apache
Apache提供将请求解释为文件系统上的物理资源或作为可能需要更抽象评估的URI位置的能力。 一般来说，前者Apache使用<Directory>或<Files>块，而它采用<Location>更多抽象的资源块。
因为Apache是从根本上设计为Web服务器，所以默认情况下通常将请求解释为文件系统资源。 它首先是获取文档根目录，然后在主机和端口号后面追加请求部分，以尝试找到一个实际的文件。 基本上，文件系统层次结构在Web上表示为可用的文档树。
当请求与底层文件系统不匹配时，Apache提供了许多替代方法。 例如，一个Alias指令可以用于映射到其他位置。 使用<Location>块与URI本身，而不是文件系统工作的方法。 还有正则表达式变体，可用于在整个文件系统中更灵活地应用配置。
虽然Apache有能力在底层文件系统和网络空间上操作，但它倾向于文件系统方法。 这可以在一些设计决定的可以看出，包括使用.htaccess文件每个目录结构。 在Apache的文档本身警告不要使用基于URI块当请求反映底层文件系统来限制访问。
Nginx
Nginx被创建为既是Web服务器又是代理服务器。 由于这两个角色需要的体系结构，它主要与URIs，在必要时转换到文件系统。
这可以从Nginx配置文件被构造和解释的一些方式中看到.Nginx不提供一种机制来指定文件系统目录的配置，而是解析URI本身。
例如，对于Nginx的主要配置块是server和location的块。 该server块解释被请求的主机，而location块负责匹配主机和端口后附带URI的部分。 在这一点上，请求被解释为URI，而不是作为文件系统上的位置。
对于静态文件，所有请求最终都必须映射到文件系统上的某个位置。 首先，Nginx选择将处理请求的服务器和位置块，然后将文档根与URI组合，根据指定的配置调整任何必要的内容。
这看起来类似，但是将请求主要解析为URI而不是文件系统位置允许Nginx更容易在Web，邮件和代理服务器角色中工作。 Nginx简单地通过布局如何响应不同的请求模式进行配置。 Nginx的不检查文件系统，直到它准备服务的请求，这可以解释为什么它没有实现的一种形式.htaccess文件。
模块
Nginx和Apache都可以通过模块系统扩展，但是它们的工作方式有很大不同。
Apache
Apache的模块系统允许您在运行服务器的过程中动态加载或卸载模块以满足您的需求。 Apache核心总是存在，而模块可以打开或关闭，添加或删除附加功能和挂接到主服务器。
Apache为大量的各种任务使用这个功能。 由于平台的成熟，有一个广泛的模块库可用。 这些可以用来改变一些服务器，如的核心功能mod_php ，其中嵌入了一个PHP解释到每个正在运行的工作。
然而，模块不限于处理动态内容。 除了其他功能，它们可以用于重写URL，认证客户端，强化服务器，日志记录，缓存，压缩，代理，速率限制和加密。 动态模块可以大大扩展核心功能，无需额外的工作。
Nginx
Nginx还实现了一个模块系统，但它与Apache系统截然不同。 在Nginx中，模块不是可动态加载的，因此必须选择它们并将其编译到核心软件中。
对于许多用户，这将使Nginx更不灵活。 这对于在其分发的传统封装系统之外不容易维护其自己的编译软件的用户尤其如此。 虽然发行版包倾向于包含最常用的模块，但如果您需要非标准模块，则必须自己从源代码构建服务器。
Nginx模块仍然是非常有用的，但它们允许你通过只包括你打算使用的功能来指定你想要的服务器。 一些用户也可能认为这更安全，因为任意组件不能挂接到服务器。 然而，如果你的服务器被放在一个可能的位置，它可能已经危害。
Nginx模块允许与Apache模块许多相同的功能。 例如，Nginx模块可以提供代理支持，压缩，速率限制，日志记录，重写，地理位置，认证，加密，流和邮件功能。
支持，兼容性，生态系统和文档
要考虑的一个要点是，启动和运行的实际过程将给予可用的帮助和其他软件支持的景观。
Apache
因为Apache已经流行了这么久，对服务器的支持是相当普遍的。 有一个大型的第一方和第三方文档库可用于核心服务器和基于任务的场景，包括用其他软件挂接Apache。
除了文档，许多工具和Web项目包括在Apache环境中引导自己的工具。 这可能包括在项目本身中，或包含在您的分发包装团队维护的包中。
一般来说，Apache将有更多的第三方项目的支持，只是因为它的市场份额和可用的时间长度。 管理员也较为容易有经验与Apache的工作不仅是因为它的流行，也是因为许多人在共享主机方案几乎完全依靠Apache由于开始.htaccess分布式管理能力。
Nginx
Nginx正在经历越来越多的支持，因为更多的用户采用它的性能配置文件，但它仍然有一些关键的一些关键领域。
在过去，很难找到关于Nginx的全面的英语文档，因为大多数早期开发和文档都是俄语。 随着项目的兴趣增加，文档已经填补，现在有大量的管理资源在Nginx网站和第三方。
关于第三方应用程序，支持和文档变得更容易获得，在某些情况下，软件包维护者开始为Apache和Nginx之间的自动配置提供选择。 即使没有支持，配置Nginx使用替代软件通常是直接的，只要项目本身记录其要求（权限，标题等）。
一起使用Apache和Nginx
在了解了Apache和Nginx的优点和局限之后，您可以更好地了解哪个服务器更适合您的需求。 然而，许多用户发现可以通过一起使用它们来利用每个服务器的优势。
这种合作的常规配置是将Nginx放在Apache前面作为反向代理。 这将允许Nginx处理来自客户端的所有请求。 这利用了Nginx的快速处理速度和同时处理大量连接的能力。
对于静态内容，Nginx擅长的，文件将被快速直接提供给客户端。 对于动态内容，例如PHP文件，Nginx将代理请求到Apache，然后Apache可以处理结果并返回呈现的页面。 Nginx然后可以将内容传递回客户端。
这个设置适用于许多人，因为它允许Nginx作为分拣机。 它将处理所有可能的请求，并传递它没有本机能力的服务。 通过减少请求，Apache服务器被要求处理，我们可以缓解Apache进程或线程被占用时发生的一些阻塞。
此配置还允许您通过根据需要添加其他后端服务器来向外扩展。 Nginx可以配置为轻松传递到服务器池，增加了此配置对故障和性能的恢复能力。
结论
正如你所看到的，Apache和Nginx都是强大，灵活和有能力的。 决定最适合您的服务器主要是评估您的特定需求和使用您期望看到的模式进行测试的功能。
这些项目之间存在差异，这对原始性能，功能和实现每个解决方案运行所需的实施时间有非常真实的影响。 然而，这些通常是一系列折衷的结果，这些折衷不应该被随便否定。 最后，没有一个适合所有的Web服务器，因此使用最符合您的目标的解决方案。
