nginx http模块配置合并

简介: 在配置nginx.conf文件的时候,我们很容易发现,有部分配置项是既可以配置在http块,也可以配置在server块,还可以配置在location块中。但是并不是所有的配置项都可以在任意位置进行配置的,根据配置项所起到的作用,nginx对各个配置块所能使用的位置进行了定义。

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

在前面的文章中,我们讲解了nginx http模块的基本存储结构,在阅读本文之前强烈建议读者朋友先阅读这篇文章。如下是nginx http模块的存储结构示意图:
N1
这里我们不再赘述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()方法主要完成了如下几个工作:

1、调用当前模块的merge_srv_conf()方法将http配置块和server配置块中NGX_HTTP_SRV_CONF_OFFSET类型的配置项进行合并,也即将http配置块结构体中的srv_conf数组与server配置块结构体中的srv_conf数组进行合并,如此就完成了NGX_HTTP_SRV_CONF_OFFSET类型配置项的合并;

2、调用当前模块的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配置块中的配置项进行合并;

3、调用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配置块的配置,如此就可以实现非常灵活的功能。

文章来源:https://my.oschina.net/zhangxufeng/blog/3173782

相关内容推荐:https://www.roncoo.com/view/1211250285484212225

相关文章
|
9天前
|
人工智能 Ubuntu 前端开发
Dify部署全栈指南:AI从Ubuntu配置到HTTPS自动化的10倍秘籍
本文档介绍如何部署Dify后端服务及前端界面,涵盖系统环境要求、依赖安装、代码拉取、环境变量配置、服务启动、数据库管理及常见问题解决方案,适用于开发与生产环境部署。
167 1
|
24天前
|
编解码 应用服务中间件 Linux
centos配置nginx-rtmp实现ffmpeg转码rtsp为rtmp视频流
centos配置nginx-rtmp实现ffmpeg转码rtsp为rtmp视频流
100 1
|
4月前
|
应用服务中间件 Linux 网络安全
Centos 8.0中Nginx配置文件和https正书添加配置
这是一份Nginx配置文件,包含HTTP与HTTPS服务设置。主要功能如下:1) 将HTTP(80端口)请求重定向至HTTPS(443端口),增强安全性;2) 配置SSL证书,支持TLSv1.1至TLSv1.3协议;3) 使用uWSGI与后端应用通信(如Django);4) 静态文件托管路径设为`/root/code/static/`;5) 定制错误页面(404、50x)。适用于Web应用部署场景。
614 87
|
5天前
|
Ubuntu 安全 应用服务中间件
详细指南:配置Nginx服务器在Ubuntu平台上
以上步骤涵盖了基本流程:从软件包管理器获取 Ngnix, 设置系统服务, 调整UFW规则, 创建并激活服务器块(也称作虚拟主机), 并进行了初步优化与加固措施。这些操作都是建立在命令行界面上,并假设用户具有必要权限(通常是root用户)来执行这些命令。每个操作都有其特定原因:例如,设置开机启动确保了即使重启后也能自动运行 Ngnix;而编辑server block则定义了如何处理进入特定域名请求等等。
93 18
|
7天前
|
Ubuntu 安全 应用服务中间件
详细指南:配置Nginx服务器在Ubuntu平台上
以上步骤涵盖了基本流程:从软件包管理器获取 Ngnix, 设置系统服务, 调整UFW规则, 创建并激活服务器块(也称作虚拟主机), 并进行了初步优化与加固措施。这些操作都是建立在命令行界面上,并假设用户具有必要权限(通常是root用户)来执行这些命令。每个操作都有其特定原因:例如,设置开机启动确保了即使重启后也能自动运行 Ngnix;而编辑server block则定义了如何处理进入特定域名请求等等。
74 17
|
4月前
|
负载均衡 应用服务中间件 nginx
Nginx配置与命令
Nginx 是一款高性能的 HTTP 和反向代理服务器,其配置文件灵活且功能强大。本文介绍了 Nginx 配置的基础结构和常用指令,包括全局块、Events 块、HTTP 块及 Server 块的配置方法,以及静态资源服务、反向代理、负载均衡、HTTPS 和 URL 重写等功能实现。此外,还提供了常用的 Nginx 命令操作,如启动、停止、重载配置和日志管理等,帮助用户高效管理和优化服务器性能。
|
1月前
|
数据建模 应用服务中间件 PHP
配置nginx容器和php容器协同工作成功,使用ip加端口的方式进行通信
本示例演示如何通过Docker挂载同一宿主目录至Nginx与PHP容器,实现PHP项目运行环境配置。需注意PHP容器中监听地址修改为0.0.0.0:9000,并调整Nginx配置中fastcgi_pass指向正确的IP与端口。同时确保Nginx容器中/var/www/html权限正确,以避免访问问题。
配置nginx容器和php容器协同工作成功,使用ip加端口的方式进行通信
|
2月前
|
应用服务中间件 网络安全 nginx
配置Nginx以支持Websocket连接的方法。
通过上述配置,Nginx将能够理解WebSocket协议的特殊要求,代理Websocket流量到合适的后端服务器。注意,Websocket并不是HTTP,尽管它最初是通过HTTP请求启动的连接升级,因此保证Nginx了解并能够妥善处理这种升级流程是关键。
533 10
|
1月前
|
Ubuntu 应用服务中间件 Linux
在Ubuntu上配置Nginx实现开机自启功能
至此,Nginx应该已经被正确地设置为开机自启。在Ubuntu中利用 `systemd`对服务进行管理是一种高效的方式,为系统管理员提供了强大的服务管理能力,包括但不限于启动、停止、重启服务,以及配置服务的开机自启动。通过这些简洁的命令,即使是对Linux不太熟悉的用户也能轻松地进行配置。
101 0
|
3月前
|
安全 应用服务中间件 Linux
Debian操作系统如何安装Nginx并开启HTTP2
本指南介绍了在Linux系统中通过源码编译安装Nginx的完整流程。首先更新软件包列表并安装必要的编译依赖,接着下载指定版本的Nginx源码包(如1.24.0),检查文件完整性后解压。随后通过配置脚本指定安装路径与模块(如HTTP SSL模块),执行编译和安装命令。最后创建软链接以便全局调用,并提供启动、停止及重载Nginx的命令,同时提醒注意安全组设置以确保正常访问。