nginx配置解析详解(一)

nginx配置解析详解(一)

现在针对nginx源码分析的blog和文章已经很多了，之前我也看过不少，大家的分析都很不错。太多重复的内容就不写了，主要想针对在我分析代码和查阅blog的过程中，发现的一些比较晦涩或者某些细节有待展开讨论的地方，给出我的自己理解和看法，希望跟大家交流和学习。

使用的nginx版本是nginx-1.0.6，我最开始看的代码是0.7.62，新的版本在功能和稳定性上做了很多的工作。在分析的时候，我尽量简单明了，不太重要的地方一带而过，具体地大家可以去读代码。相对复杂或者晦涩的地方，将详细展开。

首先我们从配置文件开始，下面的分析是建立在网友对nginx的配置文件结构有大概熟悉为前提，这样才可以很好的理解代码。这里有必要提醒一点：原始代码目录中

ngx_modules这个结构，是找不到它的定义和初始化，要看到它，你必须执行configure，make，在原来的代码目录下会出现一个objs文件夹，里面的3个文件ngx_auto_config.h，ngx_auto_headers.h，ngx_modules.c，需要在建source insight工程时也包含进去，这样有利于我们把握整个代码结构。有意思的是，nginx的configure文件是作者手工写的，里面有许多管理代码工程的方法，有时间的话，也是值得学习下的。

1.ngx_cycle_t *ngx_init_cycle(ngx_cycle_t *old_cycle);

配置文件的解析相关的处理主要在ngx_init_cycle函数中被调用。既然如此，我们就先说说ngx_init_cycle函数吧。

它需要一个参数类型为ngx_cycle_t *，返回值也是一个ngx_cycle_t*，与此同时我们注意到参数名为old_cycle，那么这个函数的作用是啥呢？很明显是由old得到一个new。其中ngx_cycle_t的结构保存一些全局的配置和信息。

这个函数具体作用将在reconfig(重读配置文件)的时候得到体现，可以理解为old_cycle 是当前正在使用的配置信息，当配置文件做了某些修改之后，ngx_init_cycle通过old_cycle 中的一些数据，对new_cycle进行一些设置，在经过进一步的配置解析之后，就可以得到一个new cycle。

2.char *ngx_conf_parse(ngx_conf_t *cf, ngx_str_t *filename)

当我们使用sourceinsight查看这个函数的调用情况时，会发现调用它的地方很多。其实，入口点就在ngx_init_cycle中对ngx_conf_parse调用，后面的所有的调用可以看作是在此之后的递归调用。为什么会是这个样子呢？原因在于nginx是一边读取配置信息，一边解析执行相关的处理，具体一点讲，就是“读一行，执行一行”，一行的定义在这里是指以分号或者是“{”和“}”等结尾的一行，例如：我们解析到http {}，我们就调用针对httpblock的处理，在处理的时候我们又会碰到server {}，自然就会调用server block的处理。。。以此类推！。

对配置文件的读取主要在函数ngx_conf_read_token中，这个函数每次会把

NGX_CONF_BUFFER(即4KB)大小的配置信息读到内存buf中，然后对该buf进行分析。在该函数外，主要通过该函数的返回值在做不同的处理，关于它的返回值的含义，大家可以去细细读下代码，意义很明确！

配置指令我们通过上面的操作就可以拿到了，以空格分开的各个字符串被保存在一个字符串数组里(即cf->args)，这一点代码体现的很明显。之后呢，我们就调用ngx_conf_handler 函数来处理当前拿到的这行配置。这里我们先从总体上说一下ngx_conf_handler这个函数的工作原理：”它遍历系统中所有的模块配置，找到特定模块，并匹配特定命令，然后执行“。下面我们展开来讲一下。

nginx会将所有的模块分类管理，自然各个模块被划分到了一个个“集合”中去，同样一个模块下的指令也是分类的(如属于哪类模块，配置在哪些位置是正确的等等)，所以在每次调用ngx_conf_parse的时候都会指出”我这次解析的配置信息是啥类型“，举例：

conf.module_type= NGX_CORE_MODULE;

conf.cmd_type = NGX_MAIN_CONF;

即解析得到的指令我们将core module类型中查找，并且在找到的module中类型为main conf的指令。

在进入重点之前，我们先看一个地方，就是cf->handler的处理，它是做什么用的？是这样的，nginx的通用处理函数ngx_conf_handler主要是针对cf->args的字符串数组来使用的，像有的配置，如types，charset_map，并不是单纯的字符串数组，指令的参数可能会放在{}中，这样通用的解析和处理函数就不适用了。通过我们注册cf->handler，我们就可以对下面{}中参数做常规的配置处理了。

我们进入到ngx_conf_handler函数中，看看它的工作机理。

3. static ngx_int_t

ngx_conf_handler(ngx_conf_t *cf,ngx_int_t last)

参数last是ngx_conf_read_token解析的返回结果。强调一点的是，cf->args中已经保存了我们需要的各个参数。接下来的处理分4步走：

(1) 模块匹配

代码显示的很明显，它首先会根据你指定的类型，对特定的模块进行查找。

(2) command匹配

找到匹配的模块之后会遍历该模块下的command数组，来从中找到它需要找command信息。如果字面上匹配，还要进行command类型的配置检查，如果此时类型不匹配，nginx会报告给你。

(3) 参数个数匹配