从本节开始，我们将进入http模块实现原理的讲解，关于http模块，有一个非常重要的点就是其是如何存储http块、server块和location块的数据的，而且nginx有的配置项是可以在多个配置块中使用的，当http块、server块和location块中两个或者两个以上的配置块都配置了该配置项的时候，就会有一个问题是，nginx是如何处理这些配置项的。本文主要讲解http块中的各个模块数据的存储方式，这将是理解nginx的http模块的工作方式的重要基石。

1. 核心模块的存储方式

在nginx运行过程中，有一个全局配置结构体 ngx_cycle_t ，其有一个属性 conf_ctx ，这个属性是存储nginx所有模块配置的一个数组，这个数组的长度与nginx模块的个数相同。不过需要注意的是， conf_ctx 数组的第一维只会存储核心模块的配置，而其他模块对应的位置处的数组元素其实是为NULL。在 conf_ctx 中，各个核心模块配置结构体的存储位置与该模块在所有模块（包括非核心模块）中的相对位置是一致的，如下图所示为nginx存储核心模块的一个结构示意图：

这里标注的 events 和 http 只是为了展示方便而添加的，本质上这个数组的元素的类型是 void* 的指针，至于该指针指向的具体结构体的类型，则是根据各个核心模块自身的定义来的。

在http模块下，其指向了一个 ngx_http_conf_ctx_t 类型的结构体，这个结构体的作用就是用来存储http配置块中各个配置项的数据的。如下是这个结构体的定义：

typedef struct {
 	// 存储MAIN级别配置
  void **main_conf;
 	// 存储SRV级别配置
  void **srv_conf;
 	// 存储LOC级别配置
  void **loc_conf;
} ngx_http_conf_ctx_t;

我们知道，在nginx.conf配置文件中，在http块下还配置有server块，而server块下也是可以有location块，更有甚者，在location块下可以有子location块，如此往复，而这里的 ngx_http_conf_ctx_t 结构体的作用就是存储所有的这些配置所对应的结构体数据。首先，我们需要明确的一点是，在nginx.conf配置文件中，配置项都是由一个个模块定义的，一个模块可以定义多个配置项，对于这些配置项的解析工作都是由这个模块所定义的方法进行的。但是，一般的，一个模块一般都只会定义一个结构体，这个结构体中的各个属性则对应于该模块所定义的各个配置项的数据，也就是说，通过各个模块所定义的方法，其会将其所定义的配置项对应的配置转换为该模块所定义的结构体。这里所说的结构体就对应于上面的 main_conf 、 srv_conf 和 loc_conf 中的配置。从上面的定义就可以看出，这三个属性的类型都是指针类型的数组，而数组的长度就对应于模块的个数，准确来讲，是对应于http模块的各个。在解析各个http模块的配置之前，nginx会对各个http模块在当前类型的模块（http模块）中进行相对位置进行标记，每个http模块的相对位置就对应于上面的三个属性的数组下标。前面已经讲到，每个http模块都只会有一个配置结构体存储该模块所定义的所有配置数据，而这些配置结构体就是存储在上面的三个数组中的。这样，我们就能够理解了，其实上面的结构体的三个属性，每一个属性的数组都对应了一个http模块的配置结构体。

既然这里每个模块都有一个结构体存储在数组的对应索引位置，那这里为什么需要三个数组呢？比如说，对于 ngx_http_core_module ，其相对位置在http模块是第一个，也就是说 main_conf[0] 、 srv_conf[0] 和 loc_conf[0] 存储的都是 ngx_http_core_module 的配置结构体，为什么需要三个结构体。这里我们需要说明的是，对于每个http模块，其会根据需要将配置项按照可使用范围划分为三类：仅用于http块，可以用于http块和server块，以及可以用于http块、server块和location块。每一类配置项都使用的是一个不同的结构体，比如 ngx_http_core_module 就定义了 ngx_http_core_main_conf_t 用于存储仅用于http块的配置项，定义了 ngx_http_core_srv_conf_t 用于存储用于http块和server块的配置项，定义了 ngx_http_core_loc_conf_t 用于存储用于http块、server块和location块的配置项。对应于上面的数组就是， main_conf[0] 的结构体类型为 ngx_http_core_main_conf_t ， srv_conf[0] 的结构体类型为 ngx_http_core_srv_conf_t ， loc_conf[0] 对应的结构体类型为 ngx_http_core_loc_conf_t 。说到这里，我们就必须要厘清一个问题了，比如，对于某个配置项，其配置在了http块中，但是其类型是可以用于http块、server块和location块的，那么其就会被存储在 loc_conf[0] 中，也就是说，上面的一整个结构体，从目前来看，存储的都是在http块中解析出来的各个配置项的数据。那么nginx是如何标记一个配置项是这三种类型中的哪一种呢？这主要是通过 ngx_command_t 结构体来定义的，如下所示为三个典型的配置：

