Nginx请求处理流程你了解吗？

淡淡的烟草味﹌ 2022-03-16 07:36 158阅读 0赞

> 本文主要介绍了nginx的11个处理阶段和lua的8个处理阶段，并说明了nginx和lua运行阶段的对应关系。  
> 上篇文章回顾： [Linux网络编程之IO模型][Linux_IO]

## 一、**nginx 11 个处理阶段** ##

##### nginx实际把http请求处理流程划分为了11个阶段，这样划分的原因是将请求的执行逻辑细分，以模块为单位进行处理，各个阶段可以包含任意多个HTTP模块并以流水线的方式处理请求。这样做的好处是使处理过程更加灵活、降低耦合度。这11个HTTP阶段如下所示： #####

1）NGX\_HTTP\_POST\_READ\_PHASE：

接收到完整的HTTP头部后处理的阶段，它位于uri重写之前，实际上很少有模块会注册在该阶段，默认的情况下，该阶段被跳过。

2）NGX\_HTTP\_SERVER\_REWRITE\_PHASE：

URI与location匹配前，修改URI的阶段，用于重定向，也就是该阶段执行处于server块内，location块外的重写指令，在读取请求头的过程中nginx会根据host及端口找到对应的虚拟主机配置。

3）NGX\_HTTP\_FIND\_CONFIG\_PHASE：

根据URI寻找匹配的location块配置项阶段，该阶段使用重写之后的uri来查找对应的location，值得注意的是该阶段可能会被执行多次，因为也可能有location级别的重写指令。

4）NGX\_HTTP\_REWRITE\_PHASE：

上一阶段找到location块后再修改URI，location级别的uri重写阶段，该阶段执行location基本的重写指令，也可能会被执行多次。

5）NGX\_HTTP\_POST\_REWRITE\_PHASE：

防止重写URL后导致的死循环，location级别重写的后一阶段，用来检查上阶段是否有uri重写，并根据结果跳转到合适的阶段。

6）NGX\_HTTP\_PREACCESS\_PHASE：

下一阶段之前的准备，访问权限控制的前一阶段，该阶段在权限控制阶段之前，一般也用于访问控制，比如限制访问频率，链接数等。

7）NGX\_HTTP\_ACCESS\_PHASE：

让HTTP模块判断是否允许这个请求进入Nginx服务器，访问权限控制阶段，比如基于ip黑白名单的权限控制，基于用户名密码的权限控制等。

8）NGX\_HTTP\_POST\_ACCESS\_PHASE：

访问权限控制的后一阶段，该阶段根据权限控制阶段的执行结果进行相应处理，向用户发送拒绝服务的错误码，用来响应上一阶段的拒绝。

9）NGX\_HTTP\_TRY\_FILES\_PHASE：

为访问静态文件资源而设置，try\_files指令的处理阶段，如果没有配置try\_files指令，则该阶段被跳过。

10）NGX\_HTTP\_CONTENT\_PHASE：

处理HTTP请求内容的阶段，大部分HTTP模块介入这个阶段，内容生成阶段，该阶段产生响应，并发送到客户端。

11）NGX\_HTTP\_LOG\_PHASE：

处理完请求后的日志记录阶段，该阶段记录访问日志。

以上11个阶段中，HTTP无法介入的阶段有4个：

3）NGX\_HTTP\_FIND\_CONFIG\_PHASE

5）NGX\_HTTP\_POST\_REWRITE\_PHASE

8）NGX\_HTTP\_POST\_ACCESS\_PHASE

9）NGX\_HTTP\_TRY\_FILES\_PHASE

剩余的7个阶段，HTTP模块均能介入，每个阶段可介入模块的个数也是没有限制的，多个HTTP模块可同时介入同一阶段并作用于同一请求。

### HTTP阶段的定义，包括checker检查方法和handler处理方法，如下所示 ###

typedef structngx_http_phase_handler_s ngx_http_phase_handler_t;/*一个HTTP处理阶段中的checker检查方法，仅可以由HTTP框架实现，以此控制HTTP请求的处理流程*/typedef ngx_int_t(*ngx_http_phase_handler_pt)(ngx_http_request_t *r, ngx_http_phase_handler_t*ph);/*由HTTP模块实现的handler处理方法*/typedef ngx_int_t(*ngx_http_handler_pt)(ngx_http_request_t *r);
    
    struct ngx_http_phase_handler_s {    /*在处理到某一个HTTP阶段时，HTTP框架将会在checker方法已实现的前提下首先调用checker方法来处理请求，
        而不会直接调用任何阶段中的hanlder方法，只有在checker方法中才会去调用handler方法，因此，事实上所有
        的checker方法都是由框架中的ngx_http_core_module模块实现的，且普通模块无法重定义checker方法*/
        ngx_http_phase_handler_pt  checker;    /*除ngx_http_core_module模块以外的HTTP模块，只能通过定义handler方法才能介入某一个HTTP处理阶段以处理请求*/
        ngx_http_handler_pt        handler;    /*将要处理的下一个HTTP处理阶段的序号
        next的设计使得处理阶段不必按顺序依次执行，既可以向后跳跃数个阶段继续执行，也可以跳跃到之前的某个阶段重新
        执行，通常，next表示下一个处理阶段中的第1个ngx_http_phase_handler_t处理方法*/
        ngx_uint_t                 next;
    };复制代码

