Apache 与 Nginx：优势和缺点

前些天发现了一个人工智能学习网站，通俗易懂，风趣幽默，最重要的屌图甚多，忍不住分享一下给大家。点击跳转到网站。

Apache 与 Nginx：优势和缺点

介绍

Apache 和 Nginx 是世界上最常见的两种开源 Web 服务器。它们共同负责提供超过 50% 的互联网流量。这两种解决方案都能够处理不同的工作负载，并与其他软件配合提供完整的网络堆栈。

虽然 Apache 和 Nginx 有许多共同的特点，但它们不被认为是完全可以互换的。每个都有自己的优势，本文将介绍他们的优点和缺点。

总体概述

在我们深入探讨 Apache 和 Nginx 之间的差异之前，让我们快速了解一下这两个项目的背景及其一般特征。

Apache

Apache HTTP 服务器由 Robert McCool 于 1995 年创建，自 1999 年以来一直在 Apache 软件基金会的指导下开发。由于 HTTP Web 服务器是该基金会的原始项目，并且是迄今为止他们最受欢迎的软件，因此它经常被简称为“阿帕奇”。

至少从 1996 年到 2016 年，Apache Web 服务器是互联网上最受欢迎的服务器。由于这种流行，Apache 受益于来自其他软件项目的大量文档和集成支持。

Apache 通常因其灵活性、强大功能和近乎普遍的支持而被管理员选择。它可以通过动态加载模块系统进行扩展，并且可以直接服务于许多脚本语言，例如PHP，而不需要额外的软件。

nginx

2002 年，Igor Sysoev 开始研究 Nginx，作为 C10K 问题的答案，这对于 Web 服务器能够处理一万个并发连接来说是一个巨大的挑战。Nginx 于 2004 年公开发布，并通过依赖异步、事件驱动的架构实现了这一目标。

由于其轻量级的占用空间以及在最少的硬件上轻松扩展的能力，Nginx 的受欢迎程度已经超过了 Apache。Nginx 擅长快速提供静态内容，拥有自己强大的模块系统，并且可以根据需要将动态请求代理给其他软件。

Nginx 通常因其资源效率和负载响应能力以及简单的配置语法而被管理员选择。

连接处理架构

Apache 和 Nginx 之间的区别之一是它们处理连接和网络流量的特定方式。这可能是它们在负载下响应方式上最显着的差异。

Apache

Apache 提供了各种多处理模块（Apache 称之为 MPM）来规定如何处理客户端请求。允许管理员配置其连接处理架构。这些都是：

mpm_prefork：此处理模块生成每个进程具有单个线程来处理请求。每个子进程一次可以处理一个连接。只要请求数少于进程数，这个MPM就非常快。然而，当请求超过进程数后，性能会迅速下降，因此在很多场景下这并不是一个好的选择。每个进程都会对 RAM 消耗产生重大影响，因此这种 MPM 很难有效扩展。不过，如果与其他未考虑线程构建的组件结合使用，这可能仍然是一个不错的选择。例如，PHP 并不总是线程安全的，因此建议将 MPM 作为使用Apache 模块（用于处理这些文件）的安全方式。
mpm_worker：该模块生成可以管理多个线程的进程。这些线程中的每一个都可以处理单个连接。线程比进程高效得多，这意味着该 MPM 的扩展性比 prefork MPM 更好。由于线程多于进程，这也意味着新连接可以立即占用空闲线程，而不必等待空闲进程。
mpm_event：此模块在大多数情况下与工作模块类似，但针对处理保持活动连接进行了优化。使用工作 MPM 时，只要连接保持活动状态，无论是否主动发出请求，连接都会保留一个线程。事件 MPM 通过留出专用线程来处理保持活动连接并将活动请求传递给其他线程来处理保持活动连接。这可以防止模块因保持活动请求而陷入困境，从而加快执行速度。

Apache 提供了灵活的架构来选择不同的连接和请求处理算法。所提供的选择主要取决于服务器的发展以及随着互联网环境的变化对并发性的需求不断增加。

nginx

Nginx 在 Apache 之后出现，更多地意识到站点大规模面临的并发问题。因此，Nginx 从一开始就被设计为使用异步、非阻塞、事件驱动的连接处理算法。

