nginx 學習筆記5

基本上作為第三方開發者最可能開發的就是三種型別的模組，即handler，filter和load-balancer。handler模組就是接受來自客戶端的請求並產生輸出的模組。有些地方說upstream模組實際上也是一種handler模組，只不過它產生的內容來自於從後端伺服器獲取的，而非在本機產生的。

如果有多個handler模組都關聯了同乙個location，那麼實際上只有乙個handler模組真正會起作用。

handler模組處理的結果通常有三種情況: 處理成功，處理失敗（處理的時候發生了錯誤）或者是拒絕去處理。在拒絕處理的情況下，這個location的處理就會由預設的handler模組來進行處理。

nginx的配置資訊分成了幾個作用域(scope,有時也稱作上下文)，這就是main, server, 以及location。

例：

typedef struct

乙個模組的配置指令是定義在乙個靜態陣列中的。以hello module為例：

ngx_command_t的定義，位於src/core/ngx_conf_file.h中

struct
ngx_command_s ;

name:

配置指令的名稱。

type:

該配置的型別，其實更準確一點說，是該配置指令屬性的集合。nginx提供了很多預定義的屬性值（一些巨集定義），通過邏輯或運算子可組合在一起，形成對這個配置指令的詳細的說明。下面列出可在這裡使用的預定義屬性值及說明。

set:

這是乙個函式指標，當nginx在解析配置的時候，如果遇到這個配置指令，將會把讀取到的值傳遞給這個函式進行分解處理。因為具體每個配置指令的值如何處理，只有定義這個配置指令的人是最清楚的。來看一下這個函式指標要求的函式原型。

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

該函式的返回值，處理成功時，返回ngx_ok，否則返回ngx_conf_error或者是乙個自定義的錯誤資訊的字串。

再看一下這個函式被呼叫的時候，傳入的三個引數。

為了更加方便的實現對配置指令引數的讀取，nginx已經預設提供了對一些標準型別的引數進行讀取的函式，可以直接賦值給set欄位使用。下面來看一下這些已經實現的set型別函式。

conf:

該字段被ngx_http_module型別模組所用 (我們編寫的基本上都是ngx_http_moudle，只有一些nginx核心模組是非ngx_http_module)，該欄位指定當前配置項儲存的記憶體位置。實際上是使用哪個記憶體池的問題。因為http模組對所有http模組所要儲存的配置資訊，劃分了main, server和location三個地方進行儲存，每個地方都有乙個記憶體池用來分配儲存這些資訊的記憶體。這裡可能的值為 ngx_http_main_conf_offset、ngx_http_srv_conf_offset或ngx_http_loc_conf_offset。當然也可以直接置為0，就是ngx_http_main_conf_offset。

offset:

指定該配置項值的精確存放位置，一般指定為某乙個結構體變數的字段偏移。因為對於配置資訊的儲存，一般我們都是定義個結構體來儲存的。那麼比如我們定義了乙個結構體a，該項配置的值需要儲存到該結構體的b欄位。那麼在這裡就可以填寫為offsetof(a, b)。對於有些配置項，它的值不需要儲存或者是需要儲存到更為複雜的結構中時，這裡可以設定為0。

post:

該欄位儲存乙個指標。可以指向任何乙個在讀取配置過程中需要的資料，以便於進行配置讀取的處理。大多數時候，都不需要，所以簡單地設為0即可。

模組上下文結構

這是乙個ngx_http_module_t型別的靜態變數。這個變數實際上是提供一組**函式指標，這些函式有在建立儲存配置資訊的物件的函式，也有在建立前和建立後會呼叫的函式。這些函式都將被nginx在合適的時間進行呼叫。

在建立和讀取該模組的配置資訊之前被呼叫。

postconfiguration：

在建立和讀取該模組的配置資訊之後被呼叫。

create_main_conf：

呼叫該函式建立本模組位於http block的配置資訊儲存結構。該函式成功的時候，返回建立的配置物件。失敗的話，返回null。

init_main_conf:

呼叫該函式初始化本模組位於http block的配置資訊儲存結構。該函式成功的時候，返回ngx_conf_ok。失敗的話，返回ngx_conf_error或錯誤字串。

create_srv_conf:

呼叫該函式建立本模組位於http server block的配置資訊儲存結構，每個server block會建立乙個。該函式成功的時候，返回建立的配置物件。失敗的話，返回null。

merge_srv_conf:

因為有些配置指令既可以出現在http block，也可以出現在http server block中。那麼遇到這種情況，每個server都會有自己儲存結構來儲存該server的配置，但是在這種情況下http block中的配置與server block中的配置資訊發生衝突的時候，就需要呼叫此函式進行合併，該函式並非必須提供，當預計到絕對不會發生需要合併的情況的時候，就無需提供。當然為了安全起見還是建議提供。該函式執行成功的時候，返回ngx_conf_ok。失敗的話，返回ngx_conf_error或錯誤字串。

create_loc_conf：

呼叫該函式建立本模組位於location block的配置資訊儲存結構。每個在配置中指明的location建立乙個。該函式執行成功，返回建立的配置物件。失敗的話，返回null。

merge_loc_conf:

與merge_srv_conf類似，這個也是進行配置值合併的地方。該函式成功的時候，返回ngx_conf_ok。失敗的話，返回ngx_conf_error或錯誤字串。

nginx裡面的配置資訊都是上下一層層的巢狀的，對於具體某個location的話，對於同乙個配置，如果當前層次沒有定義，那麼就使用上層的配置，否則使用當前層次的配置。

#define ngx_conf_unset       -1
#define ngx_conf_unset_uint  (ngx_uint_t) -1
#define ngx_conf_unset_ptr   (void *) -1
#define ngx_conf_unset_size  (size_t) -1
#define ngx_conf_unset_msec  (ngx_msec_t) -1

又因為對於配置項的合併，邏輯都類似，也就是前面已經說過的，如果在本層次已經配置了，也就是配置項的值已經被讀取進來了（那麼這些配置項的值就不會等於上面已經定義的那些unset的值），就使用本層次的值作為定義合併的結果，否則，使用上層的值，如果上層的值也是這些unset類的值，那就賦值為預設值，否則就使用上層的值作為合併的結果。對於這樣類似的操作，nginx定義了一些巨集操作來做這些事情，我們來看其中乙個的定義。

#define ngx_conf_merge_uint_value(conf, prev, default)                       \
if (conf ==ngx_conf_unset_uint)

以hello模組的模組上下文的定義為例：

對於開發乙個模組來說，我們都需要定義乙個ngx_module_t型別的變數來說明這個模組本身的資訊，從某種意義上來說，這是這個模組最重要的乙個資訊，它告訴了nginx這個模組的一些資訊，上面定義的配置資訊，還有模組上下文資訊，都是通過這個結構來告訴nginx系統的，也就是載入模組的上層**，都需要通過定義的這個結構，來獲取這些資訊。

ngx_module_t的定義如下：

typedef struct

ngx_module_s ngx_module_t;

struct

ngx_module_s ;

#define ngx_number_major 3

#define ngx_number_minor 1

#define ngx_module_v1 0, 0, 0, 0, \ngx_dso_abi_compatibility, ngx_number_major, ngx_number_minor

#define ngx_module_v1_padding 0, 0, 0, 0, 0, 0, 0, 0

nginx 學習筆記5

Nginx 學習筆記

Nginx學習筆記

nginx學習筆記

nginx 學習筆記5

Nginx 學習筆記

Nginx學習筆記

nginx學習筆記

相關推薦