一个http\{\}块解析完毕后，将会根据nginx.conf中的配置产生由ngx\_http\_phase\_handler\_t组成的数组，在处理HTTP请求时，一般情况下这些阶段是顺序向后执行的，但ngx\_http\_phase\_handler\_t中的next成员使得它们也可以非顺序地执行，ngx\_http\_phase\_engine\_t结构体就是所有ngx\_http\_phase\_handler\_t组成的数组，如下所示：

typedef struct {    /*handlers是由ngx_http_phase_handler_t构成的数组首地址，它表示一个请求可能经历的所有ngx_http_handler_pt处理方法*/
        ngx_http_phase_handler_t  *handlers;    /*表示NGX_HTTP_SERVER_REWRITE_PHASE阶段第1个ngx_http_phase_handler_t处理方法在handlers数组中的序号，用于在执行
        HTTP请求的任何阶段中快速跳转到HTTP_SERVER_REWRITE_PHASE阶段处理请求*/
        ngx_uint_t                 server_rewrite_index;    /*表示NGX_HTTP_PREACCESS_PHASE阶段第1个ngx_http_phase_handler_t处理方法在handlers数组中的序号，用于在执行
        HTTP请求的任何阶段中快速跳转到NGX_HTTP_PREACCESS_PHASE阶段处理请求*/
        ngx_uint_t                 location_rewrite_index;
    } ngx_http_phase_engine_t;复制代码

可以看到，ngx\_http\_phase\_engine\_t中保存了在当前nginx.conf配置下，一个用户请求可能经历的所有ngx\_http\_handler\_pt处理方法，这是所有HTTP模块可以合作处理用户请求的关键，这个ngx\_http\_phase\_engine\_t结构体保存在全局的ngx\_http\_core\_main\_conf\_t结构体中，如下：

typedef struct {
        ngx_array_t                servers;         /* ngx_http_core_srv_conf_t */
        /*由下面各阶段处理方法构成的phases数组构建的阶段引擎才是流水式处理HTTP请求的实际数据结构*/
        ngx_http_phase_engine_t    phase_engine;
        ngx_hash_t                 headers_in_hash;
        ngx_hash_t                 variables_hash;
        ngx_array_t                variables;       /* ngx_http_variable_t */
        ngx_uint_t                 ncaptures;
        ngx_uint_t                 server_names_hash_max_size;
        ngx_uint_t                 server_names_hash_bucket_size;
        ngx_uint_t                 variables_hash_max_size;
        ngx_uint_t                 variables_hash_bucket_size;
        ngx_hash_keys_arrays_t    *variables_keys;
        ngx_array_t               *ports;
        ngx_uint_t                 try_files;       /* unsigned  try_files:1 */
        /*用于在HTTP框架初始化时帮助各个HTTP模块在任意阶段中添加HTTP处理方法，它是一个有11个成员的ngx_http_phase_t数组，
        其中每一个ngx_http_phase_t结构体对应一个HTTP阶段，在HTTP框架初始化完毕后，运行过程中的phases数组是无用的*/
        ngx_http_phase_t           phases[NGX_HTTP_LOG_PHASE + 1];
    } ngx_http_core_main_conf_t;复制代码

在ngx\_http\_phase\_t中关于HTTP阶段有两个成员：phase\_engine和phases，其中phase\_engine控制运行过程中的一个HTTP请求所要经过的HTTP处理阶段，它将配合ngx\_http\_request\_t结构体中的phase\_handler成员使用(phase\_handler制定了当前请求应当执行哪一个HTTP阶段)；而phases数组更像一个临时变量，它实际上仅会在Nginx启动过程中用到，它的唯一使命是按照11个阶段的概率初始化phase\_engine中的handlers数组。

typedef struct {    /*handlers动态数组保存着每一个HTTP模块初始化时添加到当前阶段的处理方法*/
        ngx_array_t                handlers;
    } ngx_http_phase_t;复制代码

在HTTP框架的初始化过程中，任何HTTP模块都可以在ngx\_http\_module\_t接口的postconfiguration方法中将自定义的方法添加到handler动态数组中，这样，这个方法就会最终添加到phase\_engine动态数组中。

## 二、nginx lua 8个阶段 ##

