Nginx系列一：概念和配置

Nginx系列一：概念和配置
Nginx系列二: Nginx 的数据结构
Nginx系列三: Nginx 高级数据结构
Nginx系列四: Nginx的配置指令和handler模块概述
Nginx系列五: handler 模块

1. 功能介绍

• 基本的 HTTP 服务器功能

• 邮件代理服务器功能

• TCP/UDP 代理服务器功能

• 架构和可扩展性

2.Nginx 特性

NGINX 有什么不同？ NGINX 使用可扩展的事件驱动架构，而不是更传统的过程驱动架构。这需要更低的内存占用，并且当并发连接扩大时，使内存使用更可预测。在传统的 Web 服务器体系结构中，每个客户端连接作为一个单独的进程或线程处理，随着网站的流行度增加，并发连接数量的增加， Web 服务器减慢，延迟了对用户的响应。从技术的角度来看，产生一个单独的进程/线程需要将 CPU 切换到新的任务并创建一个新的运行时上下文，消耗额外的内存和 CPU 时间，从而对性能产生负面影响。NGINX 开发的目标是实现 10 倍以上的性能，优化服务器资源的使用，同时也能够扩展和支持网站的动态增长。 因此， NGINX 成为最知名的模块化，事件驱动，异步，单线程 Web 服务器和 Web 代理之一。

Nginx 是一个高性能的 Web 和反向代理服务器, 它具有很多非常优越的特性:

作为 Web 服务器

相比 Apache， Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，这点使 Nginx尤其受到虚拟主机提供商的欢迎。能够支持高达 50,000 个并发连接数的响应，感谢 Nginx为我们选择了 epoll and kqueue 作为开发模型。

作为负载均衡服务器

Nginx 既可以在内部直接支持 Rails 和 PHP，也可以支持作为 HTTP 代理服务器 对外进行服务。 Nginx 用 C 编写, 不论是系统资源开销还是 CPU 使用效率都比 Perlbal 要好的多。

作为邮件代理服务器

Nginx 同时也是一个非常优秀的邮件代理服务器(最早开发这个产品的目的之一也是作为邮件代理服务器)， Last.fm 描述了成功并且美妙的使用经验。Nginx 安装非常的简单，配置文件 非常简洁(还能够支持 perl 语法)， Bugs 非常少的服务器:
Nginx 启动特别容易，并且几乎可以做到 7*24 不间断运行，即使运行数个月也不需要重新启动。你还能够在 不间断服务的情况下进行软件版本的升级 。

3. Nginx 架构

​ 处理并发连接的传统的基于进程或线程的模型涉及使用单独的进程或线程处理每个连接，并阻止网络或输入/输出操作。 根据应用，在内存和 CPU 消耗方面可能非常低效。 产生一个单独的进程或线程需要准备一个新的运行时环境，包括分配堆和堆栈内存，以及创建新的执行上下文。 额外的 CPU 时间也用于创建这些项目，这可能会导致由于线程在过多的上下文切换上的转机而导致性能下降。 所有这些并发症都表现在较老的 Web 服务器架构(如 Apache)中。 这是提供丰富的一般应用功能和优化的服务器资源使用之间的一个折衷。从一开始 nginx 就是一个专门的工具，可以实现更高性能，更密集和经济地使用服务器资源，同时实现网站的动态发展，所以它采用了不同的模式。 它实际上受到各种操作系统中高级事件机制的不断发展的启发。发展结果变成是一个模块化的，事件驱动的，异步的，单线程的非阻塞架构的 nginx 代码基础。nginx 大量使用复用和事件通知，并专门用于分离进程的特定任务。 连接在有限数量的单线程进程称为工作(worker)的高效运行循环中处理。 在每个工作(worker)中， nginx 可以处理每秒数千个并发连接和请求。

4. 代码结构

​ nginx 工作(worker)码包括核心和功能模块。 nginx 的核心是负责维护严格的运行循环，并在请求处理的每个阶段执行模块代码的适当部分。 模块构成了大部分的演示和应用层功能。 模块读取和写入网络和存储，转换内容，执行出站过滤，应用服务器端包含操作，并在代理启动时将请求传递给上游服务器 。nginx 的模块化架构通常允许开发人员扩展一组 Web 服务器功能，而无需修改 nginx 内核。 nginx 模块略有不同，即核心模块，事件模块，阶段处理程序，协议，可变处理程序， 过滤器，上游和负载平衡器。 nginx 不支持动态加载的模块; 即在构建阶段将模块与核心一起编译。

