深入理解Nginx chap 4 配置， error日志和请求上下文

1. http配置项的使用场景

1. nginx 在每一个http 块， server 块， location 块下， 都会生成独立的数据结构用来存放配置项， 使用非常灵活

2. 怎样使用Http配置

1. 处理http 配置项的基本流程：

2.1 分配用于保存配置参数的数据结构

1. 这个数据结构可以根据自己的项目的需求进行定义， 书中为了解释 14 种预设配置项， 设计了如下数据结构：
   
typedef struct {
ngx_str_t my_str;
ngx_int_t my_num;
ngx_flag_t my_flag;
size_t my_size;
ngx_array_t * my_str_array;
ngx_array_t * my_keyval;
off_t my_off;
ngx_msec_t my_msec;
time_t my_sec;
ngx_bufs_t my_bufs;
ngx_uint_t my_enum_seq;
ngx_uint_t my_bitmask;
ngx_uint_t my_access;
ngx_path_t * my_path;
} ngx_http_mytest_conf_t;

2. 由于nginx 的框架设计， 在HTTP 框架解析nginx.conf 文件的时候， 只要遇到 http{}, server{}, location{} 配置块， 就会立即分配一个结构体用来存储配置参数， 进程中可能会有多个这样的配置实例存在， 因而， 需要定义上述这个结构体， 便于参数管理
3. 通过ngx_http_module_t 中所定义的回调方法， 我们可以操作 这个结构体
   
   • 当框架遇到 http{} 的时候， 调用HTTP 模块可能实现的create_main_conf, create_srv_conf, create_loc_conf 生成存储main级别配置参数的结构体
   • 同理，遇到 server{} 的时候， 调用 create_srv_conf, create_loc_conf 生成存储 srv 级别配置参数的结构体
   • 遇到 location{}时， 调用 create_loc_conf 生成 loc 级别配置参数的存储结构
4. 一般普通的HTTP 模块往往只实现create_loc_conf回调方法， 因为， 他们一般只关心匹配某种URL的请求
   

2.2 设定配置项的解析方式

1. 在nginx中，配置项主要通过ngx_command_t结构进行解析。
   

2. 关于type 的设置具体可以参考官方文档： https://www.nginx.com/resources/wiki/extending/api/configuration/?highlight=ngx_command_t# 或者 书本的 P116 页

3. set 回调方法， 是用来处理nginx.conf 中的配置项的， 这部分可以使用14种预设的方法

4. conf， 用来指示配置项所处内存的相对偏移位置。

   • 因为， HTTP 模块中可能定义了 3 个结构体， 用来存储main， srv， loc 级别的配置项 （对应 create_main_conf, create_srv_conf, create_loc_conf）, 这里使用 conf 用来指明， 将解析出来的配置项的值存放到哪个结构体中
   • 因此， 对conf 的设置是与ngx_http_module_t 实现的回调方法相关的。
   • 一般， 功能较为简单的HTTP 模块都只实现了create_loc_conf 的回调方法， 对于 http{}, server{} 块内出现的同名配置项， 都是并入到某个location{} 内create_loc_conf 方法所产生的结构体中的。 如果希望， 在HTTP 模块中的代码保存到不同的变量中， 就需要实现create_mian_conf, create_srv_conf

5. offset, 用来表明当前配置项在整个存储配置项的结构体中的偏移位置， 可以借助 offsetof 宏实现这个计算的过程

6. post， 配置项处理后的后续方法。

2.3 使用14种预设方法解析配置项

（略， 基本用法非常简单， 看一下书本上的例子就好了=_=！！）

2.4 自定义配置项处理方法

1. 首先自定义存储结构体
2. 编写set 方法

 static char * ngx_conf_set_myconfig(ngx_conf_t * cf, ngx_command_t * cmd, void * conf);

其中， conf 指代的就是我们自定义的存储结构体
然后通过， cf->args->elfs 获取参数队列