Nginx 产生工作进程，每个进程可以处理数千个连接。工作进程通过实现连续检查和处理事件的快速循环机制来实现这一点。将实际工作与连接分离允许每个工作人员仅在触发新事件时才关注连接。

由工作线程处理的每个连接都放置在事件循环中。在循环内，事件被异步处理，从而允许以非阻塞方式处理工作。当连接关闭时，它将从循环中删除。

这种连接处理方式允许 Nginx 在有限的资源下进行扩展。由于服务器是单线程的，并且不会生成进程来处理每个新连接，因此即使在负载较重时，内存和 CPU 使用率也往往保持相对一致。

静态内容与动态内容

就现实世界的用例而言，Apache 和 Nginx 之间最常见的比较之一是每个服务器处理静态和动态内容请求的方式。

Apache

Apache 服务器可以使用其传统的基于文件的方法处理静态内容。这些操作的性能主要是上述 MPM 方法的函数。

Apache 还可以通过将相关语言的处理器嵌入到其每个工作实例中来处理动态内容。这使得它能够在 Web 服务器本身内执行动态内容，而无需依赖外部组件。这些动态处理器可以通过使用动态可加载模块来启用。

Apache 内部处理动态内容的能力是 LAMP（ L inux -A pache- MySQL - PHP ）架构流行的直接贡献者，因为 PHP 代码可以由 Web 服务器本身本地执行。

nginx

Nginx 本身不具备处理动态内容的能力。为了处理 PHP 和其他动态内容请求，Nginx 必须将请求交给外部库来执行，并等待输出返回。然后可以将结果转发给客户端。

这些请求必须由 Nginx 和外部库使用 Nginx 知道如何使用的协议之一（http、FastCGI、SCGI、uWSGI、memcache）进行交换。在实践中，PHP-FPM（一种 FastCGI 实现）通常是一种即插即用的解决方案，但 Nginx 在实践中并不与任何特定语言紧密结合。

然而，这种方法也有一些优点。由于动态解释器没有嵌入到工作进程中，因此它的开销只会出现在动态内容中。静态内容可以以直接的方式提供，并且仅在需要时才会联系口译员。

分布式与集中式配置

Apache 和 Nginx 在允许基于每个目录进行覆盖的方法方面存在显着差异。

Apache

Apache 包含一个选项，允许通过检查和解释内容目录本身内的隐藏文件中的指令，在每个目录的基础上进行附加配置。这些文件称为.htaccess文件。

由于这些文件本身驻留在内容目录中，因此在处理请求时，Apache 会检查所请求文件的路径的每个组成部分，并应用其中找到的指令。这有效地允许了 Web 服务器的分散配置，通常用于实现 URL 重写、访问限制、授权和身份验证，甚至缓存策略。

虽然上面的示例都可以在主 Apache 配置文件中进行配置，但.htaccess文件有一些重要的优点。首先，由于每次沿着请求路径找到它们时都会对其进行解释，因此它们会立即实现，而无需重新加载服务器。其次，它使得非特权用户可以控制自己的 Web 内容的某些方面，而无需让他们控制整个配置文件。

这为某些 Web 软件（如内容管理系统）提供了一种简单的方法来配置其环境，而无需提供对中央配置文件的访问。共享托管提供商也使用它来保留对主配置的控制，同时让客户端控制其特定目录。

nginx

Nginx 不解释.htaccess文件，也不提供任何评估主配置文件之外的每个目录配置的机制。Apache 最初开发的时候，在单个服务器上并行运行许多异构 Web 部署是有利的，并且委派权限是有意义的。Nginx 是在单个部署更有可能被容器化并附带自己的网络配置的时候开发的，从而最大限度地减少了这种需求。在某些情况下，这可能不如 Apache 模型灵活，但它确实有自己的优点。

.htaccess目录级配置系统最显着的改进是性能的提高。对于可能允许在任何目录中的典型 Apache 设置.htaccess，服务器将为每个请求检查指向所请求文件的每个父目录中的这些文件。如果.htaccess在此搜索过程中找到一个或多个文件，则必须读取并解释它们。通过不允许目录覆盖，Nginx 可以通过为每个请求执行单个目录查找和文件读取（假设在传统目录结构中找到该文件）来更快地服务请求。

