歡迎轉載，轉載請註明出處 http://blog.csdn.net/yankai0219/article/details/8286579
| 本文主要內容 0.序 一、NGINX設定檔的格式 1.構成 2.設定檔的格式決定了某些函數會被遞迴調用。原因： 3.配置項詳細說明： 二、NGINX中結構體 與函數 1.存放指令取值的結構體 2. 存放指令的結構體 3. 與設定檔有關的函數 三、設定檔解析的流程 1.總流程 2.詳細過程 NGX_CORE_MODULE、NGX_EVENT_MODULE、NGX_HTTP_MODULE |
0.序 本文主要講述了設定檔的格式以及NGINX如何獲得設定檔的內容。閱讀了很多大牛的文章，也閱讀了代碼中關於CORE HTTP EVENT模組對於設定檔的處理，現在將內容總結如下:
一、NGINX設定檔的格式 1.構成 Nginx設定檔是由多個配置項構成，每個配置項都有一個項目名和對應的項目值。配置項又分為簡單配置項和複雜配置項。 項目名又被稱為指令（Directive），而項目值可能簡單的字串（以分號結尾），也可能是由簡單字串和多個配置項組合而成配置塊的複雜結構（以大括弧}結尾），因此我們可以將配置項歸納為兩種：簡單配置項和複雜配置項。 如下圖所示：
2.設定檔的格式決定了某些函數會被遞迴調用。原因： 從上面這條規範可以看到這裡包含有遞迴的思想，因此在後面的配置解析代碼裡可以看到某些函數被遞迴調用，其原因也就在這裡。 對於複雜配置項來說，其值是由多個簡單/複雜配置項組成，因此nginx不做過細的處理，一般就是申請內容空間、切換解析狀態，然後遞迴調用解析函數；
真正將使用者配置資訊轉換為nginx內變數的值，還是那些簡單配置項所對應的處理函數。
3.配置項詳細說明： 不管是簡單配置項還是複雜配置項，他們的項目名和項目值都是由標記（token）組成。設定項目名就是一個token，而設定項目值可以使一個、兩個、多個token組成。所謂標記（token）：這裡指一個設定檔字串內容中被空格、引號、括弧，比如’{‘、分行符號等分割開來的字元子串。 舉例說明： 比如簡單配置項： daemon off; 其項目名daemon為一個token，項目值off也是一個token。而簡單配置項： error_page 404 /404.html; 其項目值就包含有兩個token，分別為404和/404.html。 對於複雜配置項： location /www { index index.html index.htm index.php; } 其項目名location為一個token，項目值是一個token（/www）和多條簡單配置項組成的複合結構。 而如果我在設定檔內加入如下配置內容：
lenky on;
啟動nginx，直接返回錯誤，這是因為對於lenky指令，nginx沒有對應的代碼去解析它：
[emerg]: unknown directive “lenky” in /usr/local/nginx/conf/nginx.conf:2
二、NGINX中結構體 與函數 對於Nginx而言，我們需要根據某些規則自己書寫設定檔nginx.conf。那麼nginx.conf中的指令及指令的取值在NGINX程式中是以何種形式呈現的呢。問題舉例：即daemon on; 在NGINX程式中是如何體現的呢。 1.存放指令取值的結構體 在NGINX中有一類自訂的配置結構體，其格式具有統一的規則。 對於
HTTP模組中：
ngx_http_<module name>_(main|srv|loc)_conf_t 對於
EVENT模組：ngx_event_conf_t 對於
CORE模組：ngx_core_conf_t。 這類自訂的配置結構體的作用： 存放指令的取值。即NGINX在這些自訂的配置結構體中存放nginx.conf中的指令的取值。 舉例：ngx_core_conf_t 的成員變數 ngx_flag_t daemon就是存放指令daemon的取值。
2. 存放指令的結構體 在Nginx中有一類統一的指令結構體ngx_commant_t。 在ngx_commant_t ngx_core_commands[]={ {指令A}, {指令B}, ngx_null_command } 關於該指令結構體ngx_commant_t的解釋
3. 與設定檔有關的函數 ngx_conf_parse和 ngx_conf_handler 可參閱 http://lenky.info/2011/09/09/nginx%E9%85%8D%E7%BD%AE%E4%BF%A1%E6%81%AF%E7%9A%84%E8%A7%A3%E6%9E%90%E6%B5%81%E7%A8%8B-3/
三、設定檔解析的流程 1.總流程： 不管對於CORE MODULE or HTTP or EVENT MODULE，其主要流程如下所示： 1、某個void **ctx數組存放通過ngx_modules[i]->ctx->create_conf獲得的ngx_xxx_conf_t結構體 2.構造ngx_conf_t conf 。填寫裡面幾個成員變數。 void *ctx即為1.中ctx數組，即eg:conf.ctx = ctx ngx_uint_t module_type 填寫為CORE or HTTP or EVENT。eg:conf.module_type = NGX_CORE_MODULE ngx_uint_t cmd_type 填寫為MAIN or SERVER or LOCATION.eg:conf.cmd_type = NGX_MAIN_CONF 3.調用ngx_conf_parse（ngx_conf_t conf ，xxx）函數，進行解析。 在ngx_conf_handler函數中，void * conf通過ctx數組，獲得某個特定token所處於的模組的ngx_xxx_conf_t結構體，即conf指向了某個特定token所處的結構體的位置。 再指向cmd->set函數，從而可以將token的取值存入conf指向的某個特定token所處的結構體。從而完成token取值從設定檔到程式特定變數的過程。 整體過程如上所述，詳細過程還請依次閱讀對於NGX_CORE_MODULE、NGX_EVENT_MODULE、NGX_HTTP_MODULE的分析。
2.詳細過程
對於NGX_CORE_MODULE
在ngx_init_cycle函數中
在ngx_conf_parse函數調用ngx_conf_handler(ngx_conf_t *cf, ngx_int_t last)函數
對於daemon而言
對於NGX_EVENT_MODULE而言 在ngx_events_block中
對於NGX_HTTP_MODULE
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 */ /*1） typedef struct { void **main_conf; void **srv_conf; void **loc_conf; } ngx_http_conf_ctx_t; 這兒的main_conf srv_conf loc_conf分別作為 http的main server location配置項的的ngx_xxx_conf_t的存放數組。 * */ ctx = ngx_pcalloc(cf-> pool , sizeof ( ngx_http_conf_ctx_t )); if (ctx == NULL) { return NGX_CONF_ERROR; }
*( 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 */ |