{
 ngx_string("variables_hash_max_size"),
 NGX_HTTP_MAIN_CONF | NGX_CONF_TAKE1,
 ngx_conf_set_num_slot,
 	NGX_HTTP_MAIN_CONF_OFFSET,
 	offsetof(ngx_http_core_main_conf_t, variables_hash_max_size),
 	NULL
},
{
 ngx_string("listen"),
 	NGX_HTTP_SRV_CONF | NGX_CONF_1MORE,
 	ngx_http_core_listen,
 	NGX_HTTP_SRV_CONF_OFFSET,
 	0,
 	NULL
},
{
 ngx_string("root"),
 	NGX_HTTP_MAIN_CONF | NGX_HTTP_SRV_CONF | NGX_HTTP_LOC_CONF | NGX_HTTP_LIF_CONF
 	 | NGX_CONF_TAKE1,
 	ngx_http_core_root,
 	NGX_HTTP_LOC_CONF_OFFSET,
 	0,
 	NULL
},

这里我们以 variables_hash_max_size 、 listen 和 root 三个指令为例，这三个指令都是 ngx_http_core_module 模块定义的配置项，但是它们存储的位置则是完全不同的。我们需要注意的就是每个指令的第四个属性的定义： NGX_HTTP_MAIN_CONF_OFFSET 、 NGX_HTTP_SRV_CONF_OFFSET 和 NGX_HTTP_LOC_CONF_OFFSET 。这三个类型的定义有两重含义，一个是表示这个配置项是仅用于http块，还是可以用于http块和server块，再或者是可以用于http块、server块和location块；另一重含义是定义了这个配置项在上面讲的 ngx_http_conf_ctx_t 中的偏移量，所谓的偏移量指的就是，在知道 ngx_http_conf_ctx_t 结构体对象的指针地址时，通过这里的偏移量就可以计算出当前配置项所存储的数组。这里我们就需要展示一段代码，即在 ngx_conf_parse() 方法中，其主要是用于解析nginx.conf配置文件的，在解析了某个配置项之后，就会在所有的模块中，找到该配置项的定义，如果找到了配置项，就会尝试获取存储该配置项所对应的结构体，并且会调用该配置项指定的方法进行配置项数据的解析。这里尝试获取该配置项所对应的结构体时，就需要用上上面的偏移量。如下是获取该配置项的方法：

// 查找配置对象，NGX_DIRECT_CONF常量单纯用来指定配置存储区的寻址方法，只用于core模块
if (cmd->type & NGX_DIRECT_CONF) {
 conf = ((void **) cf->ctx)[cf->cycle->modules[i]->index];

 // NGX_MAIN_CONF常量有两重含义，其一是指定指令的使用上下文是main（其实还是指core模块），
 // 其二是指定配置存储区的寻址方法。
} else if (cmd->type & NGX_MAIN_CONF) {
 conf = &(((void **) cf->ctx)[cf->cycle->modules[i]->index]);

 // 除开core模块，其他类型的模块都会使用第三种配置寻址方式，也就是根据cmd->conf的值
 // 从cf->ctx中取出对应的配置。举http模块为例，cf->conf的可选值是NGX_HTTP_MAIN_CONF_OFFSET、
 // NGX_HTTP_SRV_CONF_OFFSET、NGX_HTTP_LOC_CONF_OFFSET，
 // 分别对应“http{}”、“server{}”、“location{}”这三个http配置级别。

 // 这个if判断的作用主要是，cf->ctx的类型是ngx_http_conf_ctx_t，而cmd->conf主要的值可选
 // NGX_HTTP_MAIN_CONF_OFFSET、NGX_HTTP_SRV_CONF_OFFSET、NGX_HTTP_LOC_CONF_OFFSET，
 // 可以看到ngx_http_conf_ctx_t的属性有main_conf、srv_conf和loc_conf，
 // 其实这里就是在计算当前的配置对象是存储在这三个数组中的哪一个数组中，以default_type指令为例，
 // 其ngx_command_t的配置为：
 // {ngx_string("default_type"),
 //   NGX_HTTP_MAIN_CONF | NGX_HTTP_SRV_CONF | NGX_HTTP_LOC_CONF | NGX_CONF_TAKE1,
 //   ngx_conf_set_str_slot,
 //   NGX_HTTP_LOC_CONF_OFFSET,
 //   offsetof(ngx_http_core_loc_conf_t, default_type),
 //   NULL},
 // 可以看到，其conf属性的值为NGX_HTTP_LOC_CONF_OFFSET，则说明其是存储在loc_conf数组中的，
 // 而该数组中的元素类型为ngx_http_core_loc_conf_t，因而可以看到，后面ngx_command_t
 // 中offset属性的值就指定为了offsetof(ngx_http_core_loc_conf_t, default_type)，
 // 这就是在计算default_type属性在ngx_http_core_loc_conf_t结构体中的位置。
 // 通过下面的if判断第一步confp = *(void **) ((char *) cf->ctx + cmd->conf);，就可以
 // 计算出当前所使用的结构体是在main_conf、srv_conf
 // 和loc_conf的哪一个数组中，而通过第二步conf = confp[cf->cycle->modules[i]->ctx_index];
 // 的计算，就可以计算出该结构体在数组中的具体位置，并且获取该结构体数据。
 // 需要注意的是，这种计算方式只适用于http模块的配置项获取，因为只有http模块的配置结构体是
 // ngx_http_conf_ctx_t类型的
} else if (cf->ctx) {
 confp = *(void **) ((char *) cf->ctx + cmd->conf);

 if (confp) {
  conf = confp[cf->cycle->modules[i]->ctx_index];
 }
}

