nginx 为什么如此优秀

nginx（发音为“engine x”），是一个免费的开源 Web 服务器，由俄罗斯软件工程师 Igor Sysoev 编写。自 2004 年公开发布以来，nginx 一直专注于高性能，高并发性和低内存使用。

nginx 有多优秀？ 根据 Netcraft 公司 2019 年 8 月发布的 Web Server Survey 系列调研报告，nginx 的市场份额排第一。

Web 服务器功能之上的其他功能，如负载平衡，缓存，访问和带宽控制，以及与各种应用程序高效集成的能力，有助于使 nginx 成为现代网站架构的不错选择。目前，nginx 是互联网上第二大最受欢迎的开源 Web 服务器。

为什么高并发性很重要？

如今，互联网如此广泛和无处不在，很难想象它不是十年前我们所知道的那样。从简单的 HTML 生成可点击文本，然后是 Apache Web 服务器，到全球超过 20 亿用户使用的永远在线的通信媒体，它已经有了很大的发展。随着 PC，移动设备和最近的平板电脑的激增，互联网领域正在迅速变化，整个经济已经成为数字连线。在线服务变得更加精细，明显偏向即时可用的实时信息和娱乐。运行在线业务的安全方面也发生了重大变化。因此，网站现在比以前复杂得多。

网站架构师面临的最大挑战之一就是并发。 我想你一定听说过 C10k 问题，就是 client 10000 问题，即在同时连接到服务器的客户端数量超过 10000 个的环境中，即使硬件性能足够，依然无法提供正常服务，就是单机 1 万个并发连接问题。

随着海量的客户端出现，手机、电脑、平板、穿戴设备、智能家具等等，服务器不具有高并发的处理能力，就无法在今天的竞争中胜出。

Apache不合适吗？

Apache，这种网络服务器软件在很大程度上仍然主宰着互联网，它的根源在于 20 世纪90 年代初。最初，它的架构与当时存在的操作系统和硬件相匹配，但也与互联网状态相匹配，其中网站通常是运行单个 Apache 实例的独立物理服务器。到了 2000 年代初，很明显，无法轻松复制独立的 Web 服务器模型以满足不断增长的 Web 服务的需求。尽管Apache 为未来的开发提供了坚实的基础，但它的架构是为每个新连接生成自己的副本，这不适合网站的非线性可伸缩性。最终，Apache成为了一个通用的Web服务器，专注于拥有许多不同的功能，各种第三方扩展，并且普遍适用于几乎任何类型的Web应用程序开发。然而，没有任何代价，在单个软件中拥有如此丰富和通用的工具组合的缺点是可扩展性较差，因为每个连接的CPU和内存使用量增加。

因此，当服务器硬件，操作系统和网络资源不再成为网站增长的主要限制时，全球的Web开发人员开始寻找更有效的运行Web服务器的方法。大约十年前，杰出的软件工程师Daniel Kegel 宣称 “现在是Web服务器同时处理一万个客户端的时候了”，并预测了我们现在称之为Internet云服务的东西。凯格尔的C10K清单激发了许多尝试来解决网络服务器优化问题，同时处理大量客户端，而nginx成为最成功的客户之一。

旨在解决10,000个同时连接的C10K问题，nginx在编写时考虑了不同的体系结构 - 一个更适合同时连接数和每秒请求数的非线性可伸缩性。nginx是基于事件的，因此它不遵循Apache为每个网页请求生成新进程或线程的风格。最终结果是，即使负载增加，内存和CPU使用仍然可以管理。nginx现在可以在具有典型硬件的服务器上提供数万个并发连接。

当nginx的第一个版本发布时，它意味着与Apache一起部署，使得静态内容（如HTML，CSS，JavaScript和图像）由nginx处理，以卸载基于Apache的应用程序服务器的并发和延迟处理。在开发过程中，nginx通过使用FastCGI，uswgi或SCGI协议以及分布式内存对象缓存系统（如memcached）增加了与应用程序的集成 。还添加了其他有用的功能，例如具有负载平衡和缓存的反向代理。这些附加功能使nginx成为有效的工具组合，可构建可扩展的Web基础架构。

nginx 为什么如此优秀

以高性能和高效率处理高并发性始终是部署 nginx 的关键优势。但是，还有更多。

