Nginx详解-优快云博客

随记：最近复习了一下 nginx ，发现还是有很多有待探索的地方，这里做一个大概的总结。

什么是 Nginx?

Nginx 是由俄罗斯人编写的十分轻量级的HTTP服务器，是一个高性能的HTTP和反向代理服务器，同时也是一个 IMAP/POP3/SMTP 代理服务器。它以事件驱动的方式编写，支持内核 Poll 模型，能经受起高负载的考验。运行时 CPU 与内存占有率非常低，具有很高的稳定性。同时它还支持热部署功能。

Nginx 做为 HTTP 服务器，有以下几项基本特性：

处理静态文件，索引文件以及自动索引；打开文件描述符缓冲。
无缓存的反向代理加速，简单的负载均衡和容错。
FastCGI，简单的负载均衡和容错。
模块化的结构。包括 gzipping，byte ranges,，chunked responses，以及 SSI-filter 等 filter。
支持 SSL 和 TLSSNI。

Nginx 工作方式

Nginx 默认是以多进程的方式工作的，在启动之后，系统会初始化一个 master 进程和多个 worker 进程。master 进程主要用来管理 worker 进程，包含：接收来自外界的信号，向各 worker 进程发送信号，监控 worker 进程的运行状态，当 worker 进程退出后(异常情况下)，会自动重新启动新的 worker 进程。而基本的网络事件，则是放在 worker 进程中来处理了。多个 worker 进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。

Nginx 的配置系统

Nginx 的配置系统由一个主配置文件和其他一些辅助的配置文件构成。这些配置文件均是纯文本文件，全部位于 Nginx 安装目录下的 conf 目录下。

nginx.conf 中的配置信息，根据其逻辑上的意义，对它们进行了分类，也就是分成了多个作用域，或者称之为配置指令上下文。不同的作用域含有一个或者多个配置项。

当前 Nginx 支持的几个指令上下文：

main：Nginx在运行时与具体业务功能（比如 http 服务或者 email 服务代理）无关的一些参数，比如工作进程数，运行的身份等。
http：与提供 http 服务相关的一些配置参数。例如：是否使用 keepalive 啊，是否使用 gzip 进行压缩等。
server：http 服务上支持若干虚拟主机。每个虚拟主机一个对应的 server 配置项，配置项里面包含该虚拟主机相关的配置。在提供 mail 服务的代理时，也可以建立若干 server，每个 server 通过监听的地址来区分。
location：http 服务中，某些特定的 URL 对应的一系列配置项。
mail：实现 email 相关的 SMTP/IMAP/POP3 代理时，共享的一些配置项（因为可能实现多个代理，工作在多个监听地址上）

指令上下文，可能有包含的情况出现。例如：通常 http 上下文和 mail 上下文一定是出现在 main 上下文里的。在一个上下文里，可能包含另外一种类型的上下文多次的情况。例如：

存在于 main 上下文中的配置指令如下:

user | worker_processes | error_log | events | http | mail
存在于 http 上下文中的指令如下:

server
存在于 mail 上下文中的指令如下：

server | auth_http | imap_capabilities
存在于 server 上下文中的配置指令如下：

listen | server_name | access_log | location | protocol | proxy | smtp_auth | xclient
存在于 location 上下文中的指令如下：

index | root

Nginx 的模块化体系结构

Nginx 的内部结构是由核心部分和一系列的功能模块所组成。Nginx 将各功能模块组织成一条链，当有请求到达的时候，请求依次经过这条链上的部分或者全部模块，进行处理。Nginx 的模块根据其功能基本上可以分为以下几种类型：

event module：搭建了独立于操作系统的事件处理机制的框架，及提供了各具体事件的处理。
phase handler: 此类型的模块也被直接称为 handler 模块。主要负责处理客户端请求并产生待响应内容。
output filter: 也称为 filter 模块，主要是负责对输出的内容进行处理，可以对输出进行修改。
upstream: upstream 模块实现反向代理的功能，将真正的请求转发到后端服务器上，并从后端服务器上读取响应，发回客户端。

Nginx 的请求处理

根据前面所知，所有实际上的业务处理逻辑都在 worker 进程中。worker 进程中有一个函数，执行无限循环，不断处理收到的来自客户端的请求，并进行处理，直到整个 Nginx 服务被停止。