另一个优点与安全相关。分配目录级配置访问权限还会将安全责任分配给各个用户，而这些用户可能不被信任能够很好地处理此任务。

文件与基于 URI 的解释

Web 服务器如何解释请求并将其映射到系统上的实际资源是这两种服务器的另一个不同之处。

Apache

Apache 能够将请求解释为文件系统上的物理资源或可能需要更抽象评估的 URI 位置。一般来说，以前的Apache使用<Directory>块<Files>，而它使用<Location>块来表示更抽象的资源。

由于 Apache 是从头开始设计的 Web 服务器，因此默认情况下通常将请求解释为文件系统资源。它首先获取文档根目录并在主机和端口号后面附加请求部分，以尝试查找实际文件。本质上，文件系统层次结构在网络上表示为可用的文档树。

当请求与底层文件系统不匹配时，Apache 提供了多种替代方案。例如，Alias指令可用于映射到替代位置。使用<Location>块是一种使用 URI 本身而不是文件系统的方法。还有正则表达式变体，可用于在整个文件系统中更灵活地应用配置。

虽然 Apache 能够在底层文件系统和其他 Web URI 上运行，但它严重依赖于文件系统方法。这可以从一些设计决策中看出，包括使用.htaccess文件进行每个目录的配置。当请求镜像底层文件系统时，Apache 文档本身警告不要使用基于 URI 的块来限制访问。

nginx

Nginx 被创建为 Web 服务器和代理服务器。由于这两个角色所需的架构，它主要与 URI 一起工作，并在必要时转换为文件系统。

这在 Nginx 配置文件的构建和解释方式中显而易见。Nginx 不提供指定文件系统目录配置的机制，而是解析 URI 本身。

例如，Nginx 的主要配置块是server和location块。该server块解释所请求的主机，而这些location块负责匹配主机和端口后面的 URI 部分。此时，请求被解释为 URI，而不是文件系统上的位置。

对于静态文件，所有请求最终都必须映射到文件系统上的某个位置。首先，Nginx 选择将处理请求的服务器和位置块，然后将文档根与 URI 结合起来，根据指定的配置调整任何必要的内容。

这看起来可能很相似，但主要将请求解析为 URI 而不是文件系统位置，使 Nginx 能够更轻松地在 Web、邮件和代理服务器角色中发挥作用。Nginx 的配置方式是规定如何响应不同的请求模式。Nginx 在准备好服务请求之前不会检查文件系统，这解释了为什么它不实现.htaccess文件形式。

一起使用 Apache 和 Nginx

在回顾了 Apache 和 Nginx 的优点和局限性之后，我们会更好地了解哪种服务器更适合需求。在某些情况下，可以通过一起使用每个服务器来发挥它们的优势。

这种伙伴关系的常规配置是将 Nginx 放置在 Apache 前面作为反向代理。这将允许 Nginx 处理所有客户端请求。这利用了 Nginx 快速的处理速度和并发处理大量连接的能力。

对于 Nginx 擅长的静态内容，文件或其他指令将快速直接地提供给客户端。对于动态内容，例如 PHP 文件，Nginx 会将请求代理给 Apache，然后 Apache 可以处理结果并返回呈现的页面。然后 Nginx 可以将内容传递回客户端。

这个设置对很多人来说都很有效，因为它允许 Nginx 充当排序机。它将处理它可以处理的所有请求，并传递它本身没有能力服务的请求。通过减少 Apache 服务器需要处理的请求，我们可以缓解 Apache 进程或线程被占用时发生的一些阻塞。

此配置还可以根据需要添加额外的后端服务器来促进水平扩展。Nginx 可以配置为将请求传递到多个服务器，从而提高此配置的性能。

结论

Apache 和 Nginx 都强大、灵活且功能强大。决定哪种服务器最适合主要取决于评估自身的特定需求并使用我们期望看到的模式进行测试。

这些项目之间存在差异，这些差异对生产中使用任一解决方案所需的原始性能、功能和实施时间产生非常实际的影响。使用最符合目标的解决方案。