nginx 提供了延迟处理，SSL（安全套接字层），静态内容，压缩和缓存，连接和请求限制，甚至来自应用程序的 HTTP 媒体流所需的关键功能层到更有效的边缘Web服务器层。它还允许直接与 memcached / Redis或其他“NoSQL”解决方案集成，以在为大量并发用户提供服务时提高性能。

nginx 在 2004 年，它根据双条款 BSD 许可证向公众发布。从那时起，nginx 用户的数量一直在增长，提供想法，并提交对整个社区非常有帮助和有益的错误报告、建议。

nginx 代码库是原创的，完全是用 C 编程语言从头开始编写的。nginx已被移植到许多架构和操作系统，包括L inux，FreeBSD，Solaris，Mac OS X，AIX 和Microsoft Windows。nginx 有自己的库，其标准模块除了 zlib，PCRE和OpenSSL之外不会超出系统的 C 库，除非 zlib，PCRE 和 OpenSSL 可以选择从构建中排除。

代码结构

nginx worker代码包括核心和功能模块。nginx的核心是负责维护一个紧密的运行循环，并在每个请求处理阶段执行模块代码的适当部分。模块构成了大部分表示和应用程序层功能。模块读取和写入网络和存储，转换内容，执行出站过滤，应用服务器端包含操作，并在激活代理时将请求传递给上游服务器。

nginx的模块化架构通常允许开发人员在不修改nginx核心的情况下扩展Web服务器功能集。nginx模块的版本略有不同，即核心模块，事件模块，阶段处理程序，协议，变量处理程序，过滤器，上游和负载平衡器。目前，nginx不支持动态加载的模块; 即，模块在构建阶段与核心一起编译。

nginx 架构

image

nginx配置

nginx的配置系统的灵感来自 Igor Sysoev 的 Apache 经验。他的主要观点是可扩展的配置系统对于 Web 服务器至关重要。在维护包含大量虚拟服务器，目录，位置和数据集的大型复杂配置时遇到了主要的扩展问题。在相对较大的 Web 设置中，如果在应用程序级别和系统工程师自己都没有正确完成，则可能是一场噩梦。

因此，nginx配置旨在简化日常操作，并为进一步扩展Web服务器配置提供简便的方法。

nginx配置保存在许多纯文本文件中，这些文件通常位于/usr/local/etc/nginx或中 /etc/nginx。通常调用主配置文件nginx.conf。为了保持整洁，可以将部分配置放在单独的文件中，这些文件可以自动包含在主文件中。但是，应该注意的是，nginx目前不支持Apache风格的分布式配置（即 .htaccess文件）。与nginx Web服务器行为相关的所有配置都应驻留在一组集中的配置文件中。

配置文件最初由主进程读取和验证。nginx配置的已编译只读形式可供worker进程使用，因为它们是从主进程分叉的。配置结构由通常的虚拟内存管理机制自动共享。

nginx的配置有几种不同的情况下进行main， http，server，upstream，location（也 mail用于邮件代理）指令块。上下文从不重叠。例如，没有location在main指令块中放置块的事情 。此外，为了避免不必要的歧义，没有像“全局Web服务器”配置那样的东西。nginx配置意味着干净且合乎逻辑，允许用户维护包含数千个指令的复杂配置文件。在私人谈话中，Sysoev说，“全局服务器配置中的位置，目录和其他块是我从未在Apache中喜欢的功能，所以这就是为什么它们从未在nginx中实现的原因。”

配置语法，格式和定义遵循所谓的C风格约定。制作配置文件的这种特殊方法已经被各种开源和商业软件应用程序使用。通过设计，C风格的配置非常适合嵌套描述，具有逻辑性，易于创建，读取和维护，并且受到许多工程师的喜爱。nginx的C风格配置也可以轻松实现自动化。

虽然一些nginx指令类似于Apache配置的某些部分，但是设置nginx实例是一种完全不同的体验。例如，nginx支持重写规则，但需要管理员手动调整遗留Apache重写配置以匹配nginx样式。重写引擎的实现也不同。

通常，nginx设置还支持几种原始机制，这些机制作为精简Web服务器配置的一部分非常有用。简单地提一下变量和try_files指令是有意义的 ，它们对nginx来说有些独特。开发了nginx中的变量，以提供额外的更强大的机制来控制Web服务器的运行时配置。变量针对快速评估进行了优化，并在内部预编译为索引。评估是按需进行的; 即，变量的值通常仅计算一次并在特定请求的生命周期内缓存。变量可以与不同的配置指令一起使用，为描述条件请求处理行为提供了额外的灵活性。