在处理与接受，处理和管理网络连接和内容检索相关的各种操作时， nginx 在基于 Linux，Solaris 和 BSD 的操作系统中使用事件通知机制和一些磁盘 I/O 性能增强，如： kqueue， epoll，和事件端口。 目标是为操作系统提供尽可能多的提示，以便及时获取入站和出站流量，磁盘操作，读取或写入套接字，超时等异步反馈。 对于每个基于 Unix 的 nginx 运行的操作系统，大量优化了复用和高级 I/O 操作的不同方法的使用。

5. 工作模式

如前所述， nginx 不会为每个连接生成一个进程或线程。 相反，工作(worker)进程接受来自共享“listen” 套接字的新请求，并在每个工作(worker)内执行高效的运行循环，以处理每个工作(worker)中的数千个连接。 没有专门的仲裁或分配与 nginx 工作(worker)的联系; 这个工作(worker)是由操作系统内核机制完成的。 启动后，将创建一组初始侦听套接字。 然后，工作(worker)在处理 HTTP 请求和响应时不断接受，读取和写入套接字。

运行循环是 nginx 工作(worker)代码中最复杂的部分。 它包括全面的内部调用，并且在很大程度上依赖异步任务处理的想法。 异步操作通过模块化，事件通知，广泛使用回调函数和微调定时器来实现。 总体而言，关键原则是尽可能不阻塞。 nginx 仍然可以阻塞的唯一情况是工作(worker)进程没有足够的磁盘存储。

由于 nginx 不会连接一个进程或线程，所以在绝大多数情况下，内存使用非常保守，非常有效。 nginx 也节省 CPU 周期，因为进程或线程没有持续的创建 - 销毁模式。 nginx 的作用是检查网络和存储的状态，初始化新连接，将其添加到运行循环中，并异步处理直到完成，此时连接被重新分配并从运行循环中删除。 结合仔细使用系统调用(syscall)和精确实
现支持接口(如 pool 和 slab 内存分配器)， nginx 通常可以在极端工作负载下实现中到低的CPU 使用 。

在一些磁盘使用和 CPU 负载模式，应调整 nginx 工作(worker)的数量。 在这里说一点基础规则：系统管理员应该为其工作负载尝试几个配置。 一般建议可能如下：如果负载模式是 CPU 密集型的，例如，处理大量 TCP/IP，执行 SSL 或压缩，则 nginx 工作(worker)的数量应与 CPU 内核数量相匹配; 如果负载大多是磁盘 I/O 绑定，例如，从存储或重代理服务
不同的内容集合 - 工作(worker)的数量可能是核心数量的一到两倍。有些工程师会根据个人存储单元的数量选择工作(worker)的数量，但这种方法的效率取决于磁盘存储的类型和配置 。

nginx 的开发人员将在即将推出的版本中解决的一个主要问题是如何避免磁盘 I/O 上的大多数阻塞。 目前，如果没有足够的存储性能来提供特定工作(worker)生成的磁盘操作，该工作(worker)可能仍然阻止从磁盘读取/写入。 存在许多机制和配置文件指令来减轻此类磁盘 I/O 阻塞情况。要注意的是，诸如： sendfile 和 AIO 之类的选项的组合通常会为磁盘性能带来很大的余量。 应该根据数据集，可用于 nginx 的内存量和底层存储架构来规划安装一个 nginx 服务器。

现有工作(worker)模式的另一个问题是与嵌入式脚本的有限支持有关。 一个使用标准的 nginx 分发，只支持嵌入 Perl 脚本。一个简单的解释：关键问题是嵌入式脚本阻止任何操作或意外退出的可能性。 这两种类型的行为将立即导致工作(worker)挂起的情况，同时影响到数千个连接。 更多的工作(worker)计划是使 nginx 的嵌入式脚本更简单，更可靠，适用于更广泛的应用。