worker 进程中，ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中，一个请求的简单处理流程如下：

操作系统提供的机制（例如 epoll, kqueue 等）产生相关的事件。
接收和处理这些事件，如是接受到数据，则产生更高层的 request 对象。
处理 request 的 header 和 body。
产生响应，并发送回客户端。
完成 request 的处理。
重新初始化定时器及其他事件。

从 Nginx 的内部来看，一个 HTTP Request 的处理过程涉及到以下几个阶段。

初始化 HTTP Request（读取来自客户端的数据，生成 HTTP Request 对象，该对象含有该请求所有的信息）。
处理请求头。
处理请求体。
如果有的话，调用与此请求（URL 或者 Location）关联的 handler。
依次调用各 phase handler 进行处理

一个 phase handler 通常执行以下几项任务：

获取 location 配置。
产生适当的响应。
发送 response header。
发送 response body。

当 Nginx 读取到一个 HTTP Request 的 header 的时候，Nginx 首先查找与这个请求关联的虚拟主机的配置。如果找到了这个虚拟主机的配置，那么通常情况下，这个 HTTP Request 将会经过以下几个阶段的处理（phase handlers）：

NGX_HTTP_POST_READ_PHASE: 读取请求内容阶段
NGX_HTTP_SERVER_REWRITE_PHASE: Server 请求地址重写阶段
NGX_HTTP_FIND_CONFIG_PHASE: 配置查找阶段:
NGX_HTTP_REWRITE_PHASE: Location请求地址重写阶段
NGX_HTTP_POST_REWRITE_PHASE: 请求地址重写提交阶段
NGX_HTTP_PREACCESS_PHASE: 访问权限检查准备阶段
NGX_HTTP_ACCESS_PHASE: 访问权限检查阶段
NGX_HTTP_POST_ACCESS_PHASE: 访问权限检查提交阶段
NGX_HTTP_TRY_FILES_PHASE: 配置项 try_files 处理阶段
NGX_HTTP_CONTENT_PHASE: 内容产生阶段
NGX_HTTP_LOG_PHASE: 日志模块处理阶段

在内容产生阶段，为了给一个 request 产生正确的响应，Nginx 必须把这个 request 交给一个合适的 content handler 去处理。如果这个 request 对应的 location 在配置文件中被明确指定了一个 content handler，那么Nginx 就可以通过对 location 的匹配，直接找到这个对应的 handler，并把这个 request 交给这个 content handler 去处理。这样的配置指令包括像，perl，flv，proxy_pass，mp4等。

如果一个 request 对应的 location 并没有直接有配置的 content handler，那么 Nginx 依次尝试：

如果一个 location 里面有配置 random_index on，那么随机选择一个文件，发送给客户端。
如果一个 location 里面有配置 index 指令，那么发送 index 指令指明的文件，给客户端。
如果一个 location 里面有配置 autoindex on，那么就发送请求地址对应的服务端路径下的文件列表给客户端。
如果这个 request 对应的 location 上有设置 gzip_static on，那么就查找是否有对应的.gz文件存在，有的话，就发送这个给客户端（客户端支持 gzip 的情况下）。
请求的 URI 如果对应一个静态文件，static module 就发送静态文件的内容到客户端。

内容产生阶段完成以后，生成的输出会被传递到 filter 模块去进行处理。filter 模块也是与 location 相关的。所有的 fiter 模块都被组织成一条链。输出会依次穿越所有的 filter，直到有一个 filter 模块的返回值表明已经处理完成。

这里列举几个常见的 filter 模块，例如：

server-side includes。
XSLT filtering。
图像缩放之类的。
gzip 压缩。

Nginx 常用方式：

负载均衡模块用于从upstream指令定义的后端主机列表中选取一台主机。Nginx 先使用负载均衡模块找到一台主机，再使用 upstream 模块实现与这台主机的交互。
proxy_pass 可以很方便的进行反向代理。
location 匹配规则与顺序
- 语法规则： location [=|~|~*|^~] /uri/ { … }
- 首先匹配 =，其次匹配^~, 其次是按文件中顺序的正则匹配，最后是交给 / 通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求
参考：
http://wiki.jikexueyuan.com/project/nginx/
https://blog.youkuaiyun.com/zzq900503/article/details/72821081