nginx http模块配置合并

怼烎@ 2023-07-08 12:27 13阅读 0赞

在配置nginx.conf文件的时候，我们很容易发现，有部分配置项是既可以配置在http块，也可以配置在server块，还可以配置在location块中。但是并不是所有的配置项都可以在任意位置进行配置的，根据配置项所起到的作用，nginx对各个配置块所能使用的位置进行了定义。既然一个配置项可以配置在多个配置块中，那么这里就涉及到一个问题就是，在处理请求的时候是以哪一个配置项为准。本文主要讲解nginx是如何实现配置项的合并的。

在前面的文章中，我们讲解了nginx http模块的基本存储结构，在阅读本文之前强烈建议读者朋友先阅读这篇文章。如下是nginx http模块的存储结构示意图：

![format_png][]

这里我们不再赘述nginx是如何解析各个配置项，从而形成这样的一个存储结构的。nginx对配置项的合并主要是通过`ngx_http_merge_servers()`方法进行的，如下是该方法的源码：

/**
     * @param cf 整个nginx运行的ngx_conf_t对象
     * @param cmcf 核心模块对应的配置对象
     * @param module 外层遍历时，当前遍历的模块
     * @param ctx_index 外层遍历时，当前遍历的模块的配置对应的存储位置
     */
    static char * ngx_http_merge_servers(ngx_conf_t *cf, ngx_http_core_main_conf_t *cmcf,
                           ngx_http_module_t *module, ngx_uint_t ctx_index) {
      char *rv;
      ngx_uint_t s;
      ngx_http_conf_ctx_t *ctx, saved;
      ngx_http_core_loc_conf_t *clcf;
      ngx_http_core_srv_conf_t **cscfp;
    
      // 这里获取所有server配置块对应的ngx_http_core_srv_conf_t结构体，每个结构体都对应了配置文件中
      // 一个server块的配置
      cscfp = cmcf->servers.elts;
      // 这里的cf->ctx就是解析http配置块得到的ngx_http_conf_ctx_t结构体，需要注意的是，其中只有main_conf
      // 对应的数组数据有意义，因为http块的数据只存储在main_conf中
      ctx = (ngx_http_conf_ctx_t *) cf->ctx;
      // 这里需要注意的是，在执行saved=*ctx;之后，会将当前*ctx的结构体对象完全复制而得到一个新的，从而存储到
      // saved中，也就是说ctx和&saved的值是不一样的。在下面的for循环中会执行
      // ctx->srv_conf = cscfp[s]->ctx->srv_conf;语句，这里其实改变
      // 的是ctx指针所指向的结构体对象的srv_conf属性的值，而并没有影响到saved->srv_conf属性值，
      // 因为saved和*ctx是两个各个属性值虽然相同，但是本身并不同的结构体对象。
      saved = *ctx;
      rv = NGX_CONF_OK;
    
      for (s = 0; s < cmcf->servers.nelts; s++) {
    
        /* merge the server{}s' srv_conf's */
    
        ctx->srv_conf = cscfp[s]->ctx->srv_conf;
    
        if (module->merge_srv_conf) {
          // 这里主要是进行配置的合并，saved.srv_conf[ctx_index]指向的是http块中解析出的SRV类型的配置，
          // cscfp[s]->ctx->srv_conf[ctx_index]解析的则是当前server块中的配置，合并的一般规则是通过对应
          // 模块实现的merge_srv_conf()来进行的，具体将会使用http块中的配置，还是使用server块中的配置，
          // 或者说合并两者，则是由具体的实现来决定的。这里合并的效果本质上就是对
          // cscfp[s]->ctx->srv_conf[ctx_index]中的属性赋值，如果该值不存在，则将http块对应的值写到
          // 该属性中
          rv = module->merge_srv_conf(cf, saved.srv_conf[ctx_index], 
                                      cscfp[s]->ctx->srv_conf[ctx_index]);
          if (rv != NGX_CONF_OK) {
            goto failed;
          }
        }
    
        if (module->merge_loc_conf) {
          ctx->loc_conf = cscfp[s]->ctx->loc_conf;
    
          // 需要注意的是，这里合并的主要是http块和当前server块中对应的LOC类型的配置数据，此时并没有开始
          // 合并server块下的各个location配置
          rv = module->merge_loc_conf(cf, saved.loc_conf[ctx_index], 
                                      cscfp[s]->ctx->loc_conf[ctx_index]);
          if (rv != NGX_CONF_OK) {
            goto failed;
          }
    
          clcf = cscfp[s]->ctx->loc_conf[ngx_http_core_module.ctx_index];
    
          // 这里clcf->locations存储了当前server块下的所有location块的配置，而cscfp[s]->ctx->loc_conf
          // 则指向的是将http块和server块合并之后的配置数据，从这里就可以看出，当前方法的结果就是合并了
          // http块、server块和location块的配置
          rv = ngx_http_merge_locations(cf, clcf->locations, cscfp[s]->ctx->loc_conf, 
                                        module, ctx_index);
          if (rv != NGX_CONF_OK) {
            goto failed;
          }
        }
      }
    
      failed:
    
      *ctx = saved;
    
      return rv;
    }

