国内最全IT社区平台 联系我们 | 收藏本站
华晨云阿里云优惠2
您当前位置:首页 > php开源 > 综合技术 > Nginx 模块自主开发六:源码剖析配置文件解析过程

Nginx 模块自主开发六:源码剖析配置文件解析过程

来源:程序员人生   发布时间:2016-07-19 13:17:47 阅读次数:2756次

 Nginx源码实现有1个很好的优点就是模块化,有点像面向对象语言的设计模式,实现“高内聚,松耦合”,这篇博客主要讲授模块的共有流程
集中在ngx_cycle.c、 ngx_process.c、 ngx_process_cycle.c 和 ngx_event.c代码中。

共有流程开始于解析 nginx 配置,这个进程集中在 ngx_init_cycle 函数中。 ngx_init_cycle 是 nginx 的1个核心函数,共有流程中与配置相干的几个进程都在这个函数中实现,其中包括解析 nginx 配置、初始化 CORE模块,接着是初始化文件句柄,初始化毛病日志,初始化同享内存,然后是监听端口。可以说共有流程 80% 都是现在 ngx_init_cycle 函数中,其中流程可以参考 3:深入理解Nginx的模块化 (结合源码详解)

ngx_cycle_t结构体解析

Nginx框架都是围绕着ngx_cycle_t结构体控制进程运行的,ngx_cycle_t结构体初始化就是在ngx_init_cycle函数中。

