现在针对nginx源码分析的blog和文章已经很多了，之前我也看过不少，大家的分析都很不错。在这里，我不想写太多重复的内容，只是针对在我分析代码和查阅blog的过程中，发现的一些比较晦涩或者某些细节有待展开讨论的地方，给出我的自己理解和看法，希望跟大家交流和学习。标题为情景分析，目的是向许多情景分析经典（如linux内核情景分析）致敬，力求做到深入深刻。
使用的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。好了，init 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匹配