这里`ngx_http_merge_servers()`方法主要完成了如下几个工作：

*  调用当前模块的`merge_srv_conf()`方法将http配置块和server配置块中`NGX_HTTP_SRV_CONF_OFFSET`类型的配置项进行合并，也即将http配置块结构体中的`srv_conf`数组与server配置块结构体中的`srv_conf`数组进行合并，如此就完成了`NGX_HTTP_SRV_CONF_OFFSET`类型配置项的合并；
 *  调用当前模块的`merge_loc_conf()`方法将http配置块和server配置块中`NGX_HTTP_LOC_CONF_OFFSET`类型的配置项进行合并，也即将http配置块结构体中的`loc_conf`数组与server配置块结构体中的`loc_conf`数组进行合并。不过不同于`NGX_HTTP_SRV_CONF_OFFSET`类型的配置项，`NGX_HTTP_LOC_CONF_OFFSET`类型的配置项是还可以配置在location配置块中的，因而还需要将合并的结果与location配置块中的配置项进行合并；
 *  调用`ngx_http_merge_locations()`方法将前一步http配置块与server配置块合并的`NGX_HTTP_LOC_CONF_OFFSET`类型的配置项继续与location配置块中的配置项进行合并，从而得到最终合并结果。不过这里需要注意的一点是，location配置块中还可以继续配置配置子location配置块，如此不断往复下去，而这里的`ngx_http_merge_locations()`方法则可以用于递归调用，以便于进行子location的合并。

这里我们继续看`ngx_http_merge_locations()`方法是如何合并子location的：

/**
     * 合并location块的配置
     *
     * @param cf 指向当前http块的配置结构体ngx_http_conf_ctx_t
     * @param locations 当前server块下所有的location块的配置
     * @param loc_conf
     * @param module
     * @param ctx_index
     * @return
     */
    static char * ngx_http_merge_locations(ngx_conf_t *cf, ngx_queue_t *locations, void **loc_conf,
        ngx_http_module_t *module, ngx_uint_t ctx_index) {
      char *rv;
      ngx_queue_t *q;
      ngx_http_conf_ctx_t *ctx, saved;
      ngx_http_core_loc_conf_t *clcf;
      ngx_http_location_queue_t *lq;
    
      if (locations == NULL) {
        return NGX_CONF_OK;
      }
    
      ctx = (ngx_http_conf_ctx_t *) cf->ctx;
      saved = *ctx;
    
      for (q = ngx_queue_head(locations);
           q != ngx_queue_sentinel(locations);
           q = ngx_queue_next(q)) {
        lq = (ngx_http_location_queue_t *) q;
    
        clcf = lq->exact ? lq->exact : lq->inclusive;
        ctx->loc_conf = clcf->loc_conf;
    
        // 合并location块的配置，这里的loc_conf[ctx_index]存储的是http块与server块配置合并的数据，
        // 而clcf->loc_conf则是当前server块下的某个location块的数据，这里其实就是将当前loc_conf中的
        // 数据合并到clcf->loc_conf中
        rv = module->merge_loc_conf(cf, loc_conf[ctx_index], clcf->loc_conf[ctx_index]);
        if (rv != NGX_CONF_OK) {
          return rv;
        }
    
        // 由于location块中还可以配置子location块，因而这里会递归的进行合并
        rv = ngx_http_merge_locations(cf, clcf->locations, clcf->loc_conf, module, ctx_index);
        if (rv != NGX_CONF_OK) {
          return rv;
        }
      }
    
      *ctx = saved;
    
      return NGX_CONF_OK;
    }

这里对location以及子location的合并过程其实比较简单，就是依次弹出当前配置块（server或者父location）下的各个子location，然后调用当前模块的`merge_loc_conf()`方法将当前配置块的配置与弹出的子location进行合并。在合并完成后，继续对该子location进行递归的合并，也即将该子location与其子location进行合并。如此不断往复下去，直到所有的location都被合并完成。

nginx的配置项合并是一个比较重要的功能，比如某个既可以在http块中也可以在server块中配置的配置项，如果nginx.conf中仅仅只是配置了http块中的配置，那么所有的server块的配置就都可以继承http块的配置，但如果其中某个server自身也进行了该配置项的配置，那么进行合并的时候该配置项就可以直接使用其自身的配置，而不需要继承http配置块的配置，如此就可以实现非常灵活的功能。

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9vc2NpbWcub3NjaGluYS5uZXQvb3NjbmV0L3VwLWQxNDgwOWNkZWQ4YmRlN2UyOGY3OWRjNGJjNDZlMmE5MjhhLnBuZw?x-oss-process=image/format,png