static char* ngx_conf_set_myconfig(ngx_conf_t *cf, ngx_command_t *cmd, void *conf){    //注意，参数conf就是http框架传给我们的，在ngx_http_mytest_create_loc_conf//回调方法中分配的结构体ngx_http_mytest_conf_t    ngx_http_mytest_conf_t  *mycf = conf;    // cf->args是1个ngx_array_t队列，它的成员都是ngx_str_t结构。//我们用value指向ngx_array_t的elts内容，其中value[1]就是第1//个参数，同理value[2]是第2个参数    ngx_str_t* value = cf->args->elts;    //ngx_array_t的nelts表示参数的个数    if (cf->args->nelts > 1)    {        //直接赋值即可， ngx_str_t结构只是指针的传递        mycf->my_config_str = value[1];    }    if (cf->args->nelts > 2)    {        //将字符串形式的第2个参数转为整型        mycf->my_config_num = ngx_atoi(value[2].data, value[2].len);        //如果字符串转化整型失败，将报"invalid number"错误，//nginx启动失败        if (mycf->my_config_num == NGX_ERROR)        {            return "invalid number";        }    }    //返回成功    return NGX_CONF_OK;}

2.5 合并配置项

1. 如果http{}, server{}, location{} 下面都出现了同名的配置项， 根据 merge_loc_conf（merge_srv_conf）进行合并， 如果他们被设置为 null， * 忽略上一级中的同名配置项 *

char * (*merge_loc_conf)(ngx_conf_t * cf, void * prev, void * conf)

其中， cf 表示全局配置的设置， prev 表示父级配置结构体， void * conf 为当前配置结构体

3. HTTP 配置模型

1. 当nginx 检测到 http{} 关键配置的时候， HTTP 配置模型启动， 首先建立一个ngx_http_conf_ctx_t 的上下文结构

typedef struct {    void ** main_conf;    void ** srv_conf;    void ** loc_conf; // 指针数组， 数组的每个元素指向相应 HTTP 模块 的 create_loc_conf 方法产生的结构体的地址} ngx_http_conf_ctx_t;

这时候， HTTP 框架为所有的HTTP 模块建立 3个数组， 分别存放 create_main_conf, create_srv_conf, create_loc_conf 方法所返回的地址指针

ie， ngx_http_conf_ctx_t 结构保存了所有HTTP 模块的配置数据结构的入口。

3.1 解析HTTP 配置的流程

ps： 对于每一个server 块， location 块， http 块 都会建立一个相应的 ngx_http_conf_ctx_t 的结构

3.2 HTTP 配置模型的内存布局

通过上面的图， 我们可以知道， nginx.conf中 http{}, server{}, location{} 的总个数 与 调用create_loc_conf方法的次数相同； 而 http{}, server{} 的总个数 与 调用create_srv_conf 方法的次数相同。
而这些方法每被调用一次就生成一个结构体。 （便于解决同名配置项的合并问题）。

3.3 如何合并配置项

调用 merge_srv_conf, 和 merge_loc_conf 进行合并

3.4 预设配置项处理方法的工作原理

1. 通过 使用 cf->args->elts 直接获取配置参数
2. nginx 配置项解析模块在调用 ngx_command_t 结构体的set 方法的时候， 会同时把offset 编译传递进来。由此， 可以正确识别需要解析的配置项的存储位置

4. error 日志的用法

1. 使用 ngx_log_error / ngx_log_debug 进行日志记录

5. 请求上下文

5.1 上下文与全异步Web服务器的关系

1. 在一个请求的处理过程中， 用类似struct 这样的结构体把一些关键的信息保存起来的结构体， 称为上下文
2. 上下文 是针对一个请求 一个模块而言的， 因而他是低耦合的
3. nginx 类似餐厅吃饭， 多个客户， 1 个waiter， 客户记录自己执行的流程， 处理完一个步骤之后， 呼叫waiter 进行下一步操作， 而这个记录的状态， 就可以理解成上下文了。

5.2 如何使用HTTP 上下文

1. 核心就是两个宏：
   
   • ngx_http_get_module_ctx
   • ngx_http_set_ctx
2. 一般调用方式：
   

5.3 HTTP 框架如何维护上下文结构

1. 类似于ngx_http_conf_ctx_t 的 3 个数组成员， HTTP 框架 使用 ctx 数组 保存所有 HTTP 模块上下文结构体的指针

struct ngx_http_request_s {    ...    void ** ctx;    ...}

1. ngx_http_get_module_ctx 和 ngx_http_set_ctx 本质， 只是去获取或者设置 ctx 数组中相应的 HTTP 模块的指针而已。