|
Starting from this section, we will explain the implementation principle of the http module. A very important point about the http module is how it stores data in the http block, server block, and location block. Some configuration items of nginx can be used in multiple configuration blocks. When two or more configuration blocks in the http block, server block, and location block are configured with the configuration item, there will be a question of how nginx handles these configuration items. This article mainly explains how the data of each module in the http block is stored, which will be an important cornerstone for understanding how the http module of nginx works. 1. Storage method of core modules During the running of nginx, there is a global configuration structure ngx_cycle_t , which has an attribute conf_ctx . This attribute is an array that stores the configuration of all nginx modules. The length of this array is the same as the number of nginx modules. However, it should be noted that the first dimension of the conf_ctx array only stores the configuration of the core module, and the array elements at the corresponding positions of other modules are actually NULL. In conf_ctx , the storage location of each core module configuration structure is consistent with the relative position of the module in all modules (including non-core modules). The following figure is a structural diagram of nginx storage core modules: 
events and http marked here are added only for the convenience of demonstration. In essence, the type of the elements of this array is a void* pointer. As for the type of the specific structure pointed to by the pointer, it is based on the definition of each core module itself. Under the http module, it points to a structure of type ngx_http_conf_ctx_t , which is used to store the data of each configuration item in the http configuration block. The following is the definition of this structure:
typedef struct {
//Store MAIN level configuration void **main_conf;
//Store SRV level configuration void **srv_conf;
//Store LOC level configuration void **loc_conf;
} ngx_http_conf_ctx_t; We know that in the nginx.conf configuration file, there is a server block under the http block, and there can be a location block under the server block. What's more, there can be a sub-location block under the location block, and so on. The role of the ngx_http_conf_ctx_t structure here is to store the structure data corresponding to all these configurations. First of all, we need to make it clear that in the nginx.conf configuration file, configuration items are defined by modules. A module can define multiple configuration items, and the parsing of these configuration items is performed by the methods defined by this module. However, generally, a module will only define one structure, and the various attributes in this structure correspond to the data of each configuration item defined by the module. That is to say, through the methods defined by each module, it will convert the configuration corresponding to the configuration item defined by it into the structure defined by the module. The structure mentioned here corresponds to the configuration in main_conf , srv_conf and loc_conf above. From the above definition, we can see that the types of these three attributes are arrays of pointer types, and the length of the array corresponds to the number of modules, or more precisely, to the number of http modules. Before parsing the configuration of each http module, nginx will mark the relative position of each http module in the current type of module (http module). The relative position of each http module corresponds to the array subscript of the above three attributes. As mentioned earlier, each http module will only have one configuration structure to store all the configuration data defined by the module, and these configuration structures are stored in the three arrays above. In this way, we can understand that, in fact, the three attributes of the above structure, each attribute array corresponds to a configuration structure of the http module. Since each module here has a structure stored at the corresponding index position of the array, why are three arrays needed here? For example, for ngx_http_core_module , its relative position in the http module is the first, that is to say, main_conf[0] , srv_conf[0] and loc_conf[0] all store the configuration structure of ngx_http_core_module . Why are three structures needed? What we need to explain here is that for each http module, it will divide the configuration items into three categories according to the scope of use: only for http block, can be used for http block and server block, and can be used for http block, server block and location block. Each type of configuration item uses a different structure. For example, ngx_http_core_module defines ngx_http_core_main_conf_t to store configuration items used only for the http block, ngx_http_core_srv_conf_t to store configuration items used for the http block and server block, and ngx_http_core_loc_conf_t to store configuration items used for the http block, server block, and location block. Corresponding to the above array, the structure type of main_conf[0] is ngx_http_core_main_conf_t , the structure type of srv_conf[0] is ngx_http_core_srv_conf_t , and the structure type of loc_conf[0] is ngx_http_core_loc_conf_t . At this point, we must clarify a problem. For example, for a certain configuration item, it is configured in the http block, but its type can be used in the http block, server block and location block, then it will be stored in loc_conf[0] . In other words, the entire structure above, from the current point of view, stores the data of each configuration item parsed in the http block. So how does nginx mark which of these three types a configuration item is? This is mainly defined by the ngx_command_t structure. The following are three typical configurations:
{
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
}, Here we take variables_hash_max_size , listen and root as examples. These three instructions are configuration items defined by the ngx_http_core_module module, but their storage locations are completely different. What we need to pay attention to is the definition of the fourth attribute of each directive: NGX_HTTP_MAIN_CONF_OFFSET , NGX_HTTP_SRV_CONF_OFFSET , and NGX_HTTP_LOC_CONF_OFFSET . The definition of these three types has two meanings. One is to indicate whether this configuration item is only used for http block, or can be used for http block and server block, or can be used for http block, server block and location block. The other meaning is to define the offset of this configuration item in ngx_http_conf_ctx_t mentioned above. The so-called offset means that when the pointer address of the ngx_http_conf_ctx_t structure object is known, the array stored in the current configuration item can be calculated through the offset here. Here we need to show a piece of code, that is, in ngx_conf_parse() method, which is mainly used to parse the nginx.conf configuration file. After parsing a configuration item, it will find the definition of the configuration item in all modules. If the configuration item is found, it will try to obtain the structure corresponding to the configuration item, and will call the method specified by the configuration item to parse the configuration item data. When trying to get the structure corresponding to the configuration item here, you need to use the above offset. Here is how to get this configuration item:
// Find the configuration object. The NGX_DIRECT_CONF constant is simply used to specify the addressing method of the configuration storage area. It is only used in the core module if (cmd->type & NGX_DIRECT_CONF) {
conf = ((void **) cf->ctx)[cf->cycle->modules[i]->index];
// The NGX_MAIN_CONF constant has two meanings. One is that the context of the specified instruction is main (actually it still refers to the core module).
// The second is to specify the addressing method of the configuration storage area.
} else if (cmd->type & NGX_MAIN_CONF) {
conf = &(((void **) cf->ctx)[cf->cycle->modules[i]->index]);
// Except for the core module, other types of modules will use the third configuration addressing method, that is, according to the value of cmd->conf// take the corresponding configuration from cf->ctx. Taking the http module as an example, the optional values of cf->conf are NGX_HTTP_MAIN_CONF_OFFSET,
// NGX_HTTP_SRV_CONF_OFFSET, NGX_HTTP_LOC_CONF_OFFSET,
// Corresponding to the three http configuration levels "http{}", "server{}" and "location{}" respectively.
// The main function of this if judgment is that the type of cf->ctx is ngx_http_conf_ctx_t, and the main value of cmd->conf is optional // NGX_HTTP_MAIN_CONF_OFFSET, NGX_HTTP_SRV_CONF_OFFSET, NGX_HTTP_LOC_CONF_OFFSET,
// You can see that the attributes of ngx_http_conf_ctx_t are main_conf, srv_conf and loc_conf,
// In fact, here is to calculate which of the three arrays the current configuration object is stored in. Take the default_type instruction as an example.
// Its ngx_command_t configuration is:
// {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},
// As you can see, the value of its conf attribute is NGX_HTTP_LOC_CONF_OFFSET, which means it is stored in the loc_conf array.
// The element type in the array is ngx_http_core_loc_conf_t, so you can see that the following ngx_command_t
// The value of the offset attribute is specified as offsetof(ngx_http_core_loc_conf_t, default_type),
// This is how the default_type attribute is calculated in the ngx_http_core_loc_conf_t structure.
// Through the following if judgment step confp = *(void **) ((char *) cf->ctx + cmd->conf);, we can // calculate whether the currently used structure is in main_conf, srv_conf
// and loc_conf in which array, and through the second step conf = confp[cf->cycle->modules[i]->ctx_index];
// The calculation can calculate the specific position of the structure in the array and obtain the structure data.
// Note that this calculation method is only applicable to the configuration item acquisition of the http module, because only the configuration structure of the http module is of // ngx_http_conf_ctx_t type} else if (cf->ctx) {
confp = *(void **) ((char *) cf->ctx + cmd->conf);
if (confp) {
conf = confp[cf->cycle->modules[i]->ctx_index];
}
} Here we need to focus on the last else if branch, which shows how the http module calculates the storage location of the structure corresponding to the configuration item based on the definition of the configuration item. The following figure shows the overall structure including the http block configuration: 
2. Storage of server blocks As we mentioned above, the ngx_http_conf_ctx_t structure can be used to store all the configuration items in the http block, so how are the configuration items in the server block stored? It is mainly stored in main_conf of the ngx_http_core_module module, that is, in the ngx_http_core_main_conf_t structure corresponding to main_conf[0] above. The structure has an attribute servers , and the type of this attribute is ngx_array_t , that is, an array. That is to say, under each http configuration block, each server configuration block corresponds to an element of servers array, and the element type of the array is consistent with that of the http block, which is still ngx_http_conf_ctx_t . However, the difference is that since the current configuration item must be available in the server block or location block, rather than just in the http block, the type of the configuration item must be one of NGX_HTTP_SRV_CONF_OFFSET and NGX_HTTP_LOC_CONF_OFFSET mentioned above, and it cannot be NGX_HTTP_MAIN_CONF_OFFSET . Therefore, although the configuration structure corresponding to each server configuration block is still ngx_http_conf_ctx_t , its main_conf array will not have corresponding configuration items, but can only inherit configuration items from the http block. Since it is inheritance, nginx handles it by directly pointing the pointer of the array to main_conf array of ngx_http_conf_ctx_t corresponding to the http block. The following is a diagram of the configuration of two server blocks: 
This diagram looks a bit complicated, but it is not complicated. According to the configuration block division, ngx_http_conf_ctx_t above stores the configuration of the http block, and the two ngx_http_conf_ctx_t below store the configuration of the two server blocks. The intermediate reference process is carried out through ngx_http_core_main_conf_t.servers corresponding to the ngx_http_core_module module of the http block. One thing to note is that in the above server block configuration, main_conf pointer points to main_conf attribute of the corresponding ngx_http_conf_ctx_t in the http block. 3. Storage method of location block For the storage of location blocks, its storage structure is still ngx_http_conf_ctx_t , and because the current configuration item is in the location block, its type will definitely not be NGX_HTTP_MAIN_CONF_OFFSET and NGX_HTTP_SRV_CONF_OFFSET , that is, the data obtained by parsing the location configuration item must be stored in loc_conf array. Therefore, like the server block, main_conf and srv_conf in the ngx_http_conf_ctx_t structure corresponding to the location block point to main_conf of the http block where the current location is located and srv_conf array of the server block where it is located. In addition, there will be multiple location blocks under a server block. In terms of storage structure, these location blocks are organized in the form of queues. Similar to the server block, this queue is stored in loc_conf[0] of ngx_http_conf_ctx_t corresponding to the server block where it is located. The structure type of loc_conf[0] here is ngx_http_core_loc_conf_s , which has an attribute locations of type ngx_queue_t , which is the location queue. Finally, it should be noted that locations attribute here represents more than just multiple location blocks under the server block, because multiple location blocks can continue to be configured under the location configuration block, and so on recursively. The type of these sub-location blocks is actually ngx_http_core_loc_conf_s , so they can also be represented by locations attribute. The following is a schematic diagram of the structure of adding the location configuration block: 
The figure shows the situation where two locations are organized in parallel, where main_conf and srv_conf point to main_conf of the http block and srv_conf of the server block where the current location block is located respectively, and the structures corresponding to the two location blocks are organized in ngx_http_core_loc_conf_t in a queue manner. 4. Summary This article starts with the ngx_cycle_t structure and introduces how the configuration items of the http block are stored in ngx_cycle_t . It also introduces the storage methods of the http block, server block, and location block, as well as their organization with each other. The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM. You may also be interested in:- Common instructions for nginx HTTP module configuration
|