truct ngx_cycle_s { /* 保存着所有模块存储配置项的结构体指针, 它首先是1个数组,数组大小为ngx_max_module,正好与Nginx的module个数1样; 每一个数组成员又是1个指针,指向另外一个存储着指针的数组,因此会看到void **** 每一个进程中都有1个唯1的ngx_cycle_t核心结构体,它有1个成员conf_ctx保护着所有模块的配置结构体, 其类型是void ****conf_ctx。conf_ctx意义为首先指向1个成员皆为指针的数组,其中每一个成员指针又指向另外1个 成员皆为指针的数组,第2个子数组中的成员指针才会指向各模块生成的配置结构体。这正是为了事件模 块、http模块、mail模块而设计的,这有益于不同于NGX_CORE_MODULE类型的 特定模块解析配置项。但是,NGX_CORE_MODULE类型的核心模块解析配置项时,配置项1定是全局的, 不会从属于任何{}配置块的,它不需要上述这类双数组设计。解析标识为NGX_DIRECT_CONF类型的配 置项时,会把void****类型的conf_ctx强迫转换为void**,也就是说,此时,在conf_ctx指向的指针数组 中,每一个成员指针不再指向其他数组,直接指向核心模块生成的配置鲒构体。因此,NGX_DIRECT_CONF 仅由NGX_CORE_MODULE类型的核心模块使用,而且配置项只应当出现在全局配置中。 */ //初始化见ngx_init_cycle,所有为http{} server{} location{}分配的空间都由该指针指向新开辟的空间 //NGX_CORE_MODULE类型模块赋值在ngx_init_cycle //http{}ngx_http_module相干模块赋值地方在ngx_http_block */ /* 在核心结构体ngx_cycle_t的conf_ctx成员指向的指针数组中,第7个指针由ngx_http_module模块使用(ngx_http_module模块的index序号为6, 由于由0开始,所以它在ngx_modules数组中排行第7。在寄存全局配置结构体的conf_ctx数组中,第7个成员指向ngx_http_module模块),这个指针 设置为指向解析http{}块时生成的ngx_http_conf_ctx_t结构体,而ngx_http_conf_ctx_t的3个成员则分别指向新分配的3个指针数组。新的指针数组中 成员的意义由每一个HTTP模块的ctx_index序号指定(ctx_index在HTTP模块中表明它处于HTTP模块间的序号),例如,第6个HTTP模块的ctx_index是5 (ctx_index一样由0开始计数),那末在ngx_http_conf_ctx_t的3个数组中,第6个成员就指向第6个HTTP模块的create_main_conf、create_srv_conf、 create_loc_conf方法建立的结构体,固然,如果相应的回调方法没有实现,该指针就为NULL空指针。 */ /* 见ngx_init_cycle conf.ctx = cycle->conf_ctx; //这样下面的ngx_conf_param解析配置的时候,里面对conf.ctx赋值操作,实际上就是对cycle->conf_ctx[i] 可如何由ngx_cycle_t核心结构体中找到main级别的配置结构体呢?Nginx提供的ngx_http_cycle_get_module_main_conf宏可以实现这个功能 */ void ****conf_ctx; //有多少个模块就会有多少个指向这些模块的指针,见ngx_init_cycle ngx_max_module ngx_pool_t *pool; // 内存池 /* 日志模块中提供了生成基本ngx_log_t日志对象的功能,这里的log实际上是在还没有履行ngx_init_cycle方法前, 也就是还没有解析配置前,如果有信息需要输出到日志,就会暂时使用log对象,它会输出到屏幕。 在ngx_init_cycle方法履行后,将会根据nginx.conf配置文件中的配置项,构造出正确的日志文件,此时会对log重新赋值。 */ //ngx_init_cycle中赋值cycle->log = &cycle->new_log; ngx_log_t *log; //指向ngx_log_init中的ngx_log,如果配置error_log,指向这个配置后面的文件参数,见ngx_error_log。否则在ngx_log_open_default中设置 /* 由nginx.conf配置文件读取到日志文件路径后,将开始初始化error_log日志文件,由于log对象还在用于输出日志到屏幕, 这时候会用new_log对象暂时性地替换log日志,待初始化成功后,会用new_log的地址覆盖上面的log指针 */ // 如果没有配置error_log则在ngx_log_open_default设置为NGX_ERROR_LOG_PATH,如果通过error_log有配置过则通过ngx_log_set_log添加到该new_log->next链表连接起来 /* 全局中配置的error_log xxx存储在ngx_cycle_s->new_log,http{}、server{}、local{}配置的error_log保存在ngx_http_core_loc_conf_t->error_log, 见ngx_log_set_log,如果只配置全局error_log,不配置http{}、server{}、local{}则在ngx_http_core_merge_loc_conf conf->error_log = &cf->cycle->new_log; */ //ngx_log_insert插入,在ngx_log_error_core找到对应级别的日志配置进行输出,由于可以配置error_log不同级别的日志存储在不同的日志文件中 ngx_log_t new_log;//如果配置error_log,指向这个配置后面的文件参数,见ngx_error_log。否则在ngx_log_open_default中设置 ngx_uint_t log_use_stderr; /* unsigned log_use_stderr:1; */ /* 对poll,rtsig这样的事件模块,会以有效文件句柄数来预先建立这些ngx_connection t结构 体,以加速事件的搜集、分发。这时候files就会保存所有ngx_connection_t的指针组成的数组,files_n就是指 针的总数,而文件句柄的值用来访问files数组成员 */ ngx_connection_t **files; //sizeof(ngx_connection_t *) * cycle->files_n 见ngx_event_process_init ngx_get_connection /* 从图9⑴中可以看出,在ngx_cycle_t中的connections和free_connections达两个成员构成了1个连接池,其中connections指向全部连 接池数组的首部,而free_connections则指向第1个ngx_connection_t空闲连接。所有的空闲连接ngx_connection_t都以data成员(见9.3.1节)作 为next指针串连成1个单链表,如此,1旦有用户发起连接时就从free_connections指向的链表头获得1个空闲的连接,同时free_connections再指 向下1个空闲连接。而归还连接时只需把该连接插入到free_connections链表表头便可。 */ //见ngx_event_process_init, ngx_connection_t空间和它当中的读写ngx_event_t存储空间都在该函数1次性分配好 ngx_connection_t *free_connections;// 可用连接池,与free_connection_n配合使用 ngx_uint_t free_connection_n;// 可用连接池中连接的总数 //ngx_connection_s中的queue添加到该链表上 /* 通过读操作可以判断连接是不是正常,如果不正常的话,就会把该ngx_close_connection->ngx_free_connection释放出来,这样 如果之前free_connections上没有空余ngx_connection_t,c = ngx_cycle->free_connections;就能够获得到刚才释放出来的ngx_connection_t 见ngx_drain_connections */ ngx_queue_t reusable_connections_queue;/* 双向链表容器,元素类型是ngx_connection_t结构体,表示可重复使用连接队列 表示可以重用的连接 */ //ngx_http_optimize_servers->ngx_http_init_listening->ngx_http_add_listening->ngx_create_listening把解析到的listen配置项信息添加到cycle->listening中 //通过"listen"配置创建ngx_listening_t加入到该数组中 ngx_array_t listening;// 动态数组,每一个数组元素贮存着ngx_listening_t成员,表示监听端口及相干的参数 /* 动态数组容器,它保存着nginx所有要操作的目录。如果有目录不存在,就会试图创建,而创建目录失败就会致使nginx启动失败。 */ //通过解析配置文件获得到的路径添加到该数组,例如nginx.conf中的client_body_temp_path proxy_temp_path,参考ngx_conf_set_path_slot //这些配置可能设置重复的路径,因此不需要重复创建,通过ngx_add_path检测添加的路径是不是重复,不重复则添加到paths中 ngx_array_t paths;//数组成员 nginx_path_t , ngx_array_t config_dump; /* 单链表容器,元素类型是ngx_open_file_t 结构体,它表示nginx已打开的所有文件。事实上,nginx框架不会向open_files链表中添加文件。 而是由对此感兴趣的模块向其中添加文件路径名,nginx框架会在ngx_init_cycle 方法中打开这些文件 */ //该链表中所包括的文件的打开在ngx_init_cycle中打开 ngx_list_t open_files; //如nginx.conf配置文件中的access_log参数的文件就保存在该链表中,参考ngx_conf_open_file //创建ngx_shm_zone_t在ngx_init_cycle,在ngx_shared_memory_add也可能创建新的ngx_shm_zone_t,为每一个ngx_shm_zone_t真正分配同享内存空间在ngx_init_cycle ngx_list_t shared_memory;// 单链表容器,元素类型是ngx_shm_zone_t结构体,每一个元素表示1块同享内存 ngx_uint_t connection_n;// 当前进程中所有链接对象的总数,与connections成员配合使用 ngx_uint_t files_n; //每一个进程能够打开的最多文件数 赋值见ngx_event_process_init /* 从图9⑴中可以看出,在ngx_cycle_t中的connections和free_connections达两个成员构成了1个连接池,其中connections指向全部连接池数组的首部, 而free_connections则指向第1个ngx_connection_t空闲连接。所有的空闲连接ngx_connection_t都以data成员(见9.3.1节)作为next指针串连成1个 单链表,如此,1旦有用户发起连接时就从free_connections指向的链表头获得1个空闲的连接,同时free_connections再指向下1个空闲连 接。而归还连接时只需把该连接插入到free_connections链表表头便可。 在connections指向的连接池中,每一个连接所需要的读/写事件都以相同的数组序号对应着read_events、write_events读/写事件数组, 相同序号下这3个数组中的元素是配合使用的 */ ngx_connection_t *connections;// 指向当前进程中的所有连接对象,与connection_n配合使用 /* 事件是不需要创建的,由于Nginx在启动时已在ngx_cycle_t的read_events成员中预分配了所有的读事件,并在write_events成员中预分配了所有的写事件 在connections指向的连接池中,每一个连接所需要的读/写事件都以相同的数组序号对应着read_events、write_events读/写事件数组,相同序号下这 3个数组中的元素是配合使用的。图9⑴中还显示了事件池,Nginx认为每个连接1定最少需要1个读事件和1个写事件,有多少连接就分配多少个读、 写事件。怎样把连接池中的任1个连接与读事件、写事件对应起来呢?很简单。由于读事件、写事件、连接池是由3个大小相同的数组组成,所以根据数组 序号便可将每个连接、读事件、写事件对应起来,这个对应关系在ngx_event_core_module模块的初始化进程中就已决定了(参见9.5节)。这3个数组 的大小都是由cycle->connection_n决定。 */ ngx_event_t *read_events;// 指向当前进程中的所有读事件对象,connection_n同时表示所有读事件的总数 ngx_event_t *write_events;// 指向当前进程中的所有写事件对象,connection_n同时表示所有写事件的总数 /* 旧的ngx_cycle_t 对象用于援用上1个ngx_cycle_t 对象中的成员。例如ngx_init_cycle 方法,在启动早期, 需要建立1个临时的ngx_cycle_t对象保存1些变量, 再调用ngx_init_cycle 方法时就能够把旧的ngx_cycle_t 对象传进去, 而这时候old_cycle对象就会保存这个前期的ngx_cycle_t对象。 */ ngx_cycle_t *old_cycle; ngx_str_t conf_file;// 配置文件相对安装目录的路径名称 默许为安装路径下的NGX_CONF_PATH,见ngx_process_options ngx_str_t conf_param;// nginx 处理配置文件时需要特殊处理的在命令行携带的参数,1般是-g 选项携带的参数 ngx_str_t conf_prefix; // nginx配置文件所在目录的路径 ngx_prefix 见ngx_process_options ngx_str_t prefix; //nginx安装目录的路径 ngx_prefix 见ngx_process_options ngx_str_t lock_file;// 用于进程间同步的文件锁名称 ngx_str_t hostname; // 使用gethostname系统调用得到的主机名 在ngx_init_cycle中大写字母被转换为小写字母 };

配置解析

配置解析接口

ngx_init_cycle 提供的是配置解析接口。接口是1个切入点,通过少许代码提供1个完全功能的调用。配置解析接口分为两个阶段,1个是准备阶段,另外一个就是真正开始调用配置解析。准备阶段指甚么呢?主要是准备3点:

  • 准备内存:nginx会根据 以往的经验(old_cycle)预测这1次的配置 需要分配多少内存
if (old_cycle->shared_memory.part.nelts) { n = old_cycle->shared_memory.part.nelts; for (part = old_cycle->shared_memory.part.next; part; part = part->next) { n += part->nelts; } } else { n = 1; } if (ngx_list_init(&cycle->shared_memory, pool, n, sizeof(ngx_shm_zone_t)) != NGX_OK) { ngx_destroy_pool(pool); return NULL; }
  • 准备毛病日志:nginx启动可能出错,出现就要记录就要记录在日志文件中 。
log = old_cycle->log; pool = ngx_create_pool(NGX_CYCLE_POOL_SIZE, log); if (pool == NULL) { return NULL; } pool->log = log; cycle = ngx_pcalloc(pool, sizeof(ngx_cycle_t)); if (cycle == NULL) { ngx_destroy_pool(pool); return NULL; } cycle->pool = pool; cycle->log = log; cycle->old_cycle = old_cycle;
  • 准备数据结构,1个是ngx_cycle_t结构,1个是ngx_conf_t结构,ngx_cycle_t结构用于寄存所有CORE模块的 配置,而ngx_conf_t则是用于寄存解析配置的上下文的信息
    ngx_conf_t结构体
struct ngx_conf_s { //当前解析到的命令名 char *name; //当前命令的所有参数 ngx_array_t *args; //使用的cycle ngx_cycle_t *cycle; //所使用的内存池 ngx_pool_t *pool; //这个pool将会在配置解析终了后释放。 ngx_pool_t *temp_pool; //这个表示将要解析的配置文件 ngx_conf_file_t *conf_file; //配置log ngx_log_t *log; //主要为了提供模块的层次化(后续会详细介绍) void *ctx; //模块类型 ngx_uint_t module_type; //命令类型 ngx_uint_t cmd_type; //模块自定义的handler ngx_conf_handler_pt handler; //自定义handler的conf char *handler_conf; };
for (i = 0; ngx_modules[i]; i++) { if (ngx_modules[i]->type != NGX_CORE_MODULE) { continue; } module = ngx_modules[i]->ctx; if (module->create_conf) { rv = module->create_conf(cycle); if (rv == NULL) { ngx_destroy_pool(pool); return NULL; } cycle->conf_ctx[ngx_modules[i]->index] = rv; } } conf.ctx = cycle->conf_ctx; // cycle是ngx_cycle_t结构,conf就是ngx_conf_t结构 conf.cycle = cycle; conf.pool = pool; conf.log = log; conf.module_type = NGX_CORE_MODULE; //注意,1开始命令的类型就是MAIN,并且模块类型是core conf.cmd_type = NGX_MAIN_CONF;

准备好了这些内容,nginx开始调用配置解析模块,其代码以下:

if (ngx_conf_param(&conf) != NGX_CONF_OK) { environ = senv; ngx_destroy_cycle_pools(&conf); return NULL; } /*开始解析文件 然后来看ngx_conf_parse,这个函数第2个是将要解析的文件名,不过这里还有1个要注意的,那就是第2个参数可以为空的,如果为空,则说明将要解析的是block中的内容或param。*/ if (ngx_conf_parse(&conf, &cycle->conf_file) != NGX_CONF_OK) { environ = senv; ngx_destroy_cycle_pools(&conf); return NULL; }

第1个if解析nginx命令行参数’-g’加入的配置。第2个if解析nginx配置文件。好的设计就体现在接口极度简化,模块之间的耦合非常低。这里只使用区区10行完成了配置的解析

配置解析

配置解析模块在 ngx_conf_file.c 中实现。模块提供的接口函数主要是 ngx_conf_parse,另外模块提供单独的接口ngx_conf_param,用来解析命令行传递的配置,固然这个接口也是 对ngx_conf_parse的包装。

ngx_conf_parse 函数支持3种不同的解析环境:


  • parse_file:解析配置文件
  • parse_block:解析块配置。块配置1定是由“ {”和“ }”包裹起来的;
  • parse_param:解析命令行配置。命令行配置中不支持块指令。

这是1个递归的进程。nginx首先解析core模块的配置。core模块提供1些块指令,这些指令引入其他类型的模块,nginx遇到这些指令,就重新迭代解析进程,解析其他模块的配置。这些模块配置中又有1些块指令引入新的模块类型或指令类型,nginx就会再次迭代,解析这些新的配置类型。比如上图,nginx遇到“events”指令,就重新调用ngx_conf_parse()解析event模块配置,解析完以后ngx_conf_parse()返回,nginx继续解析core模块指令,直到遇到“http”指令。nginx再次调用ngx_conf_parse()解析http模块配置的http级指令,当遇到“server”指令时,nginx又1次调用ngx_conf_parse()解析http模块配置的server级指令。
parseconfig
// ngx_conf_parse()解析配置分成两个主要阶段,1个是词法分析,1个是指令解析。 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 */ ................................................ } else if (cf->conf_file->file.fd != NGX_INVALID_FILE) { //到这里说明接下来解析的是block中的内容 type = parse_block; } else { //参数 type = parse_param; } for ( ;; ) { rc = ngx_conf_read_token(cf); //此法分析,类似文件内容格式分析 /* * ngx_conf_read_token() may return * * NGX_ERROR there is error * NGX_OK the token terminated by ";" was found * NGX_CONF_BLOCK_START the token terminated by "{" was found * NGX_CONF_BLOCK_DONE the "}" was found * NGX_CONF_FILE_DONE the configuration file is done */ ..................................................... /* rc == NGX_OK || rc == NGX_CONF_BLOCK_START */ //如果有handler,则调用handler if (cf->handler) { //handler是自定义解析函数指针 /* * the custom handler, i.e., that is used in the http's * "types { ... }" directive */ 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; } //没有handler则调用默许解析函数 rc = ngx_conf_handler(cf, rc); if (rc == NGX_ERROR) { goto failed; } } failed: rc = NGX_ERROR; done: .................................... return NGX_CONF_OK; }

为何需要cf的两个主要cf->handler和cf->handler_conf这两个属性,其中handler是自定义解析函数指针,handler_conf是conf指针。

Nginx的配置文件是分块的,然后event, http都是1个大的core模块,然后core模块中包括了很多2级模块(epoll/kqeue/proxy..).也就是1级模块中必须包括1个上下文用来保存2级模块的配置。而在HTTP模块中又有1些特殊,那就是HTTP模块中每一个指令都可能会有3个作用域,那就是main/server/loc,所以在HTTP的上下文中,必须同时保存这3个上下文。

同时Nginx中的命令 有

#define NGX_CONF_ARGS_NUMBER 0x000000ff #define NGX_CONF_BLOCK 0x00000100 #define NGX_CONF_FLAG 0x00000200 #define NGX_CONF_ANY 0x00000400 #define NGX_CONF_1MORE 0x00000800 #define NGX_CONF_2MORE 0x00001000 #define NGX_DIRECT_CONF 0x00010000 #define NGX_MAIN_CONF 0x01000000 #define NGX_ANY_CONF 0x1F000000 #define NGX_HTTP_MODULE 0x50545448 /* "HTTP" */ #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

DIRECT_CONF顾名思义,就是说直接存取CONF,也就是说进入命令解析函数的同时,CONF已创建好了,只需要直接使用就好了(也就是会有create_conf回调)。而Main_conf就是说最顶层的conf,比如HTTP/EVENT/PID等等,可以看到都属属于CORE 模块。而NGX_HTTP_XXX就是所有HTTP模块的子模块.

ngx_conf_handler函数

//如果设置了type if (!(cmd->type & NGX_CONF_ANY)) { //首先判断参数个数是不是合法 if (cmd->type & NGX_CONF_FLAG) { if (cf->args->nelts != 2) { goto invalid; } } else if (cmd->type & NGX_CONF_1MORE) { if (cf->args->nelts < 2) { goto invalid; } ................................................. } /* set up the directive's configuration context */ conf = NULL; //最核心的地方, if (cmd->type & NGX_DIRECT_CONF) { //我们还记得最开始ctx是包括了所有core模块的conf(create_conf回调),因此这里取出对应的模块conf. conf = ((void **) cf->ctx)[ngx_modules[i]->index]; // NgX_DIRECT_CONF 才有create_conf回调 } else if (cmd->type & NGX_MAIN_CONF) { //如果不是DIRECT_CONF并且是MAIN,则说明我们需要在配置中创建自己模块的上下文(也就是需要进入2级模块) conf = &(((void **) cf->ctx)[ngx_modules[i]->index]); // MAIN_CONF1般没有create_conf回调 } else if (cf->ctx) { //否则进入2级模块处理(后续会详细介绍)。 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; }

上面代码中2级模块解析那部份先放1下,首先来看Nginx中带2级模块的1级模块如何解析命令的,来看HTTP模块(event模块基本1样)的解析代码。

/可以看到没有direct_conf,由于http包括有2级模块。 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 }; static char * ngx_http_block(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { char *rv; ngx_uint_t mi, m, s; ngx_conf_t pcf; ngx_http_module_t *module; ngx_http_conf_ctx_t *ctx; ngx_http_core_loc_conf_t *clcf; ngx_http_core_srv_conf_t **cscfp; ngx_http_core_main_conf_t *cmcf; /* the main http context */ ctx = ngx_pcalloc(cf->pool, sizeof(ngx_http_conf_ctx_t)); if (ctx == NULL) { return NGX_CONF_ERROR; } //最核心的地方,可以看到修改了传递进来的conf *(ngx_http_conf_ctx_t **) conf = ctx; /* count the number of the http modules and set up their indices */ ngx_http_max_module = 0; for (m = 0; ngx_modules[m]; m++) { if (ngx_modules[m]->type != NGX_HTTP_MODULE) { continue; } //然后保存了对应模块的索引. ngx_modules[m]->ctx_index = ngx_http_max_module++; } /* the http main_conf context, it is the same in the all http contexts */ //创建HTTP对应的conf,由于每一个级别(main/ser/loc)都会包括模块的conf. ctx->main_conf = ngx_pcalloc(cf->pool, sizeof(void *) * ngx_http_max_module); if (ctx->main_conf == NULL) { return NGX_CONF_ERROR; } /* * the http null srv_conf context, it is used to merge * the server{}s' srv_conf's */ ctx->srv_conf = ngx_pcalloc(cf->pool, sizeof(void *) * ngx_http_max_module); if (ctx->srv_conf == NULL) { return NGX_CONF_ERROR; } /* * the http null loc_conf context, it is used to merge * the server{}s' loc_conf's */ ctx->loc_conf = ngx_pcalloc(cf->pool, sizeof(void *) * ngx_http_max_module); if (ctx->loc_conf == NULL) { return NGX_CONF_ERROR; } /* * create the main_conf's, the null srv_conf's, and the null loc_conf's * of the all http modules */ .................................... //保存当前使用的cf,由于我们只是在解析HTTP时需要改变当前的cf, pcf = *cf; //保存当前模块的上下文 cf->ctx = ctx; .......................................... /* 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 */ ......................................... /* * http{}'s cf->ctx was needed while the configuration merging * and in postconfiguration process */ //回复cf *cf = pcf; ...................................... return NGX_CONF_OK; failed: *cf = pcf; return rv;

每一个级别都会保存对应的ctx(main/ser/loc),怎样说呢,就是在解析HTTP main中创建了3个ctx(main/srv/loc),而在HTTP srv block中将会创建2个ctx(main/srv/loc),这时候产生重复了,那就需要merge了。比如1个命令(srv_offset)在HTTP main中有1个,那末Nginx将会把它放入到HTTP main的ctx的srv ctx中,然后server block也有1个,那末Nginx会继续把它放到Server ctx的 srv_conf中,最后merge他们。

所以我们解析1下server模块

{ ngx_string("server"), NGX_HTTP_MAIN_CONF|NGX_CONF_BLOCK|NGX_CONF_MULTI|NGX_CONF_NOARGS, ngx_http_core_server, 0, 0, NULL }, static char * ngx_http_core_server(ngx_conf_t *cf, ngx_command_t *cmd, void *dummy) { char *rv; void *mconf; ngx_uint_t i; ngx_conf_t pcf; ngx_http_module_t *module; struct sockaddr_in *sin; ngx_http_conf_ctx_t *ctx, *http_ctx; ngx_http_listen_opt_t lsopt; ngx_http_core_srv_conf_t *cscf, **cscfp; ngx_http_core_main_conf_t *cmcf; ctx = ngx_pcalloc(cf->pool, sizeof(ngx_http_conf_ctx_t)); if (ctx == NULL) { return NGX_CONF_ERROR; } http_ctx = cf->ctx; //main conf不变 ctx->main_conf = http_ctx->main_conf; /* the server{}'s srv_conf */ //创建新的srv和loc conf. ctx->srv_conf = ngx_pcalloc(cf->pool, sizeof(void *) * ngx_http_max_module); if (ctx->srv_conf == NULL) { return NGX_CONF_ERROR; } /* the server{}'s loc_conf */ ctx->loc_conf = ngx_pcalloc(cf->pool, sizeof(void *) * ngx_http_max_module); if (ctx->loc_conf == NULL) { return NGX_CONF_ERROR; } ............................ /* the server configuration context */ cscf = ctx->srv_conf[ngx_http_core_module.ctx_index]; cscf->ctx = ctx; cmcf = ctx->main_conf[ngx_http_core_module.ctx_index]; //保存所有的servers,可以看到是保存在main中的。这模样最后在HTTP main中就能够取到这个srv conf. cscfp = ngx_array_push(&cmcf->servers); if (cscfp == NULL) { return NGX_CONF_ERROR; } *cscfp = cscf; /* parse inside server{} */ //解析,可以看到设置type为srv_conf. pcf = *cf; cf->ctx = ctx; cf->cmd_type = NGX_HTTP_SRV_CONF; rv = ngx_conf_parse(cf, NULL); // 调用ngx_conf_parse函数 //恢复cf. *cf = pcf; ........................ } return rv; }

现在来分析上述代码

struct ngx_command_s { ngx_str_t name; ngx_uint_t type; char *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf); //conf就是对应的上下文偏移.比如NGX_HTTP_LOC_CONF_OFFSET ngx_uint_t conf; ngx_uint_t offset; void *post; }; ............................ else if (cf->ctx) { //获得对应的1级模块的2级上下文(HTTP的 srv_offset) confp = *(void **) ((char *) cf->ctx + cmd->conf); if (confp) { //然后取出对应的模块conf. conf = confp[ngx_modules[i]->ctx_index]; } }

接下来 1些简单的命令如何使用和配置,主要 看这几个数据结构

typedef struct { void **main_conf; void **srv_conf; void **loc_conf; } ngx_http_conf_ctx_t; // 下面这些就是放到ngx_command_t的conf域,可以看到就是对应conf的偏移 #define NGX_HTTP_MAIN_CONF_OFFSET offsetof(ngx_http_conf_ctx_t, main_conf) #define NGX_HTTP_SRV_CONF_OFFSET offsetof(ngx_http_conf_ctx_t, srv_conf) #define NGX_HTTP_LOC_CONF_OFFSET offsetof(ngx_http_conf_ctx_t, loc_conf) // //下面就是如何来取模块的配置 #define ngx_http_get_module_main_conf(r, module) \ (r)->main_conf[module.ctx_index] #define ngx_http_get_module_srv_conf(r, module) (r)->srv_conf[module.ctx_index] #define ngx_http_get_module_loc_conf(r, module) (r)->loc_conf[module.ctx_index] #define ngx_http_conf_get_module_main_conf(cf, module) \ ((ngx_http_conf_ctx_t *) cf->ctx)->main_conf[module.ctx_index] #define ngx_http_conf_get_module_srv_conf(cf, module) \ ((ngx_http_conf_ctx_t *) cf->ctx)->srv_conf[module.ctx_index] #define ngx_http_conf_get_module_loc_conf(cf, module) \ ((ngx_http_conf_ctx_t *) cf->ctx)->loc_conf[module.ctx_index] #define ngx_http_cycle_get_module_main_conf(cycle, module) \ (cycle->conf_ctx[ngx_http_module.index] ? \ ((ngx_http_conf_ctx_t *) cycle->conf_ctx[ngx_http_module.index]) \ ->main_conf[module.ctx_index]: \ NULL)

总结

其实不是所有的模块像http有3个级别(main/srv/loc)比如stream和mail模块只有两个级别(main/srv)),但是整体解析流程都是 1致的,所以学习了1个模块,就能够很清楚其他模块,只是具体的handler不1样而已。接下来的博客将要介绍全部Nginx的全部框架 的流程

生活不易,码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠
程序员人生
------分隔线----------------------------
分享到:
------分隔线----------------------------
关闭
程序员人生