文章20：NGINX配置文件格式及处理流程

欢迎转载，转载请注明出处 http://blog.csdn.net/yankai0219/article/details/8286579 

本文主要内容 0.序 一、NGINX配置文件的格式  1.构成 2.配置文件的格式决定了某些函数会被递归调用！原因： 3.配置项详细说明： 二、NGINX中结构体 与函数    1.存放指令取值的结构体 2.  存放指令的结构体 3.  与配置文件有关的函数  三、配置文件解析的流程 1.总流程 2.详细过程      NGX_CORE_MODULE、NGX_EVENT_MODULE、NGX_HTTP_MODULE

0.序

     本文主要讲述了配置文件的格式以及NGINX如何获得配置文件的内容。阅读了很多大牛的文章，也阅读了代码中关于CORE HTTP EVENT模块对于配置文件的处理，现在将内容总结如下:

一、NGINX配置文件的格式 

1.构成

     Nginx配置文件是由多个配置项构成，每个配置项都有一个项目名和对应的项目值。配置项又分为简单配置项和复杂配置项。 项目名又被称为指令（Directive），而项目值可能简单的字符串（以分号结尾），也可能是由简单字符串和多个配置项组合而成配置块的复杂结构（以大括号}结尾），因此我们可以将配置项归纳为两种：简单配置项和复杂配置项。

如下图所示：

2.配置文件的格式决定了某些函数会被递归调用！原因：

            从上面这条规范可以看到这里包含有递归的思想，因此在后面的配置解析代码里可以看到某些函数被递归调用，其原因也就在这里。

对于复杂配置项来说，其值是由多个简单/复杂配置项组成，因此nginx不做过细的处理，一般就是申请内容空间、切换解析状态，然后递归调用解析函数；真正将用户配置信息转换为nginx内变量的值，还是那些简单配置项所对应的处理函数。

3.配置项详细说明：

     不管是简单配置项还是复杂配置项，他们的项目名和项目值都是由标记（token）组成。配置项目名就是一个token，而配置项目值可以使一个、两个、多个token组成。所谓标记（token）：这里指一个配置文件字符串内容中被空格、引号、括号，比如’{‘、换行符等分割开来的字符子串。

      举例说明：

比如简单配置项：

daemon off;

其项目名daemon为一个token，项目值off也是一个token。而简单配置项：

error_page  404   /404.html;

其项目值就包含有两个token，分别为404和/404.html。

对于复杂配置项：

location /www {

index    index.html index.htm index.php;

}

其项目名location为一个token，项目值是一个token（/www）和多条简单配置项组成的复合结构。

而如果我在配置文件内加入如下配置内容：
lenky on;
启动nginx，直接返回错误，这是因为对于lenky指令，nginx没有对应的代码去解析它：
[emerg]: unknown directive “lenky” in /usr/local/nginx/conf/nginx.conf:2

二、NGINX中结构体 与函数

     对于Nginx而言，我们需要根据某些规则自己书写配置文件nginx.conf。那么nginx.conf中的指令及指令的取值在NGINX程序中是以何种形式呈现的呢？问题举例：即daemon on; 在NGINX程序中是如何体现的呢？

       1.存放指令取值的结构体

          在NGINX中有一类自定义的配置结构体，其格式具有统一的规则。

     对于 HTTP模块中： ngx_http_<module name>_(main|srv|loc)_conf_t 

     对于 EVENT模块：ngx_event_conf_t

     对于 CORE模块：ngx_core_conf_t。

        这类自定义的配置结构体的作用：

               存放指令的取值。即NGINX在这些自定义的配置结构体中存放nginx.conf中的指令的取值。

               举例：ngx_core_conf_t 的成员变量 ngx_flag_t daemon就是存放指令daemon的取值。

     

      2.  存放指令的结构体

               在Nginx中有一类统一的指令结构体ngx_commant_t。

               在ngx_commant_t ngx_core_commands[]={

                    {指令A},

                    {指令B},

                    ngx_null_command

               }

关于该指令结构体ngx_commant_t的解释

3.  与配置文件有关的函数

     ngx_conf_parse和 ngx_conf_handler 可参阅 http://lenky.info/2011/09/09/nginx%E9%85%8D%E7%BD%AE%E4%BF%A1%E6%81%AF%E7%9A%84%E8%A7%A3%E6%9E%90%E6%B5%81%E7%A8%8B-3/

 三、配置文件解析的流程

1.总流程：

     不管对于CORE MODULE or HTTP or EVENT MODULE，其主要流程如下所示：

1、某个void **ctx数组存放通过ngx_modules[i]->ctx->create_conf获得的ngx_xxx_conf_t结构体

2.构造ngx_conf_t conf 。填写里面几个成员变量。

          void *ctx即为1.中ctx数组，即eg:conf.ctx = ctx

          ngx_uint_t module_type 填写为CORE or HTTP or EVENT。eg:conf.module_type = NGX_CORE_MODULE

          ngx_uint_t cmd_type 填写为MAIN or SERVER or LOCATION.eg:conf.cmd_type = NGX_MAIN_CONF

3.调用ngx_conf_parse（ngx_conf_t conf ，xxx）函数，进行解析。

        在ngx_conf_handler函数中，void * conf通过ctx数组，获得某个特定token所处于的模块的ngx_xxx_conf_t结构体，即conf指向了某个特定token所处的结构体的位置。

        再指向cmd->set函数，从而可以将token的取值存入conf指向的某个特定token所处的结构体。从而完成token取值从配置文件到程序特定变量的过程。  

     整体过程如上所述，详细过程还请依次阅读对于NGX_CORE_MODULE、NGX_EVENT_MODULE、NGX_HTTP_MODULE的分析。

2.详细过程

对于NGX_CORE_MODULE

在ngx_init_cycle函数中

在ngx_conf_parse函数调用ngx_conf_handler(ngx_conf_t *cf, ngx_int_t last)函数

对于daemon而言

对于NGX_EVENT_MODULE而言

在ngx_events_block中

对于NGX_HTTP_MODULE

static  char  * ngx_http_block ( ngx_conf_t  *cf,  ngx_command_t  *cmd,  void  *conf) {      char                         *rv;      ngx_uint_t                    mi, m, s;      ngx_conf_t                    pcf;      ngx_http_module_t            *module;      ngx_http_conf_ctx_t          *ctx;      ngx_http_core_loc_conf_t     *clcf;      ngx_http_core_srv_conf_t    **cscfp;      ngx_http_core_main_conf_t    *cmcf;