6. nginx 进程角色

nginx 在内存中运行多个进程; 有一个主进程和几个工作(worker)进程。 还有一些特殊用途的过程，特别是缓存加载器和缓存管理器。 所有进程都是单线程版本为 1.x 的 nginx。所有进程主要使用共享内存机制进行进程间通信。主进程作为 root 用户运行。 缓存加载器，缓存管理器和工作(worker)则以无权限用户运行。

主程序负责以下任务：

• 读取和验证配置
• 创建，绑定和关闭套接字
• 启动，终止和维护配置的工作(worker)进程数
• 重新配置，无需中断服务
• 控制不间断的二进制升级(如果需要，启动新的二进制并回滚)
• 重新打开日志文件
• 编译嵌入式 Perl 脚本

工作(worker)进程接受，处理和处理来自客户端的连接，提供反向代理和过滤功能，并执行几乎所有其他的 nginx 能力。 关于监视 nginx 实例的行为，系统管理员应该关注工作(worker)进程，因为它们是反映 Web 服务器实际日常操作的过程。

缓存加载器进程负责检查磁盘缓存项目，并使用缓存元数据填充 nginx 的内存数据库。本质上，缓存加载器准备 nginx 实例来处理已经存储在磁盘上的特定分配的目录结构中的文件。 它遍历目录，检查缓存内容元数据，更新共享内存中的相关条目，然后在所有内容清洁并准备使用时退出。
缓存管理器主要负责缓存到期和无效。 在正常的 nginx 操作期间它保持在内存中，并且在失败的情况下由主进程重新启动。

7. Nginx安装

准备第三方支持库源码：

• nginx-1.16.1.tar.gz //源文件
• openssl-1.1.1g.tar.gz //加密
• pcre-8.44.tar.gz // 轻量级函数库
• zlib-1.2.11.tar.gz // 解压缩

包的链接地址放在网盘:
链接：https://pan.baidu.com/s/10yW1tb9lGfWbNHV04JfyzA
提取码：omh2

先解压每个包

$ tar xzvf nginx-1.16.1.tar.gz 
$ tar xzvf openssl-1.1.1g.tar.gz
$ tar xzvf pcre-8.44.tar.gz
$ tar xzvf zlib-1.2.11.tar.gz 

编译安装

$ cd nginx-1.16.1
$ ./configure --prefix=/usr/local/nginx --with-http_realip_module --
with-http_addition_module --with-http_gzip_static_module --withhttp_secure_link_module --with-http_stub_status_module --with-stream --
with-pcre=/home/wz/pcre-8.41 --withzlib=/home/wz/zlib-1.2.11 --withopenssl=/home/wz/openssl-1.1.0g

$ make
$ sudo make install

在/usr/local/目录下面，产生了 nginx 的目录

启动nginx

//进入/usr/local/nginx 下执行
$ ./sbin/nginx –c ./conf/nginx.conf  

使用 ps 查看nginx的进程
$ ps -aux|grep nginx

输入本地ip， 可以看到nginx的页面

8. Nginx的快速入门

nginx 有一个主进程和几个工作进程。 主进程的主要目的是读取和评估配置，并维护工作进程。 工作进程对请求进行实际处理。 nginx 采用基于事件的模型和依赖于操作系统的机制来有效地在工作进程之间分配请求。 工作进程的数量可在配置文件中定义，并且可以针对给定的配置进行修改，或者自动调整到可用 CPU 内核的数量在配置文件中确定 nginx 及其模块的工作方式。 默认情况下，配置文件名为 nginx.conf，并放在目录： /usr/local/nginx/conf, /etc/nginx, 或 /usr/local/etc/nginx 中。在前面安装文章配置中，使用的安装配置目录是： /usr/local/nginx/conf 。所以可以在这个目录下找到这个配置文件。

启动，停止和重新加载Nginx的配置

要启动 nginx，请运行可执行文件。 当 nginx 启动后，可以通过使用-s 参数调用可执行文件
来控制它。 使用以下语法：

$ nginx -s signal

信号(signal)的值可能是以下之一：

• stop - 快速关闭服务
• quit - 正常关闭服务
• reload - 重新加载配置文件
• reopen - 重新打开日志文件