这里我们需要重点关注最后一个 else if 分支，这里就表明了http模块是如何根据配置项的定义来计算该配置项所对应的结构体的存储位置的。下面的图就展示了包含有http块配置的整体结构：

2. server块的存储方式

上面我们讲到，使用 ngx_http_conf_ctx_t 结构体就可以存储所有的http块中的配置项，那么server块中的配置项是如何存储的呢？其主要存储在 ngx_http_core_module 模块的 main_conf 中，也即上面的 main_conf[0] 所对应的 ngx_http_core_main_conf_t 结构体中，该结构体有一个属性 servers ，这个属性的类型为 ngx_array_t ，也即一个数组。也就是说，在每个http配置块下，每个server配置块都对应于 servers 数组的一个元素，而数组的元素类型与http块的一致，还是 ngx_http_conf_ctx_t 。不过区别在于，由于当前的配置项一定是可用于server块或者location块中的，而不是仅仅只能用于http块中的，因而配置项的类型一定是上面讲到的 NGX_HTTP_SRV_CONF_OFFSET 和 NGX_HTTP_LOC_CONF_OFFSET 之一，而不可能是 NGX_HTTP_MAIN_CONF_OFFSET 。因而这里虽然每个server配置块对应的配置结构体还是 ngx_http_conf_ctx_t ，但是其 main_conf 数组是不会有对应的配置项的，而只能从http块中继承配置项。既然是继承，nginx的处理方式是直接将该数组的指针指向http块对应的 ngx_http_conf_ctx_t 的 main_conf 数组。如下所示为两个server块配置的示意图：

这个图稍微看起来有点复杂，但实际上并不复杂，按照配置块划分，上面的 ngx_http_conf_ctx_t 中存储的就是http块的配置，而下面的两个 ngx_http_conf_ctx_t 存储的就是两个server块中的配置，中间的引用过程是通过http块的 ngx_http_core_module 模块对应的 ngx_http_core_main_conf_t.servers 进行的。需要注意的一点是，上面的server块的配置中， main_conf 指针都是指向的http块的对应 ngx_http_conf_ctx_t 的 main_conf 属性。

3. location块的存储方式

对于location块的存储，其存储结构也还是 ngx_http_conf_ctx_t ，并且由于当前配置项在location块中的，因而其类型一定不会是 NGX_HTTP_MAIN_CONF_OFFSET 和 NGX_HTTP_SRV_CONF_OFFSET ，也就是说，解析location配置项得到的数据一定是存储在 loc_conf 数组中的。因而，与server块一样，location块对应的 ngx_http_conf_ctx_t 结构体中的 main_conf 和 srv_conf 指向的则是当前location所在的http块的 main_conf 和所在的server块的 srv_conf 数组。

另外，一个server块下会有多个location块，在存储结构上，这些location块是以队列的方式进行组织的，与server块类似，这个队列则是存储在其所在的server块对应的 ngx_http_conf_ctx_t 的 loc_conf[0] 中的。这里的 loc_conf[0] 的结构体类型为 ngx_http_core_loc_conf_s ，其有一个 ngx_queue_t 类型的属性 locations 就是该location队列。最后需要注意的是，这里的 locations 属性表征的不仅仅只是server块下的多个location块，因为在location配置块下还可以继续配置多个location块，如此不断递归下去。这些子location块的类型其实还是 ngx_http_core_loc_conf_s ，因而也是可以通过 locations 属性进行表征的。如下是加入location配置块的结构体示意图：

图中展示了两个location并列组织的情形，其 main_conf 和 srv_conf 分别指向了http块的 main_conf 和当前location块所在的server块的 srv_conf ，并且两个location块对应的结构体是以队列的方式组织在 ngx_http_core_loc_conf_t 中的。

4. 小结

本文从 ngx_cycle_t 结构体开始，介绍了http块的配置项是如何存储在 ngx_cycle_t 中的，并且依次介绍了http块、server块和location块的存储方式，以及相互之间的组织方式。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。