首页 > 代码库 > Nginx 配置解析
Nginx 配置解析
概述
在上一篇文章《 Nginx 启动初始化过程》简单介绍了 Nginx 启动的过程，并分析了其启动过程的源码。在启动过程中有一个步骤非常重要，就是调用函数 ngx_init_cycle()，该函数的调用为配置解析提供了接口。配置解析接口大概可分为两个阶段：准备数据阶段 和 配置解析阶段；
准备数据阶段包括：
- 准备内存；
- 准备错误日志；
- 准备所需数据结构；
配置解析阶段是调用函数：
/* 配置文件解析 */
if (ngx_conf_param(&conf) != NGX_CONF_OK) {/* 带有命令行参数'-g' 加入的配置 */
environ = senv;
ngx_destroy_cycle_pools(&conf);
return NULL;
}
if (ngx_conf_parse(&conf, &cycle->conf_file) != NGX_CONF_OK) {/* 解析配置文件*/
environ = senv;
ngx_destroy_cycle_pools(&conf);
return NULL;
}
配置解析
ngx_conf_t 结构体
该结构体用于 Nginx 在解析配置文件时描述每个指令的属性，也是 Nginx 程序中非常重要的一个数据结构，其定义于文件：src/core/ngx_conf_file.h
/* 解析配置时所使用的结构体 */
struct ngx_conf_s {
char *name; /* 当前解析到的指令 */
ngx_array_t *args; /* 当前指令所包含的所有参数 */
ngx_cycle_t *cycle; /* 待解析的全局变量ngx_cycle_t */
ngx_pool_t *pool; /* 内存池 */
ngx_pool_t *temp_pool;/* 临时内存池，分配一些临时数组或变量 */
ngx_conf_file_t *conf_file;/* 待解析的配置文件 */
ngx_log_t *log; /* 日志信息 */
void *ctx; /* 描述指令的上下文 */
ngx_uint_t module_type;/* 当前解析的指令的模块类型 */
ngx_uint_t cmd_type; /* 当前解析的指令的指令类型 */
ngx_conf_handler_pt handler; /* 模块自定义的handler，即指令自定义的处理函数 */
char *handler_conf;/* 自定义处理函数需要的相关配置 */
};
配置文件信息 conf_file
conf_file 是存放 Nginx 配置文件的相关信息。ngx_conf_file_t 结构体的定义如下：
typedef struct {
ngx_file_t file; /* 文件的属性 */
ngx_buf_t *buffer; /* 文件的内容 */
ngx_uint_t line; /* 文件的行数 */
} ngx_conf_file_t;配置上下文 ctx
Nginx 的配置文件是分块配置的，常见的有 http 块、server 块、location 块以及 upsteam 块和 mail 块等。每一个这样的配置块代表一个作用域。高一级配置块的作用域包含了多个低一级配置块的作用域，也就是有作用域嵌套的现象。这样，配置文件中的许多指令都会同时包含在多个作用域内。比如，http 块中的指令都可能同时处于 http 块、server 块和 location 块等三层作用域内。
在 Nginx 程序解析配置文件时，每一条指令都应该记录自己所属的作用域范围，而配置文件上下文 ctx 变量就是用来存放当前指令所属的作用域的。在 Nginx 配置文件的各种配置块中，http 块可以包含子配置块，这在存储结构上比较复杂。
指令类型 type
Nginx 程序中的不同的指令类型以宏的形式定义在不同的源码头文件中，指令类型是 core 模块类型的定义在文件：src/core/ngx_conf_file.h
#define NGX_DIRECT_CONF 0x00010000 #define NGX_MAIN_CONF 0x01000000 #define NGX_ANY_CONF 0x0F000000
这些是core类型模块支持的指令类型。其中的NGX_DIRECT_CONF类指令在Nginx程序进入配置解析函数之前已经初始化完成，所以在进入配置解析函数之后可以将它们直接解析并存储到实际的数据结构中，从配置文件的结构上来看，它们一般指的就是那些游离于配置块之外、处于配置文件全局块部分的指令。NGX_MAIN_CONF类指令包括event、http、mail、upstream等可以形成配置块的指令，它们没有自己的初始化函数。Nginx程序在解析配置文件时如果遇到NGX_MAIN_CONF类指令，将转入对下一级指令的解析。
以下是event类型模块支持的指令类型。
#define NGX_EVENT_CONF 0x02000000
以下是 http 类型模块支持的指令类型，其定义在文件：src/http/ngx_http_config.h
#define NGX_HTTP_MAIN_CONF 0x02000000 #define NGX_HTTP_SRV_CONF 0x04000000 #define NGX_HTTP_LOC_CONF 0x08000000 #define NGX_HTTP_UPS_CONF 0x10000000 #define NGX_HTTP_SIF_CONF 0x20000000 #define NGX_HTTP_LIF_CONF 0x40000000 #define NGX_HTTP_LMT_CONF 0x80000000
通用模块配置解析
配置解析模块在 src/core/ngx_conf_file.c 中实现。模块提供的接口函数主要是 ngx_conf_parse。另外，模块提供另一个单独的接口 ngx_conf_param，用来解析命令行传递的配置，这个接口也是对 ngx_conf_parse 的包装。首先看下配置解析函数 ngx_conf_parse，其定义如下：
/*
* 函数功能：配置文件解析；
* 支持三种不同的解析类型：
* 1、解析配置文件；
* 2、解析block块设置；
* 3、解析命令行配置；
*/
char *
ngx_conf_parse(ngx_conf_t *cf, ngx_str_t *filename)
{
char *rv;
ngx_fd_t fd;
ngx_int_t rc;
ngx_buf_t buf;
ngx_conf_file_t *prev, conf_file;
enum {
parse_file = 0,
parse_block,
parse_param
} type;
#if (NGX_SUPPRESS_WARN)
fd = NGX_INVALID_FILE;
prev = NULL;
#endif
if (filename) {/* 若解析的是配置文件 */
/* open configuration file */
/* 打开配置文件 */
fd = ngx_open_file(filename->data, NGX_FILE_RDONLY, NGX_FILE_OPEN, 0);
if (fd == NGX_INVALID_FILE) {
ngx_conf_log_error(NGX_LOG_EMERG, cf, ngx_errno,
ngx_open_file_n " \"%s\" failed",
filename->data);
return NGX_CONF_ERROR;
}
prev = cf->conf_file;
cf->conf_file = &conf_file;
if (ngx_fd_info(fd, &cf->conf_file->file.info) == NGX_FILE_ERROR) {
ngx_log_error(NGX_LOG_EMERG, cf->log, ngx_errno,
ngx_fd_info_n " \"%s\" failed", filename->data);
}
cf->conf_file->buffer = &buf;
buf.start = ngx_alloc(NGX_CONF_BUFFER, cf->log);
if (buf.start == NULL) {
goto failed;
}
buf.pos = buf.start;
buf.last = buf.start;
buf.end = buf.last + NGX_CONF_BUFFER;
buf.temporary = 1;
/* 复制文件属性及文件内容 */
cf->conf_file->file.fd = fd;
cf->conf_file->file.name.len = filename->len;
cf->conf_file->file.name.data = http://www.mamicode.com/filename->data;>
从配置解析函数的源码可以看出，该函数分为两个阶段：语法分析 和 指令解析。语法分析由 ngx_conf_read_token() 函数完成。指令解析有两种方式：一种是 Nginx 内建的指令解析机制；另一种是自定义的指令解析机制。自定义指令解析源码如下所示： /* 自定义指令处理函数 */
if (cf->handler) {
/*
* the custom handler, i.e., that is used in the http's
* "types { ... }" directive
*/
if (rc == NGX_CONF_BLOCK_START) {
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "unexpected \"{\"");
goto failed;
}
/* 命令行配置处理函数 */
rv = (*cf->handler)(cf, NULL, cf->handler_conf);
if (rv == NGX_CONF_OK) {
continue;
}
if (rv == NGX_CONF_ERROR) {
goto failed;
}
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, rv);
goto failed;
}
而 Nginx 内置解析机制有函数 ngx_conf_handler() 实现。其定义如下：/* Nginx内建的指令解析机制 */
static ngx_int_t
ngx_conf_handler(ngx_conf_t *cf, ngx_int_t last)
{
char *rv;
void *conf, **confp;
ngx_uint_t i, found;
ngx_str_t *name;
ngx_command_t *cmd;
name = cf->args->elts;
found = 0;
for (i = 0; ngx_modules[i]; i++) {
cmd = ngx_modules[i]->commands;
if (cmd == NULL) {
continue;
}
for ( /* void */ ; cmd->name.len; cmd++) {
if (name->len != cmd->name.len) {
continue;
}
if (ngx_strcmp(name->data, cmd->name.data) != 0) {
continue;
}
found = 1;
/*
* 只处理模块类型为NGX_CONF_MODULE 或是当前正在处理的模块类型；
*/
if (ngx_modules[i]->type != NGX_CONF_MODULE
&& ngx_modules[i]->type != cf->module_type)
{
continue;
}
/* is the directive's location right ? */
if (!(cmd->type & cf->cmd_type)) {
continue;
}
/* 非block块指令必须以";"分号结尾，否则出错返回 */
if (!(cmd->type & NGX_CONF_BLOCK) && last != NGX_OK) {
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
"directive \"%s\" is not terminated by \";\"",
name->data);
return NGX_ERROR;
}
/* block块指令必须后接"{"大括号，否则出粗返回 */
if ((cmd->type & NGX_CONF_BLOCK) && last != NGX_CONF_BLOCK_START) {
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
"directive \"%s\" has no opening \"{\"",
name->data);
return NGX_ERROR;
}
/* is the directive's argument count right ? */
/* 验证指令参数个数是否正确 */
if (!(cmd->type & NGX_CONF_ANY)) {
/* 指令携带的参数只能是 1 个，且其参数值只能是 on 或 off */
if (cmd->type & NGX_CONF_FLAG) {
if (cf->args->nelts != 2) {
goto invalid;
}
} else if (cmd->type & NGX_CONF_1MORE) {/* 指令携带的参数必须超过 1 个 */
if (cf->args->nelts < 2) {
goto invalid;
}
} else if (cmd->type & NGX_CONF_2MORE) {/* 指令携带的参数必须超过 2 个 */
if (cf->args->nelts < 3) {
goto invalid;
}
} else if (cf->args->nelts > NGX_CONF_MAX_ARGS) {
goto invalid;
} else if (!(cmd->type & argument_number[cf->args->nelts - 1]))
{
goto invalid;
}
}
/* set up the directive's configuration context */
conf = NULL;
if (cmd->type & NGX_DIRECT_CONF) {/* 在core模块使用 */
conf = ((void **) cf->ctx)[ngx_modules[i]->index];
} else if (cmd->type & NGX_MAIN_CONF) {/* 指令配置项出现在全局配置中，不属于任何{}配置块 */
conf = &(((void **) cf->ctx)[ngx_modules[i]->index]);
} else if (cf->ctx) {/* 除了core模块，其他模块都是用该项 */
confp = *(void **) ((char *) cf->ctx + cmd->conf);
if (confp) {
conf = confp[ngx_modules[i]->ctx_index];
}
}
/* 执行指令解析回调函数 */
rv = cmd->set(cf, cmd, conf);
if (rv == NGX_CONF_OK) {
return NGX_OK;
}
if (rv == NGX_CONF_ERROR) {
return NGX_ERROR;
}
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
"\"%s\" directive %s", name->data, rv);
return NGX_ERROR;
}
}
if (found) {
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
"\"%s\" directive is not allowed here", name->data);
return NGX_ERROR;
}
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
"unknown directive \"%s\"", name->data);
return NGX_ERROR;
invalid:
ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
"invalid number of arguments in \"%s\" directive",
name->data);
return NGX_ERROR;
}
HTTP 模块配置解析
这里主要是结构体 ngx_command_t ，我们在文章 《Nginx 模块开发》 对该结构体作了介绍，其定义如下：
struct ngx_command_s {
/* 配置项名称 */
ngx_str_t name;
/* 配置项类型，type将指定配置项可以出现的位置以及携带参数的个数 */
ngx_uint_t type;
/* 处理配置项的参数 */
char *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf);
/* 在配置文件中的偏移量，conf与offset配合使用 */
ngx_uint_t conf;
ngx_uint_t offset;
/* 配置项读取后的处理方法，必须指向ngx_conf_post_t 结构 */
void *post;
};
若在上面的通用配置解析中，定义了如下的 http 配置项结构，则回调用 http 配置项，并对该 http 配置项进行解析。此时，解析的是 http block块设置。
static ngx_command_t ngx_http_commands[] = {
{ ngx_string("http"),
NGX_MAIN_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS,
ngx_http_block,
0,
0,
NULL },
ngx_null_command
};
http 是作为一个 core 模块被 nginx 通用解析过程解析的，其核心就是 http{} 块指令回调，它完成了 http 解析的整个功能，从初始化到计算配置结果。http{} 块指令的流程是：
- 创建并初始化上下文结构；
- 调用通用模块配置解析流程解析；
- 根据解析结果进行配置项合并处理；
创建并初始化上下文结构
当 Nginx 检查到 http{…} 配置项时，HTTP 配置模型就会启动，则会建立一个 ngx_http_conf_ctx_t 结构，该结构定义在文件中：src/http/ngx_http_config.h
typedef struct{
/* 指针数组，数组中的每个元素指向所有 HTTP 模块 create_main_conf 方法产生的结构体 */
void **main_conf;
/* 指针数组，数组中的每个元素指向所有 HTTP 模块 create_srv_conf 方法产生的结构体 */
void **srv_conf;
/* 指针数组，数组中的每个元素指向所有 HTTP 模块 create_loc_conf 方法产生的结构体 */
void **loc_conf;
}ngx_http_conf_ctx_t;
此时，HTTP 框架为所有 HTTP 模块建立 3 个数组，分别存放所有 HTTP 模块的 create_main_conf、create_srv_conf 、create_loc_conf 方法返回的地址指针。ngx_http_conf_ctx_t 结构的三个成员分别指向这 3 个数组。例如下面的例子是设置 create_main_conf、create_srv_conf 、create_loc_conf 返回的地址。
ngx_http_conf_ctx *ctx;
/* HTTP 框架生成 1 个 ngx_http_conf_ctx_t 结构变量 */
ctx = ngx_pcalloc(cf->pool, sizeof(ngx_http_conf_ctx_t));
*(ngx_http_conf_ctx_t **) conf = ctx;
...
/* 分别生成 3 个数组存储所有的 HTTP 模块的 create_main_conf、create_srv_conf、create_loc_conf 方法返回的地址 */
ctx->main_conf = ngx_pcalloc(cf->pool,
sizeof(void *) * ngx_http_max_module);
ctx->srv_conf = ngx_pcalloc(cf->pool, sizeof(void *) * ngx_http_max_module);
ctx->loc_conf = ngx_pcalloc(cf->pool, sizeof(void *) * ngx_http_max_module);
/* 遍历所有 HTTP 模块 */
for (m = 0; ngx_modules[m]; m++) {
if (ngx_modules[m]->type != NGX_HTTP_MODULE) {
continue;
}
module = ngx_modules[m]->ctx;
mi = ngx_modules[m]->ctx_index;
/* 若实现了create_main_conf 方法，则调用该方法，并把返回的地址存储到 main_conf 中 */
if (module->create_main_conf) {
ctx->main_conf[mi] = module->create_main_conf(cf);
}
/* 若实现了create_srv_conf 方法，则调用该方法，并把返回的地址存储到 srv_conf 中 */
if (module->create_srv_conf) {
ctx->srv_conf[mi] = module->create_srv_conf(cf);
}
/* 若实现了create_loc_conf 方法，则调用该方法，并把返回的地址存储到 loc_conf 中 */
if (module->create_loc_conf) {
ctx->loc_conf[mi] = module->create_loc_conf(cf);
}
}
pcf = *cf;
cf->ctx = ctx;
for (m = 0; ngx_modules[m]; m++) {
if (ngx_modules[m]->type != NGX_HTTP_MODULE) {
continue;
}
module = ngx_modules[m]->ctx;
if (module->preconfiguration) {
if (module->preconfiguration(cf) != NGX_OK) {
return NGX_CONF_ERROR;
}
}
}
调用通用模块配置解析流程解析
从源码src/http/ngx_http.c中可以看到，http 块的配置解析是调用通用模块的配置解析函数，其实现如下：
/* 调用通用模块配置解析 */
/* parse inside the http{} block */
cf->module_type = NGX_HTTP_MODULE;
cf->cmd_type = NGX_HTTP_MAIN_CONF;
rv = ngx_conf_parse(cf, NULL);
if (rv != NGX_CONF_OK) {
goto failed;
}
根据解析结果进行配置项合并处理
/* 根据解析结构进行合并处理 */
/*
* init http{} main_conf's, merge the server{}s' srv_conf's
* and its location{}s' loc_conf's
*/
cmcf = ctx->main_conf[ngx_http_core_module.ctx_index];
cscfp = cmcf->servers.elts;
for (m = 0; ngx_modules[m]; m++) {
if (ngx_modules[m]->type != NGX_HTTP_MODULE) {
continue;
}
module = ngx_modules[m]->ctx;
mi = ngx_modules[m]->ctx_index;
/* init http{} main_conf's */
if (module->init_main_conf) {
rv = module->init_main_conf(cf, ctx->main_conf[mi]);
if (rv != NGX_CONF_OK) {
goto failed;
}
}
rv = ngx_http_merge_servers(cf, cmcf, module, mi);
if (rv != NGX_CONF_OK) {
goto failed;
}
}
/* create location trees */
for (s = 0; s < cmcf->servers.nelts; s++) {
clcf = cscfp[s]->ctx->loc_conf[ngx_http_core_module.ctx_index];
if (ngx_http_init_locations(cf, cscfp[s], clcf) != NGX_OK) {
return NGX_CONF_ERROR;
}
if (ngx_http_init_static_location_trees(cf, clcf) != NGX_OK) {
return NGX_CONF_ERROR;
}
}
if (ngx_http_init_phases(cf, cmcf) != NGX_OK) {
return NGX_CONF_ERROR;
}
if (ngx_http_init_headers_in_hash(cf, cmcf) != NGX_OK) {
return NGX_CONF_ERROR;
}
for (m = 0; ngx_modules[m]; m++) {
if (ngx_modules[m]->type != NGX_HTTP_MODULE) {
continue;
}
module = ngx_modules[m]->ctx;
if (module->postconfiguration) {
if (module->postconfiguration(cf) != NGX_OK) {
return NGX_CONF_ERROR;
}
}
}
if (ngx_http_variables_init_vars(cf) != NGX_OK) {
return NGX_CONF_ERROR;
}
/*
* http{}'s cf->ctx was needed while the configuration merging
* and in postconfiguration process
*/
*cf = pcf;
if (ngx_http_init_phase_handlers(cf, cmcf) != NGX_OK) {
return NGX_CONF_ERROR;
}
/* optimize the lists of ports, addresses and server names */
if (ngx_http_optimize_servers(cf, cmcf, cmcf->ports) != NGX_OK) {
return NGX_CONF_ERROR;
}
return NGX_CONF_OK;
failed:
*cf = pcf;
return rv;
Nginx 配置解析
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。