提供静态内容服务(静态网站)

一个重要的 Web 服务器任务是提供文件(如图像或静态 HTML 页面)。这里我们来学习如何实现一个示例，根据请求，文件将从不同的本地目录提供： /usr/local/nginx/html/www(包含HTML 文件)和/usr/local/nginx/html/images(包含图像)。这将需要编辑配置文件，并使用两个位置块在 http 块内设置服务器块。首先，创建/usr/local/nginx/html/www 目录，并将一个包含任何文本内容的 exmaple.html 文件放入其中，并创建/usr/local/nginx/html/images 目录并在其中放置一些图像。

root@ubuntu:/usr/local/nginx# mkdir -p /data/images
root@ubuntu:/usr/local/nginx#

分别在上面创建的两个目录中放入两个文件： /usr/local/nginx/html/www/exmaple.html 和 /
usr/local/nginx/html/1.png, 2.png, 3.png， /usr/local/nginx/html/ww 文件的内容就一行，如下

<h2> Nginx Demo.h2>   

接下来，打开配置文件(/usr/local/nginx/conf/nginx.conf)。 默认的配置文件已经包含了服务器块的几个示例，大部分是注释掉的。 现在注释掉所有这样的块，并启动一个新的服务器块：

http {
	server {
	}
}

通常，配置文件可以包括服务器监听的端口和服务器名称区分的几个 server 块。当 nginx 决
定哪个服务器处理请求后，它会根据服务器块内部定义的 location 指令的参数测试请求头中
指定的 URI。将以下 location 块添加到服务器(server)块：

http {
	server {
		location / {
			root /usr/local/nginx/html/www;
			}
	}
}

该location 块指定与请求中的 URI 相比较的“/”前缀。 对于匹配请求， URI 将被添加到 root指令中指定的路径(即/data/www)，以形成本地文件系统上所请求文件的路径。 如果有几个匹配的 location 块， nginx 将选择具有最长前缀来匹配 location 块。 上面的 location 块提供最短的前缀长度为 1，因此只有当所有其他 location 块不能提供匹配时，才会使用该块。接下来，添加第二个 location 块：

http {
	server {
		location / {
			root /usr/local/nginx/html/www;
		}
		location /images/ {
			root /usr/local/nginx/html;
		}
	}
}

它将是以/images/(位置/也匹配这样的请求，但具有较短前缀，也就是“/images/”比“/”长)的
请求来匹配。
server 块的最终配置应如下所示：

server {
	location / {
		root /usr/local/nginx/html/www;
		}
	location /images/ {
		root /usr/local/nginx/html;
	}
}

这已经是一个在标准端口 80 上侦听并且可以在本地机器上访问的服务器( http://localhost/ )的工作配置。 响应以/images/开头的 URI 的请求，服务器将从/data/images 目录发送文件。例如，响应 http://192.168.199.133:8080/images/logo.jpg 请求， nginx 将发送服务上的/usr/local/nginx/html/images/logo.jpg 文件。 如果文件不存在， nginx 将发送一个指示 404 错误的响应。 不以/images/开头的 URI 的请求将映射到/usr/local/nginx/html/www 目录。 例如 ， 响 应 http://192.168.199.133:8080/example.html 请 求 时 ， nginx 将 发 送/usr/local/nginx/html/www /example.html 文件。要应用新配置，如果尚未启动 nginx 或者通过执行以下命令将重载信号发送到 nginx 的主进程：

root@ubuntu:/usr/local/nginx# /usr/local/nginx/sbin/nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is
ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is
successful
root@ubuntu:/usr/local/nginx# /usr/local/nginx/sbin/nginx -s reload
如果错误或异常导致无法正常工作，可以尝试查看目录**/usr/local/nginx/logs** 或/var/log/nginx中的 access.log 和 error.log 文件中查找原因。打开浏览器或使用 CURL 访问 Nginx 服务器如下所示:

完整的 nginx.conf 文件配置内容如下：

events {
	worker_connections 1024;
}
http {
	server {
		listen 8080;
		server_name localhost;
		location / {
			root /usr/local/nginx/html/www;
		}
		location /images/ {
			root /usr/local/nginx/html;
		}
	}
}