Apache 与 Nginx：优势和缺点

本文介绍: Apache 和 Nginx 是世界上最常见的两种开源 Web 服务器。它们共同负责提供超过 50% 的互联网流量。这两种解决方案都能够处理不同的工作负载，并与其他软件配合提供完整的网络堆栈。虽然 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 可以通过为每个请求执行单个目录查找和文件读取（假设在传统目录结构中找到该文件）来更快地服务请求。

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