上一篇《WEB请求处理（1）：浏览器请求发起处理》，我们讲述了浏览器端请求发起过程，通过DNS域名解析服务器IP，并建立TCP连接，发送HTTP请求。本文讲述请求到达反向代理服务器的一个处理过程，比如：在Nginx中请求的处理流程，请求都是经过了哪些模块，做了哪些处理，又是如何找到应用服务器呢？
为直观明了，先上一张图，红色部分为本章所述模块：
Nginx有五大优点：模块化、事件驱动、异步、非阻塞、多进程单线程。其中，模块化设计类似于面向对象中的接口类，它增强了nginx源码的可读性、可扩充性和可维护性。
Nginx由内核和模块组成的，其中内核完成的工作比较简单，仅仅通过查找配置文件将客户端请求映射到一个location block，然后又将这个location block中所配置的每个指令将会启动不同的模块去完成相应的工作。
所以，在讲述Nginx请求处理过程，首先要了解Nginx模块结构与功能，Nginx中有哪些模块，其功能又是如何。
1 Nginx模块
Nginx总共有5大一类模块：core、conf、event、http、mail，和48个二类模块。每个模块有属于自己的配置项，由commands字段决定；每个模块在初始化和退出销毁时均有回调函数。
多进程模式下的模块初始化主要有四个方面：脚本初始化、静态初始化、动态初始化、进程初始化。
脚本初始化是指在安装nginx时，由configure脚本生成的相关文件，比如ngx_modules.c文件包含了nginx的所有模块；
静态初始化在编译时就完成，主要通过定义全局变量实现；
动态初始化在运行时完成，主要通过master进程main函数，ngx_init_cycle函数，及各模块文件内定义的init函数实现；
进程初始化是指各worker进程执行init_process函数。当nginx退出或重读配置文件或nginx平滑升级时，worker进程会调用各模块的exit_process函数来销毁资源。
开发人员可以根据nginx模块规则注册自己的模块，添加模块后要重新编译源码，并且修改nginx.conf配置文件才能使新模块生效。
1.1 四种角色模块
Nginx模块主要有4种角色：
(1) core(核心模块)：构建nginx基础服务、管理其他模块；
(2) handlers(处理模块)：用于处理HTTP请求，然后产生输出。
(3) filters（过滤模块）：过滤handler产生的输出。
(4) load-balancers（负载均衡模块）：当有多于一台的后端备选服务器时，选择一台转发HTTP请求。
Nginx的核心模块主要负责建立nginx服务模型、管理网络层和应用层协议、以及启动针对特定应用的一系列候选模块。其他模块负责分配给web服务器的实际工作：
(1) 当Nginx发送文件或者转发请求到其他服务器，由handlers(处理模块)或load-balancers(负载均衡模块)提供服务；
(2) 当需要Nginx把输出压缩或者在服务端加一些东西，由filters(过滤模块)提供服务。
1.2 模块结构设计
1.3 模块数据结构
1.核心：ngx_module_t（nginx所有模块的数据结构模板）
2.配置文件指令：ngx_command_t（主要负责模块与配置文件nginx.conf的交互）
3.指令配置：ngx_conf_t（解析某个具体的指令）
typedef char *(*ngx_conf_handler_pt)(ngx_conf_t *cf, ngx_command_t *dummy, void *conf);
typedef struct ngx_conf_s ngx_conf_t;
struct ngx_conf_s {
char *name; // 指令名
ngx_array_t *args; // 指令后的参数
ngx_cycle_t *cycle; // 全局数据结构
ngx_pool_t *pool; // 内存池
ngx_pool_t *temp_pool; // 临时内存池
ngx_conf_file_t *conf_file; // 指令所在配置文件
ngx_log_t *log; // 日志记录
void *ctx; // 模块上下文
ngx_uint_t module_type; // 模块类型
ngx_uint_t cmd_type; // 指令类型
ngx_conf_handler_pt handler; // set函数指针
char *handler_conf; // set函数返回值
};
4.全局配置：ngx_cycle_t（nginx绝大部分初始化操作都围绕该结构体）
typedef struct ngx_cycle_s ngx_cycle_t;
struct ngx_cycle_s {
void ****conf_ctx; // 配置上下文数组(含所有模块)
ngx_pool_t *pool; // 内存池
ngx_log_t *log; // 日志
ngx_log_t new_log;
ngx_connection_t **files; // 连接文件
ngx_connection_t *free_connections; // 空闲连接
ngx_uint_t free_connection_n; // 空闲连接个数
ngx_queue_t reusable_connections_queue; // 再利用连接队列
ngx_array_t listening; // 监听套接字数组
ngx_array_t pathes; // 路径数组
ngx_list_t open_files; // 打开文件链表
ngx_list_t shared_memory; // 共享内存链表
ngx_uint_t connection_n; // 连接个数
ngx_uint_t files_n; // 打开文件个数
ngx_connection_t *connections; // 连接
ngx_event_t *read_events; // 读事件
ngx_event_t *write_events; // 写事件
ngx_cycle_t *old_cycle; // old cycle指针
ngx_str_t conf_file; // 配置文件
ngx_str_t conf_param; // 配置参数
ngx_str_t conf_prefix; // 配置文件目录
ngx_str_t prefix; // 程序工作目录
ngx_str_t lock_file; // 锁文件，用在不支持accept_mutex的系统中
ngx_str_t hostname; // 主机名
};
1.4 模块调用流程
1.当服务器启动，每个handlers(处理模块)都有机会映射到配置文件中定义的特定位置（location）；如果有多个handlers(处理模块)映射到特定位置时，只有一个会“赢”（说明配置文件有冲突项，应该避免发生）。处理模块以三种形式返回：
OK
ERROR
或者放弃处理这个请求而让默认处理模块来处理（主要是用来处理一些静态文件，事实上如果是位置正确而真实的静态文件，默认的处理模块会抢先处理）。
2.如果handlers(处理模块)把请求反向代理到后端的服务器，就变成另外一类的模块：load-balancers（负载均衡模块）。负载均衡模块的配置中有一组后端服务器，当一个HTTP请求过来时，它决定哪台服务器应当获得这个请求。Nginx的负载均衡模块采用两种方法：
轮转法，它处理请求就像纸牌游戏一样从头到尾分发；
IP哈希法，在众多请求的情况下，它确保来自同一个IP的请求会分发到相同的后端服务器。
3.如果handlers(处理模块)没有产生错误，filters（过滤模块）将被调用。多个filters（过滤模块）能映射到每个位置，所以（比如）每个请求都可以被压缩成块。它们的执行顺序在编译时决定。filters（过滤模块）是经典的“接力链表（CHAIN OF RESPONSIBILITY）”模型：一个filters（过滤模块）被调用，完成其工作，然后调用下一个filters（过滤模块），直到最后一个filters（过滤模块）。过滤模块链的特别之处在于：
每个filters（过滤模块）不会等上一个filters（过滤模块）全部完成；
它能把前一个过滤模块的输出作为其处理内容；有点像Unix中的流水线。
过滤模块能以buffer（缓冲区）为单位进行操作，这些buffer一般都是一页（4K）大小，当然你也可以在nginx.conf文件中进行配置。这意味着，比如，模块可以压缩来自后端服务器的响应，然后像流一样的到达客户端，直到整个响应发送完成。
总之，过滤模块链以流水线的方式高效率地向客户端发送响应信息。
4.所以总结下上面的内容，一个典型的HTTP处理周期是这样的：
客户端发送HTTP请求 –>
Nginx基于配置文件中的位置选择一个合适的处理模块 ->
(如果有)负载均衡模块选择一台后端服务器 –>
处理模块进行处理并把输出缓冲放到第一个过滤模块上 –>
第一个过滤模块处理后输出给第二个过滤模块 –>
然后第二个过滤模块又到第三个 –>
依此类推 –> 最后把响应发给客户端。
下图展示了nginx模块处理流程：
2 Nginx请求处理
Nginx在启动时会以daemon形式在后台运行，采用多进程+异步非阻塞IO事件模型来处理各种连接请求。多进程模型包括一个master进程，多个worker进程，一般worker进程个数是根据服务器CPU核数来决定的。master进程负责管理Nginx本身和其他worker进程。如下图：
从上图中可以很明显地看到，4个worker进程的父进程都是master进程，表明worker进程都是从父进程fork出来的，并且父进程的ppid为1，表示其为daemon进程。
需要说明的是，在nginx多进程中，每个worker都是平等的，因此每个进程处理外部请求的机会权重都是一致的。
所有实际上的业务处理逻辑都在worker进程。worker进程中有一个ngx_worker_process_cycle()函数，执行无限循环，不断处理收到的来自客户端的请求，并进行处理，直到整个Nginx服务被停止。
worker 进程中，ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中，一个请求的简单处理流程如下：
操作系统提供的机制（例如 epoll, kqueue 等）产生相关的事件。
接收和处理这些事件，如是接收到数据，则产生更高层的 request 对象。
处理 request 的 header 和 body。
产生响应，并发送回客户端。
完成 request 的处理。
重新初始化定时器及其他事件。
2.1 多进程处理模型
下面来介绍一个请求进来，多进程模型的处理方式：
首先，master进程一开始就会根据我们的配置，来建立需要listen的网络socket fd，然后fork出多个worker进程。
其次，根据进程的特性，新建立的worker进程，也会和master进程一样，具有相同的设置。因此，其也会去监听相同ip端口的套接字socket fd。
然后，这个时候有多个worker进程都在监听同样设置的socket fd，意味着当有一个请求进来的时候，所有的worker都会感知到。这样就会产生所谓的“惊群现象”。为了保证只会有一个进程成功注册到listenfd的读事件，nginx中实现了一个“accept_mutex”类似互斥锁，只有获取到这个锁的进程，才可以去注册读事件。其他进程全部accept 失败。
最后，监听成功的worker进程，读取请求，解析处理，响应数据返回给客户端，断开连接，结束。因此，一个request请求，只需要worker进程就可以完成。
进程模型的处理方式带来的一些好处就是：进程之间是独立的，也就是一个worker进程出现异常退出，其他worker进程是不会受到影响的；此外，独立进程也会避免一些不需要的锁操作，这样子会提高处理效率，并且开发调试也更容易。
如前文所述，多进程模型+异步非阻塞模型才是胜出的方案。单纯的多进程模型会导致连接并发数量的降低，而采用异步非阻塞IO模型很好的解决了这个问题；并且还因此避免的多线程的上下文切换导致的性能损失。
worker进程会竞争监听客户端的连接请求：这种方式可能会带来一个问题，就是可能所有的请求都被一个worker进程给竞争获取了，导致其他进程都比较空闲，而某一个进程会处于忙碌的状态，这种状态可能还会导致无法及时响应连接而丢弃discard掉本有能力处理的请求。这种不公平的现象，是需要避免的，尤其是在高可靠web服务器环境下。
针对这种现象，Nginx采用了一个是否打开accept_mutex选项的值，ngx_accept_disabled标识控制一个worker进程是否需要去竞争获取accept_mutex选项，进而获取accept事件。
ngx_accept_disabled值，nginx单进程的所有连接总数的八分之一，减去剩下的空闲连接数量，得到的这个ngx_accept_disabled。
当ngx_accept_disabled大于0时，不会去尝试获取accept_mutex锁，并且将ngx_accept_disabled减1，于是，每次执行到此处时，都会去减1，直到小于0。不去获取accept_mutex锁，就是等于让出获取连接的机会，很显然可以看出，当空闲连接越少时，ngx_accept_disable越大，于是让出的机会就越多，这样其它进程获取锁的机会也就越大。不去accept，自己的连接就控制下来了，其它进程的连接池就会得到利用，这样，nginx就控制了多进程间连接的平衡了。
2.2 一个简单的HTTP请求
从 Nginx 的内部来看，一个 HTTP Request 的处理过程涉及到以下几个阶段：
初始化 HTTP Request（读取来自客户端的数据，生成 HTTP Request 对象，该对象含有该请求所有的信息）。
处理请求头。
处理请求体。
如果有的话，调用与此请求（URL 或者 Location）关联的 handler。
依次调用各 phase handler 进行处理。
以上步骤，如下图所示：
在这里，我们需要了解一下 phase handler 这个概念。phase 字面的意思，就是阶段。所以 phase handlers 也就好理解了，就是包含若干个处理阶段的一些 handler。
在每一个阶段，包含有若干个 handler，再处理到某个阶段的时候，依次调用该阶段的 handler 对 HTTP Request 进行处理。
通常情况下，一个 phase handler 对这个 request 进行处理，并产生一些输出。通常 phase handler 是与定义在配置文件中的某个 location 相关联的。
一个 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 压缩。
在所有的 filter 中，有几个 filter 模块需要关注一下。按照调用的顺序依次说明如下：
copy: 将一些需要复制的 buf(文件或者内存)重新复制一份然后交给剩余的 body filter 处理。
postpone: 这个 filter 是负责 subrequest 的，也就是子请求的。
write: 写输出到客户端，实际上是写到连接对应的 socket 上。
专栏作者简介
陶邦仁：专注于后端技术研究，前端技术略有涉猎，热衷于构建高性能、高可用网站，擅长于平台服务化、分布式服务、分布式存储等方面的解决方案。目前就职于千丁互联，任技术经理一职，负责社区产品技术研发。曾就职于京东，负责库存组缓存方案技术实现；曾就职于百度糯米，负责PC首页、APP个性化排单服务化解决方案。