nginx http模块数据存储结构

        从本节开始，我们将进入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块的存储方式，以及相互之间的组织方式。