init\_by\_lua http  
set\_by\_lua server, server if, location, location if  
rewrite\_by\_lua http, server, location, location if  
access\_by\_lua http, server, location, location if  
content\_by\_lua location, location if  
header\_filter\_by\_lua http, server, location, location if  
body\_filter\_by\_lua http, server, location, location if  
log\_by\_lua http, server, location, location if

1）init\_by\_lua：

在nginx重新加载配置文件时，运行里面lua脚本，常用于全局变量的申请。（例如：lua\_shared\_dict共享内存的申请，只有当nginx重起后，共享内存数据才清空，这常用于统计。）

2）set\_by\_lua：

流程分支处理判断变量初始化（设置一个变量，常用与计算一个逻辑，然后返回结果，该阶段不能运行Output API、Control API、Subrequest API、Cosocket API）

3）rewrite\_by\_lua：

转发、重定向、缓存等功能 (例如特定请求代理到外网，在access阶段前运行，主要用于rewrite)

4）access\_by\_lua：

IP准入、接口权限等情况集中处理(例如配合iptable完成简单防火墙，主要用于访问控制，能收集到大部分变量，类似status需要在log阶段才有。这条指令运行于nginx access阶段的末尾，因此总是在 allow 和 deny 这样的指令之后运行，虽然它们同属 access 阶段。）

5）content\_by\_lua：

内容生成，阶段是所有请求处理阶段中最为重要的一个，运行在这个阶段的配置指令一般都肩负着生成内容（content）并输出HTTP响应。

6）header\_filter\_by\_lua：

应答HTTP过滤处理，一般只用于设置Cookie和Headers等，该阶段不能运行Output API、Control API、Subrequest API、Cosocket API(例如添加头部信息)。

7）body\_filter\_by\_lua：

应答BODY过滤处理(例如完成应答内容统一成大写)（一般会在一次请求中被调用多次, 因为这是实现基于 HTTP 1.1 chunked 编码的所谓“流式输出”的，该阶段不能运行Output API、Control API、Subrequest API、Cosocket API）

8）log\_by\_lua：

会话完成后本地异步完成日志记录(日志可以记录在本地，还可以同步到其他机器)（该阶段总是运行在请求结束的时候，用于请求的后续操作，如在共享内存中进行统计数据,如果要高精确的数据统计，应该使用body\_filter\_by\_lua，该阶段不能运行Output API、Control API、Subrequest API、Cosocket API）

## 三、nginx和lua运行阶段的对应关系 ##

1）init\_by\_lua，运行在initialization Phase；

2）set\_by\_lua，运行在rewrite 阶段；

set 指令来自 ngx\_rewrite 模块，运行于 rewrite 阶段；

3）rewrite\_by\_lua 指令来自 ngx\_lua 模块，运行于 rewrite 阶段的末尾

4）access\_by\_lua 指令同样来自 ngx\_lua 模块，运行于 access 阶段的末尾；

deny 指令来自 ngx\_access 模块，运行于 access 阶段；

5）content\_by\_lua 指令来自 ngx\_lua 模块，运行于 content 阶段；不要将它和其它的内容处理指令在同一个location内使用如proxy\_pass；

echo 指令则来自 ngx\_echo 模块，运行在 content 阶段；

6）header\_filter\_by\_lua 运行于 content 阶段，output-header-filter 一般用来设置cookie和headers；

7）body\_filter\_by\_lua，运行于 content 阶段；

8）log\_by\_lua，运行在Log Phase 阶段；

如图：

> 参考资料：
> 
> 1.https://blog.csdn.net/fb408487792/article/details/53610140
> 
> 2.https://blog.csdn.net/lijinqi1987/article/details/53010000?locationNum=15&fps=1
> 
> 3.https://blog.csdn.net/yangguanghaozi/article/details/54139258  
>

本文首发于公众号“小米运维”，[点击查看原文][Link 1]

[Linux_IO]: https://link.juejin.im?target=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzUxMDQxMDMyNg%3D%3D%26amp%3Bmid%3D2247484772%26amp%3Bidx%3D1%26amp%3Bsn%3D4dac1e0efe3d89fbc3091575d71d6c67%26amp%3Bchksm%3Df9022e5dce75a74bc0ea87ae131b7e8d3c5b8bda532949f97bb135636219361a9b21fd49814f%26amp%3Bscene%3D21%23wechat_redirect
[Link 1]: https://link.juejin.im?target=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzUxMDQxMDMyNg%3D%3D%26amp%3Bmid%3D2247484777%26amp%3Bidx%3D1%26amp%3Bsn%3D1351faa0b02fa1aa3cfff68e4a13bbe9%26amp%3Bchksm%3Df9022e50ce75a746133f7622575a14aa98bad9322b3c89c6dd4394bf954ea60fc0c7fcb4dee6%26amp%3Btoken%3D18833801%26amp%3Blang%3Dzh_CN%23rd