開発ガイド
はじめに
コード レイアウト
-
auto
— ビルド スクリプト -
src
-
core
— 基本的なタイプと関数 — 文字列、配列、ログ、プールなど -
event
— イベントのコア-
modules
— イベント通知モジュール: epoll, kqueue, select など
-
-
http
— コア HTTP モジュールと共通コード-
modules
— 他のHTTPモジュール -
v2
— HTTPv2
-
-
mail
— メールモジュール -
os
— プラットフォーム固有のコード-
unix
-
win32
-
-
stream
— ストリームモジュール
-
インクルードファイル
各nginxファイルは以下の二つのファイルを含むところから始まらなければなりません:
#include <ngx_config.h> #include <ngx_core.h>
それに加えて、HTTPコードは以下を含まなければなりません
#include <ngx_http.h>
メールコードは以下を含まなければなりません
#include <ngx_mail.h>
ストリームコードは以下を含まなければなりません
#include <ngx_stream.h>
整数
一般的な目的のために、nginxのコードはintptr_t
とuintptr_t
についての型定義である二つ整数型 ngx_int_t
と ngx_uint_t
を使います。
共通リターンコード
nginxのほとんどの関数は以下のコードを返します:
-
NGX_OK
— 操作が成功 -
NGX_ERROR
— 操作が失敗 -
NGX_AGAIN
— 操作が完了しておらず、関数は再び呼ばれる必要がある -
NGX_DECLINED
— 操作が却下された。例えば、設定で無効な場合。これはエラーではありません -
NGX_BUSY
— リソースが利用できません -
NGX_DONE
— 操作が完了したか、他の場所で続いているまた、代替の成功コードとして使われます -
NGX_ABORT
— 関数が中断されました。また、代替のエラーコードとして使われます
エラーハンドリング
最後のシステムエラーコードを取得するために、ngx_errno
マクロが利用可能です。POSIXプラットフォーム上のerrno
にマップされ、Windows内でGetLastError()
コールにマップされます。最後のソケットエラー番号を取得するために、ngx_socket_errno
マクロが利用可能です。POSIXシステム上のerrno
にマップされ、Windows上でWSAGetLastError()
にマップされます。パフォーマンス上の理由でngx_errno
あるいは ngx_socket_errno
の値は連続して1回以上アクセスされるべきではありません。必要であれば、複数回使うために、エラー値はローカル変数型 ngx_err_t
に格納されるべきです。エラーを設定するために、ngx_set_errno(errno)
および ngx_set_socket_errno(errno)
マクロが利用可能です。
ngx_errno
あるいは ngx_socket_errno
の値はログ関数ngx_log_error()
と ngx_log_debugX()
に渡すことができ、その場合、システムエラーテキストがログメッセージに追加されます。
ngx_errno
を使う例:
void ngx_my_kill(ngx_pid_t pid, ngx_log_t *log, int signo) { ngx_err_t err; if (kill(pid, signo) == -1) { err = ngx_errno; ngx_log_error(NGX_LOG_ALERT, log, err, "kill(%P, %d) failed", pid, signo); if (err == NGX_ESRCH) { return 2; } return 1; } return 0; }
文字列
概要
Cの文字列については、nginxのコードは符号無し文字型ポインタ u_char *
を使います。
nginxの文字列型 ngx_str_t
は以下のように定義されます:
typedef struct { size_t len; u_char *data; } ngx_str_t;
len
フィールドは文字列の長さを保持し、data
は文字列のデータを保持します。ngx_str_t
に保持されている文字列はlen
バイトの後にnull終端子があるかも知れません。ほとんどの場合はありません。しかし、コードのある部分(例えば、設定をパースする場合)、ngx_str_t
オブジェクトはnull終端だと知られていて、その知見は文字列の比較を単純化するために使われ、それらの文字列をシステムコールに渡すのを容易にします。
多くの文字列オペレータがnginx内で提供されます。それらはsrc/core/ngx_string.h
内で定義されます。それらの幾つかは標準C関数をラップします:
-
ngx_strcmp()
-
ngx_strncmp()
-
ngx_strstr()
-
ngx_strlen()
-
ngx_strchr()
-
ngx_memcmp()
-
ngx_memset()
-
ngx_memcpy()
-
ngx_memmove()
幾つかのnginx固有の文字列関数:
-
ngx_memzero()
はメモリにゼロを詰めます。 -
ngx_cpymem()
はngx_memcpy()
と同じ事をしますが、最後の宛先のアドレスを返します。これは複数の文字列を連続して追加するのに便利です。 -
ngx_movemem()
はngx_memmove()
と同じ事をしますが、最後の宛先のアドレスを返します。 -
ngx_strlchr()
は二つのポインタによって分割された文字列内の文字を検索します。
幾つかの変換と比較関数:
-
ngx_tolower()
-
ngx_toupper()
-
ngx_strlow()
-
ngx_strcasecmp()
-
ngx_strncasecmp()
フォーマット
多くのフォーマット関数がnginxによって提供されます。これらの関数はnginx固有の型をサポートします:
-
ngx_sprintf(buf, fmt, ...)
-
ngx_snprintf(buf, max, fmt, ...)
-
ngx_slrintf(buf, last, fmt, ...)
-
ngx_vslprint(buf, last, fmt, args)
-
ngx_vsnprint(buf, max, fmt, args)
これらの関数によってサポートされるフォーマットオプションの完全なリストはsrc/core/ngx_string.c
の中で見つけることができます。それらのうちの幾つか:
%O — off_t %T — time_t %z — size_t %i — ngx_int_t %p — void * %V — ngx_str_t * %s — u_char * (null-terminated) %*s — size_t + u_char *
The ‘u’ modifier makes most types unsigned, ‘X’/‘x’ convert output to hex.
例:
u_char buf[NGX_INT_T_LEN]; size_t len; ngx_int_t n; /* set n here */ len = ngx_sprintf(buf, "%ui", n) — buf;
数値変換
数値変換の幾つかの関数はnginx内で実装されています:
-
ngx_atoi(line, n)
— 指定された長さの文字列を正数値型ngx_int_t
に変換します。エラー時にはNGX_ERROR
を返します -
ngx_atosz(line, n)
—ssize_t
型に同じことをします -
ngx_atoof(line, n)
—off_t
型に同じことをします -
ngx_atotm(line, n)
—time_t
型に同じことをします -
ngx_atofp(line, n, point)
— 指定された長さの固定小数点float数を正数値型ngx_int_t
に変換します。結果はpoints
10進位置だけ左シフトされます。The string representation of the number is expected to have no more thanpoints
fractional digits. エラー時にはNGX_ERROR
を返します。例えば、ngx_atofp("10.5", 4, 2)
は1050
を返します -
ngx_hextoi(line, n)
— 正数の16進数表現をngx_int_t
に変換します。エラー時にはNGX_ERROR
を返します
正規表現
nginxでの正規表現インタフェースはPCRE ライブラリのラッパーです。対応するヘッダファイルは src/core/ngx_regex.h
です。
文字列のマッチングのために正規表現を使うためには、まず、コンパイルされる必要があります。これは通常設定フェーズで行われます。PCREサポートは任意のため、インタフェースを使用している全てのコードは周りを取り巻くNGX_PCRE
マクロによって保護されなければなりません:
#if (NGX_PCRE) ngx_regex_t *re; ngx_regex_compile_t rc; u_char errstr[NGX_MAX_CONF_ERRSTR]; ngx_str_t value = ngx_string("message (\\d\\d\\d).*Codeword is '(?<cw>\\w+)'"); ngx_memzero(&rc, sizeof(ngx_regex_compile_t)); rc.pattern = value; rc.pool = cf->pool; rc.err.len = NGX_MAX_CONF_ERRSTR; rc.err.data = errstr; /* rc.options are passed as is to pcre_compile() */ if (ngx_regex_compile(&rc) != NGX_OK) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "%V", &rc.err); return NGX_CONF_ERROR; } re = rc.regex; #endif
After successful compilation, ngx_regex_compile_t
structure
fields captures
and named_captures
are filled with count of all and named captures respectively found in the
regular expression.
Later, the compiled regular expression may be used to match strings against it:
ngx_int_t n; int captures[(1 + rc.captures) * 3]; ngx_str_t input = ngx_string("This is message 123. Codeword is 'foobar'."); n = ngx_regex_exec(re, &input, captures, (1 + rc.captures) * 3); if (n >= 0) { /* string matches expression */ } else if (n == NGX_REGEX_NO_MATCHED) { /* no match was found */ } else { /* some error */ ngx_log_error(NGX_LOG_ALERT, log, 0, ngx_regex_exec_n " failed: %i", n); }
The arguments of ngx_regex_exec()
are: the compiled regular
expression re
, string to match s
,
optional array of integers to hold found captures
and its size
.
The captures
array size must be a multiple of three,
per requirements of the
PCRE API.
In the example, its size is calculated from a total number of captures plus
one for the matched string itself.
Now, if there are matches, captures may be accessed:
u_char *p; size_t size; ngx_str_t name, value; /* all captures */ for (i = 0; i < n * 2; i += 2) { value.data = input.data + captures[i]; value.len = captures[i + 1] — captures[i]; } /* accessing named captures */ size = rc.name_size; p = rc.names; for (i = 0; i < rc.named_captures; i++, p += size) { /* capture name */ name.data = &p[2]; name.len = ngx_strlen(name.data); n = 2 * ((p[0] << 8) + p[1]); /* captured value */ value.data = &input.data[captures[n]]; value.len = captures[n + 1] — captures[n]; }
The ngx_regex_exec_array()
function accepts the array of ngx_regex_elt_t
elements (which are just compiled regular expressions with associated names), a string to match and a log. The function will apply expressions from the array to the string until the match is found or no more expressions are left. 合致した場合には返り値はNGX_OK
で、そうでなければNGX_DECLINED
、あるいはエラー時にはNGX_ERROR
です。
コンテナ
配列
nginx配列型ngx_array_t
は以下のように定義されます
typedef struct { void *elts; ngx_uint_t nelts; size_t size; ngx_uint_t nalloc; ngx_pool_t *pool; } ngx_array_t;
配列の要素はelts
フィールドを使って利用可能です。要素の数はnelts
フィールドに格納されています。size
フィールドは1つの要素のサイズを保持し、配列を初期化する時に設定されます。
配列はngx_array_create(pool, n, size)
呼び出しを使ってプール内に生成することができます。既に割り当てられている配列オブジェクトは ngx_array_init(array, pool, n, size)
呼び出しを使って初期化することができます。
ngx_array_t *a, b; /* create an array of strings with preallocated memory for 10 elements */ a = ngx_array_create(pool, 10, sizeof(ngx_str_t)); /* initialize string array for 10 elements */ ngx_array_init(&b, pool, 10, sizeof(ngx_str_t));
配列への要素の追加は以下の関数を使って行われます:
-
ngx_array_push(a)
は後に1つの要素を追加し、それへのポインタを返します。 -
ngx_array_push_n(a, n)
は後にn
個の要素を追加し、最初の要素へのポインタを返します。
もし現在割り当てられているメモリが新しい要素に十分ではない場合、要素のための新しいメモリが割り当てられ、既存の要素がメモリにコピーされるでしょう。新しいメモリブロックは通常既存のものの2倍の大きさです。
s = ngx_array_push(a); ss = ngx_array_push_n(&b, 3);
リスト
nginxでのリストは配列の系列で、潜在的に大量の項目を挿入できるように最適化されています。リストの型は以下のように定義されます:
typedef struct { ngx_list_part_t *last; ngx_list_part_t part; size_t size; ngx_uint_t nalloc; ngx_pool_t *pool; } ngx_list_t;
実施あの項目は、以下で定義されるリストの一部に格納されます:
typedef struct ngx_list_part_s ngx_list_part_t; struct ngx_list_part_s { void *elts; ngx_uint_t nelts; ngx_list_part_t *next; };
最初に、リストはngx_list_init(list, pool, n, size)
の呼び出しで初期化されるか、ngx_list_create(pool, n, size)
の呼び出しで生成されなければなりません。両方の関数とも1つの項目のサイズとリスト部分ごとの項目の数を受け取ります。ngx_list_push(list)
関数はリストに項目を追加するために使われます。以下の例で分かるように、直接リストのフィールドにアクセスすることで項目の繰り返しが行われます。
ngx_str_t *v; ngx_uint_t i; ngx_list_t *list; ngx_list_part_t *part; list = ngx_list_create(pool, 100, sizeof(ngx_str_t)); if (list == NULL) { /* error */ } /* add items to the list */ v = ngx_list_push(list); if (v == NULL) { /* error */ } ngx_str_set(v, "foo"); v = ngx_list_push(list); if (v == NULL) { /* error */ } ngx_str_set(v, "bar"); /* iterate over the list */ part = &list->part; v = part->elts; for (i = 0; /* void */; i++) { if (i >= part->nelts) { if (part->next == NULL) { break; } part = part->next; v = part->elts; i = 0; } ngx_do_smth(&v[i]); }
nginxでのリストの主要な使い方はHTTP入力と出力ヘッダです。
リストは項目の削除をサポートしません。しかし、必要であれば、項目はリストから実際に削除すること無しに外すように内部的に印をつけることができます。例えば、ngx_table_elt_t
として格納されているHTTP出力ヘッダは、ngx_table_elt_t
のhash
フィールドをゼロに設定することで外すことができます。ヘッダ上を繰り返す時に、そのような項目は明示的にスキップされます。
キュー
nginxでのキューは各ノードが以下のように定義されている二重にリンクされた出しゃばりのリストです:
typedef struct ngx_queue_s ngx_queue_t; struct ngx_queue_s { ngx_queue_t *prev; ngx_queue_t *next; };
先頭のキューノードはどのようなデータともリンクしていません。使う前に、リストの先頭はngx_queue_init(q)
呼び出しで初期化される必要があります。キューは以下の操作をサポートします:
-
ngx_queue_insert_head(h, x)
,ngx_queue_insert_tail(h, x)
— 新しいノードを挿入する -
ngx_queue_remove(x)
— キューのノードを削除する -
ngx_queue_split(h, q, n)
— ノードでキューを分割し、キューの残りが分割されたキューの中で返されます -
ngx_queue_add(h, n)
— 二つ目のキューを最初のキューに追加する -
ngx_queue_head(h)
,ngx_queue_last(h)
— 最初あるいは最後のキューノードを取得する -
ngx_queue_sentinel(h)
- get a queue sentinel object to end iteration at -
ngx_queue_data(q, type, link)
— get reference to the beginning of a queue node data structure, considering the queue field offset in it
例:
typedef struct { ngx_str_t value; ngx_queue_t queue; } ngx_foo_t; ngx_foo_t *f; ngx_queue_t values; ngx_queue_init(&values); f = ngx_palloc(pool, sizeof(ngx_foo_t)); if (f == NULL) { /* error */ } ngx_str_set(&f->value, "foo"); ngx_queue_insert_tail(&values, f); /* insert more nodes here */ for (q = ngx_queue_head(&values); q != ngx_queue_sentinel(&values); q = ngx_queue_next(q)) { f = ngx_queue_data(q, ngx_foo_t, queue); ngx_do_smth(&f->value); }
赤黒木
src/core/ngx_rbtree.h
ヘッダファイルは赤黒木の効果的な実装への参照を提供します。
typedef struct { ngx_rbtree_t rbtree; ngx_rbtree_node_t sentinel; /* custom per-tree data here */ } my_tree_t; typedef struct { ngx_rbtree_node_t rbnode; /* custom per-node data */ foo_t val; } my_node_t;
木を全体として扱うために、二つのノードが必要です: ルートと歩哨です。一般的にそれらは何らかの独自の構造に追加されます。従ってデータを葉がデータへのリンクあるいはデータを埋め込む木へ整理することができます。
木を初期化するには:
my_tree_t root; ngx_rbtree_init(&root.rbtree, &root.sentinel, insert_value_function);
insert_value_function
は木を行き来し、新しい値を正しい場所に挿入する責任を持つ関数です。例えば、ngx_str_rbtree_insert_value
関数はngx_str_t
型を扱うように設計されています。
void ngx_str_rbtree_insert_value(ngx_rbtree_node_t *temp, ngx_rbtree_node_t *node, ngx_rbtree_node_t *sentinel)
引数は、挿入の付け根のノードへのポインタ、追加される新しく作成されたノード、および木の歩哨です。
行き来はとても率直なもので、以下の捜索機能パターンを使って実演することができます:
my_node_t * my_rbtree_lookup(ngx_rbtree_t *rbtree, foo_t *val, uint32_t hash) { ngx_int_t rc; my_node_t *n; ngx_rbtree_node_t *node, *sentinel; node = rbtree->root; sentinel = rbtree->sentinel; while (node != sentinel) { n = (my_node_t *) node; if (hash != node->key) { node = (hash < node->key) ? node->left : node->right; continue; } rc = compare(val, node->val); if (rc < 0) { node = node->left; continue; } if (rc > 0) { node = node->right; continue; } return n; } return NULL; }
compare()
は、ゼロより少ない、等しい、あるいは大きいという値を返す伝統的な比較器です。検索を高速化し、大きいかも知れないユーザのオブジェクトの比較を避けるために、整数のハッシュフィールドが使われます。
ノードを木に追加するために、新しいノードを割り当て、それを初期化し、そしてngx_rbtree_insert()
を呼びます:
my_node_t *my_node; ngx_rbtree_node_t *node; my_node = ngx_palloc(...); init_custom_data(&my_node->val); node = &my_node->rbnode; node->key = create_key(my_node->val); ngx_rbtree_insert(&root->rbtree, node);
ノードを削除するには:
ngx_rbtree_delete(&root->rbtree, node);
ハッシュ
ハッシュテーブル関数は src/core/ngx_hash.h
で定義されています。正確、およびワイルドカードの合致がサポートされます。後者は特別なセットアップを必要とし、以下の別の章で説明されます。
nginxはハッシュを任意でビルドすることができるため、ハッシュを初期化するには、前もって要素の数を知る必要があります。設定するために必要な二つのパラメータは max_size
と bucket_size
です。これらのセットアップの詳細は、別のドキュメントの中で提供されます。通常、これらの二つのパラメータはユーザによって設定されます:ハッシュの初期化設定はngx_hash_init_t
型として格納され、ハッシュ自身は ngx_hash_t
です:
ngx_hash_t foo_hash; ngx_hash_init_t hash; hash.hash = &foo_hash; hash.key = ngx_hash_key; hash.max_size = 512; hash.bucket_size = ngx_align(64, ngx_cacheline_size); hash.name = "foo_hash"; hash.pool = cf->pool; hash.temp_pool = cf->temp_pool;
キー
は文字列からハッシュの整数キーを生成する関数へのポインタです。二つの一般的な関数が提供されています:ngx_hash_key(data, len)
と ngx_hash_key_lc(data, len)
。後者は文字列を小文字に変換します。従って渡される文字列が書き込み可能である必要があります。そうでない場合は、配列キーを初期化するNGX_HASH_READONLY_KEY
フラグが関数に渡されるかも知れません (以下を見てください)。
ハッシュのキーはngx_hash_keys_arrays_t
に格納され、ngx_hash_keys_array_init(arr, type)
を使って初期化されます:
ngx_hash_keys_arrays_t foo_keys; foo_keys.pool = cf->pool; foo_keys.temp_pool = cf->temp_pool; ngx_hash_keys_array_init(&foo_keys, NGX_HASH_SMALL);
二つ目のパラメータはNGX_HASH_SMALL
あるいは NGX_HASH_LARGE
のどちらかが可能で、ハッシュのための予め割り当てられるリソースの量を制御します。ハッシュが多数の要素を含むことが期待される場合、NGX_HASH_LARGE
を使ってください。
ngx_hash_add_key(keys_array, key, value, flags)
関数はキーをハッシュキー配列に挿入するために使われます;
ngx_str_t k1 = ngx_string("key1"); ngx_str_t k2 = ngx_string("key2"); ngx_hash_add_key(&foo_keys, &k1, &my_data_ptr_1, NGX_HASH_READONLY_KEY); ngx_hash_add_key(&foo_keys, &k2, &my_data_ptr_2, NGX_HASH_READONLY_KEY);
ここで、ハッシュテーブルはngx_hash_init(hinit, key_names, nelts)
の呼び出しを使って構築されるかも知れません:
ngx_hash_init(&hash, foo_keys.keys.elts, foo_keys.keys.nelts);
max_size
あるいは bucket_size
パラメータが十分に大きくない場合は、これは失敗するかも知れません。ハッシュが構築される時、ngx_hash_find(hash, key, name, len)
関数は要素を調べるために使われるかも知れません:
my_data_t *data; ngx_uint_t key; key = ngx_hash_key(k1.data, k1.len); data = ngx_hash_find(&foo_hash, key, k1.data, k1.len); if (data == NULL) { /* key not found */ }
ワイルドカード マッチング
ワイルドカードを使って動作するハッシュを生成するには、ngx_hash_combined_t
型が使われます。それは、上で説明されるハッシュ型を含み、二つの追加のキー配列を持ちます: dns_wc_head
と dns_wc_tail
。基本的なプロパティの初期化は通常のハッシュと同じように行われます:
ngx_hash_init_t hash ngx_hash_combined_t foo_hash; hash.hash = &foo_hash.hash; hash.key = ...;
NGX_HASH_WILDCARD_KEY
フラグを使ってワイルドカードキーを追加することが可能です:
/* k1 = ".example.org"; */ /* k2 = "foo.*"; */ ngx_hash_add_key(&foo_keys, &k1, &data1, NGX_HASH_WILDCARD_KEY); ngx_hash_add_key(&foo_keys, &k2, &data2, NGX_HASH_WILDCARD_KEY);
関数はワイルドカードを理解し、キーを対応する配列に追加します。ワイルドカードの構文と合致アルゴリズムの説明については、map モジュールのドキュメントを参照してください。
追加されたキーの内容に依存して、三つのキー配列を初期化する必要があるかも知れません: 1つは(上で説明された)完全な合致のため、2つは文字列の始まりあるいは終わりから開始する合致のためです。
if (foo_keys.dns_wc_head.nelts) { ngx_qsort(foo_keys.dns_wc_head.elts, (size_t) foo_keys.dns_wc_head.nelts, sizeof(ngx_hash_key_t), cmp_dns_wildcards); hash.hash = NULL; hash.temp_pool = pool; if (ngx_hash_wildcard_init(&hash, foo_keys.dns_wc_head.elts, foo_keys.dns_wc_head.nelts) != NGX_OK) { return NGX_ERROR; } foo_hash.wc_head = (ngx_hash_wildcard_t *) hash.hash; }
キー配列はソートされる必要があり、初期化の結果は結合されたハッシュに追加されなければなりません。dns_wc_tail
配列の初期化は同じように行われます。
結合されたハッシュ内での照合はngx_hash_find_combined(chash, key, name, len)
によって扱われます:
/* key = "bar.example.org"; — will match ".example.org" */ /* key = "foo.example.com"; — will match "foo.*" */ hkey = ngx_hash_key(key.data, key.len); res = ngx_hash_find_combined(&foo_hash, hkey, key.data, key.len);
メモリ管理
ヒープ
システムヒープからメモリを割り当てるために、以下の関数がnginxによって提供されています:
-
ngx_alloc(size, log)
— システムヒープからメモリを割り当てる。これはログのサポートを持つmalloc()
のラッパーです。割り当てエラーとデバッグ情報がlog
に記録されます。 -
ngx_calloc(size, log)
—ngx_alloc()
と同じですが、割り当ての後でメモリがゼロで埋められます -
ngx_memalign(alignment, size, log)
— システムヒープから揃えられたメモリが割り当てられます。これは、供給するプラットフォーム上でposix_memalign()
をラッパーします。そうでなければ実装は最大の割り当てを提供するngx_alloc()
で代用されます。 -
ngx_free(p)
— 割り当てられたメモリを解放します。これはfree()
のラッパーです
プール
ほとんどのnginxの割り当てはプール内で行われます。nginxのプールで割り当てられたメモリはプールが破壊された時に自動的に開放されます。これにより割り当てのパフォーマンスが良くなり、メモリの制御が簡単になります。
プールはメモリの連続するブロックの中でオブジェクトを内部的に割り当てます。ブロックが埋まると、新しいブロックが割り当てられ、プールメモリブロックリストへ追加されます。ブロックに収まらない大きな割り当てが要求された場合、そのような割り当てはシステムのアロケータに転送され、更なる割り当ての解除のためにプール内に返されたポインタが格納されます。
Nginxのプールは型ngx_pool_t
を持ちます。以下の操作がサポートされます:
-
ngx_create_pool(size, log)
— 指定されたブロックサイズを持つプールを作成します。返されたプールオブジェクトは同じようにプール内に割り当てられます。 -
ngx_destroy_pool(pool)
—プールオブジェクト自身を含む全てのプールメモリを解放します。 -
ngx_palloc(pool, size)
— プールから揃えられたメモリが割り当てられます -
ngx_pcalloc(pool, size)
— プールから揃えられたメモリが割り当てられ、ゼロで埋められます。 -
ngx_pnalloc(pool, size)
— プールから揃えられていないメモリが割り当てられます。ほとんどは文字列を割り当てるために使われます -
ngx_pfree(pool, p)
— プール内で以前に割り当てられたメモリを解放します。システムアロケータに転送された割り当てのみ開放することができます。
u_char *p; ngx_str_t *s; ngx_pool_t *pool; pool = ngx_create_pool(1024, log); if (pool == NULL) { /* error */ } s = ngx_palloc(pool, sizeof(ngx_str_t)); if (s == NULL) { /* error */ } ngx_str_set(s, "foo"); p = ngx_pnalloc(pool, 3); if (p == NULL) { /* error */ } ngx_memcpy(p, "foo", 3);
nginxではチェイン リンク ngx_chain_t
が積極的に使われるため、nginxのプールはそれらを再利用する方法を提供します。ngx_pool_t
の chain
フィールドは再利用のために以前割り当てられたリンクのリストを準備し続けます。プール内での効率的なチェインリンクの割り当てのために、関数ngx_alloc_chain_link(pool)
が使われるべきです。This function looks up a free chain link in the pool list and only if it's empty allocates a new one. リンクを解放するにはngx_free_chain(pool, cl)
が呼ばれるべきです。
クリーンナップ ハンドラはプール内に登録することができます。クリーンナップ ハンドラはプールが破壊される時に呼ばれる引数を持つコールバックです。プールは通常特定の(HTTPリクエスト)のようなnginxオブジェクトと紐付けられ、オブジェクトの生存期間の最後にはオブジェクト自身を解放しながら破壊されます。Registering a pool cleanup is a convenient way to release resources, close file descriptors or make final adjustments to shared data, associated with the main object.
A pool cleanup is registered by calling ngx_pool_cleanup_add(pool, size)
which returns ngx_pool_cleanup_t
pointer to be filled by the caller. size
引数はクリーンナップ ハンドラのためにコンテキストを割り当てることができます。
ngx_pool_cleanup_t *cln; cln = ngx_pool_cleanup_add(pool, 0); if (cln == NULL) { /* error */ } cln->handler = ngx_my_cleanup; cln->data = "foo"; ... static void ngx_my_cleanup(void *data) { u_char *msg = data; ngx_do_smth(msg); }
共有メモリ
共有メモリはプロセス間での共通データを共有するためにnginxによって使われます。関数 ngx_shared_memory_add(cf, name, size, tag)
はサイクルに新しい共有メモリ エントリ ngx_shm_zone_t
を追加します。関数はゾーンのname
と size
を受け取ります。各共有ゾーンはユニークな名前を持たなければなりません。もし指定された名前を持つ共有ゾーン エントリが存在する場合、タグの値も一致すれば古いゾーン エントリは再利用されます。一致しないタグはエラーと見なされます。通常、モジュール構造のアドレスがタグとして渡され、1つのnginxモジュール内で名前によって共有ゾーンを再利用することができます。
共有メモリ エントリ構造 ngx_shm_zone_t
は以下のフィールドを持ちます:
-
init
— 共有ゾーンが実際のメモリにマップされた後で呼ばれる初期化コールバック -
data
— 任意のデータをinit
コールバックに渡すために使われるデータコンテキスト -
noreuse
— 古いサイクルからの共有ゾーンの再利用を無効にするフラグ -
tag
— 共有ゾーンフラグ -
shm
— 少なくとも以下のフィールドを持つ、プラットフォーム固有のngx_shm_t
型のオブジェクト:-
addr
— 最初はNULLのマップされた共有メモリアドレス -
size
— 共有メモリサイズ -
name
— 共有メモリ名 -
log
— 共有メモリログ -
exists
— 共有メモリがマスタープロセスから継承されたことを示すフラグ (Windows固有)
-
共有ゾーン エントリは設定がパースされた後でngx_init_cycle()
内の実際のメモリにマップされます。POSIXシステム上では、mmap()
syscall が共有匿名マッピングを生成するために使われます。Windows上では、CreateFileMapping()/MapViewOfFileEx()
ペアが使われます。
共有メモリ内で割り当てるために、nginxはスラブ プール ngx_slab_pool_t
を提供します。各nginx共有ゾーンの中で、スラブ プールはそのゾーン内でメモリを割り当てるために自動的に生成されます。プールは共有ゾーンの最初に位置していて、表現(ngx_slab_pool_t *) shm_zone->shm.addr
によってアクセスすることができます。共有ゾーンでの割り当ては ngx_slab_alloc(pool, size)/ngx_slab_calloc(pool, size)
関数のうちの一つの呼び出しによって行われます。メモリは ngx_slab_free(pool, p)
の呼び出しによって解放されます。
スラブ プールは全ての共有ゾーンをページに分割します。各ページは同じサイズのオブジェクトを割り当てるために使われます。8以上の二乗のサイズが考慮されます。他のサイズはそれらの値のうちの一つに丸められます。For each page, a bitmask is kept, showing which blocks within that page are in use and which are free for allocation. 半分のページ(通常 2048バイト)より大きい場合、ページ全体まで割り当てが行われます。
同時アクセスから共有メモリ内のデータを守るためには、ngx_slab_pool_t
のmutex
フィールド内でmutexが利用可能です。メモリを割り当ておよび開放する間、スラブによってmutexが使われます。しかし、それは共有ゾーン内で割り当てられてる他のユーザデータ構造を保護するために使うことができます。ngx_shmtx_lock(&shpool->mutex)
を呼び出すことでロッキングが行われ、ngx_shmtx_unlock(&shpool->mutex)
を呼び出すことでアンロッキングが行われます。
ngx_str_t name; ngx_foo_ctx_t *ctx; ngx_shm_zone_t *shm_zone; ngx_str_set(&name, "foo"); /* allocate shared zone context */ ctx = ngx_pcalloc(cf->pool, sizeof(ngx_foo_ctx_t)); if (ctx == NULL) { /* error */ } /* add an entry for 65k shared zone */ shm_zone = ngx_shared_memory_add(cf, &name, 65536, &ngx_foo_module); if (shm_zone == NULL) { /* error */ } /* register init callback and context */ shm_zone->init = ngx_foo_init_zone; shm_zone->data = ctx; ... static ngx_int_t ngx_foo_init_zone(ngx_shm_zone_t *shm_zone, void *data) { ngx_foo_ctx_t *octx = data; size_t len; ngx_foo_ctx_t *ctx; ngx_slab_pool_t *shpool; value = shm_zone->data; if (octx) { /* reusing a shared zone from old cycle */ ctx->value = octx->value; return NGX_OK; } shpool = (ngx_slab_pool_t *) shm_zone->shm.addr; if (shm_zone->shm.exists) { /* initialize shared zone context in Windows nginx worker */ ctx->value = shpool->data; return NGX_OK; } /* initialize shared zone */ ctx->value = ngx_slab_alloc(shpool, sizeof(ngx_uint_t)); if (ctx->value == NULL) { return NGX_ERROR; } shpool->data = ctx->value; return NGX_OK; }
ログ
nginxのコードを記録するには、ngx_log_t
オブジェクトを使います。Nginxのロガーは出力の幾つかのタイプをサポートします:
- stderr — 標準エラー出力に記録します
- file — ファイルに記録します
- syslog — syslogに記録します
- memory — 開発目的のために内部的なメモリストレージに記録します。メモリはデバッガーによって後でアクセスされるかもしれません。
ロガーインスタンスは実際にはお互いにnext
フィールドでリンクされたロガーのチェーンかも知れません。各メッセージはチェーン内で全てのロガーに記録されます。
各ロガーはログに書き込まれるメッセージを制限するエラーレベルを持ちます。以下のエラーレベルがnginxでサポートされます:
-
NGX_LOG_EMERG
-
NGX_LOG_ALERT
-
NGX_LOG_CRIT
-
NGX_LOG_ERR
-
NGX_LOG_WARN
-
NGX_LOG_NOTICE
-
NGX_LOG_INFO
-
NGX_LOG_DEBUG
デバッグのログのために、デバッグマスクもチェックされます。以下のデバッグマスクが存在します:
-
NGX_LOG_DEBUG_CORE
-
NGX_LOG_DEBUG_ALLOC
-
NGX_LOG_DEBUG_MUTEX
-
NGX_LOG_DEBUG_EVENT
-
NGX_LOG_DEBUG_HTTP
-
NGX_LOG_DEBUG_MAIL
-
NGX_LOG_DEBUG_STREAM
通常、ロガーは既存のnginxコードによってerror_log
ディレクティブから生成され、サイクル、設定、クライアント接続および他のオブジェクトのほとんど全ての処理のステージで利用可能です。
Nginx は以下のログ マクロを提供します:
-
ngx_log_error(level, log, err, fmt, ...)
— エラーログ -
ngx_log_debug0(level, log, err, fmt)
,ngx_log_debug1(level, log, err, fmt, arg1)
etc — デバッグログ。8つまでの整形引数がサポートされます
ログメッセージはスタック上のサイズNGX_MAX_ERROR_STR
(現在のところ 2048 バイト)のバッファ内で整形されます。メッセージはエラーレベル、プロセスID,接続id (log->connection
に格納されています)およびシステムエラー テキストが前に付きます。非デバッグメッセージについては、もっと特定の情報がログメッセージに付くようにlog->handler
が呼ばれます。HTTP モジュールは、クライアントとサーバアドレス、現在のアクション(log->action
に格納されています)、クライアント リクエスト ライン、サーバ名などを記録するためにログ ハンドラとしてngx_http_log_error()
関数を設定します。
例:
/* specify what is currently done */ log->action = "sending mp4 to client”; /* error and debug log */ ngx_log_error(NGX_LOG_INFO, c->log, 0, "client prematurely closed connection”); ngx_log_debug2(NGX_LOG_DEBUG_HTTP, mp4->file.log, 0, "mp4 start:%ui, length:%ui”, mp4->start, mp4->length);
Logging result:
2016/09/16 22:08:52 [info] 17445#0: *1 client prematurely closed connection while sending mp4 to client, client: 127.0.0.1, server: , request: "GET /file.mp4 HTTP/1.1” 2016/09/16 23:28:33 [debug] 22140#0: *1 mp4 start:0, length:10000
サイクル
サイクルオブジェクトは特定の設定から生成されるnginxの実行時コンテキストを保持します。サイクルの型はngx_cycle_t
です。設定がリロードされる時、新しいサイクルがnginx設定の新しいバージョンから生成されます。古いサイクルは新しいものがうまく生成された後で通常削除されます。現在のところ、活動中のサイクルはngx_cycle
グローバル変数に格納され、新しくスタートしたnginxワーカーによって継承されます。
サイクルは関数 ngx_init_cycle()
によって生成されます。関数は古いサイクルを引数として取ります。それは設定ファイルの場所を特定するために使われ、nginxをスムーズに実行し続けるために古いサイクルからできる限り多くのリソースを継承します。nginxが開始した時に、"init cycle"と呼ばれる偽物のサイクルが生成され、その後設定から作られた通常のサイクルによって置き換えられます。
サイクルの幾つかのメンバー:
-
pool
— サイクル プール。新しい各サイクルのために作られます -
log
— サイクル ログ。最初に、このログが古いサイクルから継承されます。設定を読んだ後で、このメンバーがnew_log
を指すように設定されます -
new_log
— 設定によって作られたサイクル ログ。ルート スコープerror_log
ディレクティブによって影響をうけます -
connections
,connections_n
— 型ngx_connection_t
の接続のワーカーごとの配列。各nginxワーカーを初期化する時にイベントモジュールによって生成されます。接続の数はworker_connections
ディレクティブによって設定されます。 -
free_connections
,free_connections_n
— 現在利用可能な接続の数。利用可能な接続が無い場合、nginxワーカーは新しいクライアントを受け付けることを拒否します。 -
files
,files_n
— ファイルディスクリプタをnginx接続にマッピングするための配列。このマッピングはイベントモジュールによって使われ、NGX_USE_FD_EVENT
フラグ (現在のところ、それはプールとdevプールです)を持ちます。 -
conf_ctx
— コアモジュール設定の配列。nginx設定ファイルを読み込む間に設定が生成され、満たされます。 -
modules
,modules_n
— モジュールngx_module_t
の配列で、静的および動的であり、現在の設定によってロードされます -
listening
— リスニング オブジェクトngx_listening_t
の配列。リスニング オブジェクトは通常ngx_create_listening()
を呼ぶ異なるモジュールのlisten
ディレクティブによって追加されます。リスニング オブジェクトに基づいて、listenソケットがnginxによって生成されます。 -
paths
— パスngx_path_t
の配列。パスは、特定のディレクティブ上で操作することができるモジュールからngx_add_path()
関数を呼び出すことで追加されます。これらのディレクティブが無い場合は、設定の読み込みの後でこれらのディレクティブが生成されます。さらに、二つのハンドラを各パスについて設定することができます:- path loader — nginxの開始あるいはリロード後の60秒以内に一度だけ実行されます。通常、ディレクトリを読み込み、nginx共有メモリにデータを格納します。ハンドラは専用のnginxプロセス “nginx cache loader” から呼ばれます。
- path manager — 定期的に実行されます。通常は、ディレクトリから古いファイルを削除し、これらの変更をnginxメモリに反映します。ハンドラは専用のnginxプロセス “nginx cache manager” から呼ばれます
-
open_files
—ngx_open_file_t
オブジェクトのリスト。オープン ファイル オブジェクトは関数ngx_conf_open_file()
の呼び出しによって生成されます。設定の読み込み後に、nginxはopen_files
リストから全てのファイルを開き、各オープン ファイル オブジェクトのfd
フィールド内にファイルディスクリプタを格納します。ファイルは追記モードで開かれ、無い場合は生成されます。再オープンシグナル(通常それはUSR1
です)を受け取った時に、このリストからのファイルはnginxワーカーによって再オープンされます。この場合、fd
フィールドは新しいディスクリプタに変更されます。オープンファイルは現在のところログのために使われます。 -
shared_memory
— 共有メモリゾーンのリスト。それぞれはngx_shared_memory_add()
関数の呼び出しによって追加されます。共有ゾーンは全てのnginxプロセスの中で同じアドレス範囲にマップされ、例えばHTTPキャッシュ インメモリ ツリーのような共通データを共有するために使われます
バッファ
入力/出力オペレーションのために、nginxはバッファ型 ngx_buf_t
を提供します。通常、それは宛先に書き込まれるためのデータを保持するためか、ソースから読み込むために使われます。バッファはメモリ内およびファイル内でデータを参照することができます。技術的には、バッファが同時に二つを参照することができます。バッファのためのメモリは個々に割り当てられ、バッファ構造 ngx_buf_t
には関係しません。
構造 ngx_buf_t
は以下のフィールドを持ちます:
-
start
,end
— メモリブロックの境界で、バッファのために割り当てられます。 -
pos
,last
— メモリバッファの境界で、通常はstart
..end
の部分領域です -
file_pos
,file_last
— ファイルバッファの境界で、ファイルの先頭からのオフセットです。 -
tag
— ユニークな値で、バッファを区別するために使われ、通常はバッファの再利用のために異なるnginxモジュールによって生成されます -
file
— ファイルオブジェクト -
temporary
— フラグ。バッファが書き込み可能なメモリを参照することを意味します。 -
memory
— フラグ。バッファが読み込みのみ可能なメモリを参照することを意味します -
in_file
— フラグ。現在のバッファがファイル内のデータを参照することを意味します -
flush
— フラグ。このバッファより前の全てのデータがフラッシュされるべきであることを意味します -
recycled
— フラグ。バッファが再利用可能でできる限り消費されなければならないことを意味します -
sync
— フラグ。バッファが何もデータを運ばないか、flush
あるいはlast_buf
のような特別なシグナルを運ぶことを意味します。通常、そのようなバッファはnginxによってエラーと見なされます。このフラグはエラーのチェックをスキップすることができます -
last_buf
— フラグ。現在のバッファが入力内で最後であることを意味します -
last_in_chain
— フラグ。(サブ)リクエスト内にそれ以上のデータバッファが無いことを意味します -
shadow
— 現在のバッファに関係する他のバッファへのリファレンス通常現在のバッファはシャドーバッファからのデータを使います。現在のバッファが一度消費されると、シャドーバッファも通常消費されたとマークされなければなりません -
last_shadow
— フラグ。現在のバッファが最後のバッファであることを意味し、特定のシャドーバッファを参照します -
temp_file
— フラグ。バッファが一時ファイル内にあることを意味します
入力および出力のために、バッファはチェーンでリンクされます。チェーンはチェーンリンクngx_chain_t
の順列で、以下のように定義されます:
typedef struct ngx_chain_s ngx_chain_t; struct ngx_chain_s { ngx_buf_t *buf; ngx_chain_t *next; };
各チェーンリンクはバッファへの参照と次のチェーンリンクへの参照を保持します。
バッファとチェーンの使用例:
ngx_chain_t * ngx_get_my_chain(ngx_pool_t *pool) { ngx_buf_t *b; ngx_chain_t *out, *cl, **ll; /* first buf */ cl = ngx_alloc_chain_link(pool); if (cl == NULL) { /* error */ } b = ngx_calloc_buf(pool); if (b == NULL) { /* error */ } b->start = (u_char *) "foo"; b->pos = b->start; b->end = b->start + 3; b->last = b->end; b->memory = 1; /* read-only memory */ cl->buf = b; out = cl; ll = &cl->next; /* second buf */ cl = ngx_alloc_chain_link(pool); if (cl == NULL) { /* error */ } b = ngx_create_temp_buf(pool, 3); if (b == NULL) { /* error */ } b->last = ngx_cpymem(b->last, "foo", 3); cl->buf = b; cl->next = NULL; *ll = cl; return out; }
ネットワーク
接続
接続型 ngx_connection_t
はソケットディスクリプタのラッパーです。構造のフィールドの幾つかは次のようなものです:
-
fd
— ソケットディスクリプタ -
data
— 任意の接続コンテキスト通常、高レベルオブジェクトへのポインタで、接続の上に構築され、HTTPリクエストあるいはストリームセッションのようなものです -
read
,write
— 接続のための読み込みおよび書き込みイベント -
recv
,send
,recv_chain
,send_chain
— 接続のための I/O オペレーション -
pool
— コネクションプール -
log
— コネクションログ -
sockaddr
,socklen
,addr_text
— バイナリおよびテキスト形式のリモートのソケットアドレス -
local_sockaddr
,local_socklen
— バイナリ形式のローカルソケットアドレス。最初は、これらのフィールドは空です。関数ngx_connection_local_sockaddr()
はソケットのローカルアドレスを取得するために使われなければなりません。 -
proxy_protocol_addr
,proxy_protocol_port
- PROXYプロトコルが接続のために有効な場合、PROXY プロトコルのクライアントアドレスとポート -
ssl
— nginx コネクション SSL コンテキスト -
reusable
— フラグ。接続が再利用可能な場合、その状態にあることを意味します。 -
close
— フラグ。接続が再利用されていて、閉じられなければならないことを意味します
nginxの接続は透過的にSSL層をカプセル化します。この場合、接続ssl
フィールドはngx_ssl_connection_t
構造へのポインタを保持し、SSL_CTX
と SSL
を含む接続のための全てのSSLに関係するデータを持ち続けます。ハンドラ recv
, send
, recv_chain
, send_chain
はSSL関数へも設定されます。
nginxのワーカーあたりの接続の数はworker_connections
の値によって制限されます。全ての接続の構造は、ワーカーが開始する時にあらかじめ作成され、サイクルオブジェクトのconnections
フィールドの中に格納されます。接続の構造に手を伸ばすには、ngx_get_connection(s, log)
関数が使われます。関数は接続構造の中でラップされる必要がある複数の
ソケットディスクリプタを受け取ります。
ワーカーあたりの接続の数が制限されるため、nginxは現在使われている接続を横取りする方法を提供します。接続の再利用を有効あるいは無効にするために、関数ngx_reusable_connection(c, reusable)
が呼ばれます。ngx_reusable_connection(c, 1)
の呼び出しは接続構造のreuse
フラグを設定し、その接続をサイクルのreusable_connections_queue
に挿入します。ngx_get_connection()
はサイクルのfree_connections
リストの中に利用可能な接続が無いと分かるといつでも特定の数の再利用可能な接続lを解放するためにngx_drain_connections()
を呼びます。For each such connection, the close
flag is set and its read handler is called which is supposed to free the connection by calling ngx_close_connection(c)
and make it available for reuse. 接続が再利用可能な時に状態を抜けるためにngx_reusable_connection(c, 0)
が呼ばれます。nginxでの再利用可能な接続の例は、クライアントから何らかのデータを受け取るまで再利用可能だとマークされているHTTPクライアントの接続です。
イベント
イベント
nginxでのイベントオブジェクトngx_event_t
は特定のイベントが起きていることを伝える方法を提供します。
ngx_event_t
のフィールドの幾つかは次のようなものです:
-
data
— arbitrary event context, used in event handler, usually, a pointer to a connection, tied with the event -
handler
— イベントが起きた時に発動されるコールバック関数 -
write
— フラグ。これがwriteイベントということを意味します。readとwriteイベントを区別するために使われます -
active
— フラグ。イベントが、通常epoll, kqueue, pollのような通知機構からI/O通知を受け取るために登録されたことを意味します。 -
ready
— フラグ。イベントがI/O通知を受け取ったことを意味します。 -
delayed
— フラグ。I/Oがレートの制限により遅れたことを意味します。 -
timer
— イベントをタイマーツリーに挿入するための赤黒木 -
timer_set
— フラグ。イベントタイマーがセットされたがまだ期限切れではないことを意味します -
timedout
— フラグ。イベントタイマーが期限切れになったことを意味します -
eof
— readイベントフラグ。データの読み込み中にeofが発生したことを意味します -
pending_eof
— フラグ。たとえそれ以前に何らかのデータが利用可能だったかも知れないが、ソケット上でeofが起ころうとしていることを意味します。フラグはEPOLLRDHUP
epoll イベント、あるいはEV_EOF
kqueue フラグによって配送されます。 -
error
— フラグ。(readイベントに関して)読み込み中、あるいは(書き込みイベントに関して)書き込み中にエラーが起きたことを意味します -
cancelable
— タイマーイベントフラグ。イベントタイムアウトがまだ期限切れでない場合でも、nginxワーカーがgracefulシャットダウンする間にイベントハンドラが呼ばれなければならないことを意味します。フラグは、ある動き、例えばログファイルのフラッシュを終了させる方法を提供します -
posted
— フラグ、イベントがキューに投げられたことを意味します -
queue
— イベントをキューに投げるためにノードをキューに入れます
I/O イベント
ngx_get_connection()
呼び出しによって受け取られた各接続は、それに付随する二つのイベントを持ちます: c->read
と c->write
。これらのイベントは読み込みあるいは書き込みの準備ができたソケットについての通知を受け取るために使われます。全てのそのようなイベントはEdge-Triggeredモードで操作されます。ソケットの状態の変更時にそれらは通知を引き起こすことを意味します。例えば、ソケット上の部分的な読み込みの実施は、ソケットにもっと多くのデータが到着するまでnginxに繰り返しの読み込み通知を配送しないでしょう。背後で動くI/O通知機構が本質的に Level-Triggered (poll, select など)であった場合でも、nginxは通知を Edge-Triggered に変えるでしょう。To make nginx event notifications consistent across all notifications systems on different platforms, it's required, that the functions ngx_handle_read_event(rev, flags)
and ngx_handle_write_event(wev, lowat)
are called after handling an I/O socket notification or calling any I/O functions on that socket. 通常、これらの関数は各読み込みあるいは書き込みイベントハンドラの最後に一度だけ呼ばれます。
タイマー イベント
イベントはタイムアウトの期限切れを通知するために設定することができます。関数 ngx_add_timer(ev, timer)
はイベントのタイムアウトを設定し、ngx_del_timer(ev)
は以前に設定されたタイムアウトを削除します。現在のところ全ての既存のイベントに設定されたタイムアウトはグローバルタイムアウト 赤黒木 ngx_event_timer_rbtree
に保持されます。木でのキーは型ngx_msec_t
を持ち、イベントが期限切れになる1970年1月1日 (modulus ngx_msec_t
の最大値)からのミリ秒の時間です。木構造は高速な挿入と削除操作を提供し、もっとも近いタイムアウトへのアクセスを提供します。The latter is used by nginx to find out for how long to wait for I/O events and for expiring timeout events afterwards.
ポストされたイベント
イベントがポストされるかも知れません。ハンドルが現在のイベントループの繰り返しの中でどこかの時点の後で呼ばれるかも知れないという意味です。イベントのポストはコードを単純化しスタックオーバーフローを避けるための良い練習です。ポストされたイベントはポストキューの中に保持されます。マクロ ngx_post_event(ev, q)
はイベント ev
をポストキューq
にポストします。マクロ ngx_delete_posted_event(ev)
はイベント ev
を現在ポストされたどのようなキューからでも削除します。通常、イベントは ngx_posted_events
キューにポストされます。このキューはイベントループの中で、全てのI/Oおよびタイマーイベントがすでに処理された後で処理されます。関数 ngx_event_process_posted()
はイベントキューを処理するために呼ばれます。この関数はキューが空になるまでイベントハンドラを呼びます。このことは、ポストされたイベントハンドラは現在のイベントループの繰り返しの中で処理されるされるようにもっと多くのイベントをポストすることができることを意味します。
例:
void ngx_my_connection_read(ngx_connection_t *c) { ngx_event_t *rev; rev = c->read; ngx_add_timer(rev, 1000); rev->handler = ngx_my_read_handler; ngx_my_read(rev); } void ngx_my_read_handler(ngx_event_t *rev) { ssize_t n; ngx_connection_t *c; u_char buf[256]; if (rev->timedout) { /* timeout expired */ } c = rev->data; while (rev->ready) { n = c->recv(c, buf, sizeof(buf)); if (n == NGX_AGAIN) { break; } if (n == NGX_ERROR) { /* error */ } /* process buf */ } if (ngx_handle_read_event(rev, 0) != NGX_OK) { /* error */ } }
イベントループ
I/Oを行う全てのnginxプロセスはイベントループを持ちます。I/Oを持たないプロセスの唯一の型は、シグナルがやってくるのを待つsigsuspend()
呼び出しの中でほとんどの時間を過ごすnginxのマスタープロセスです。イベントループはngx_process_events_and_timers()
関数の中で実装されています。この関数はプロセスが終了するまで繰り返し呼ばれます。以下のステージを持ちます:
-
ngx_event_find_timer()
を呼ぶことで最も近いタイムアウトを見つけます。この関数は最も左のタイマーツリーのノードを見つけ、ノードが期限切れになるまでのミリ秒の数値を返します。 -
process I/O events by calling a handler, specific to event notification mechanism, chosen by nginx configuration. このハンドラは最も近いタイムアウトよりは長く無い間、少なくとも1回のI/Oイベントが起きるのを待ちます。起きた各読み込みあるいは書き込みイベントについて、
ready
フラグが設定されそのハンドラが呼ばれます。Linuxについては、通常、I/Oイベントを待つためにepoll_wait()
を呼び出すngx_epoll_process_events()
ハンドラが使われます。 -
ngx_event_expire_timers()
を呼び出すことでタイマーを期限切れにする。タイマーツリーはまだ期限切れになっていないタイムアウトが見つかるまで最も左の要素から右まで繰り返します。各期限切れのノードについては、timedout
イベントフラグが設定され、timer_set
がリセットされ、イベントハンドラが呼ばれます。 -
ngx_event_process_posted()
を呼び出すことでポストされたイベントを処理します。関数はポストされたイベントキューから最初の要素を繰り返し削除し、キューが空になるまでそのハンドラを呼びます。
全てのnginxプロセスもシグナルを処理します。シグナルハンドラは、ngx_process_events_and_timers()
呼び出しの後でチェックされるグローバル変数にのみ設定します。
プロセス
nginxには処理の幾つかのタイプがあります:現在のプロセスのタイプはngx_process
グローバル変数の中に保持されます:
-
NGX_PROCESS_MASTER
— マスタープロセスはngx_master_process_cycle()
関数を実行します。マスタープロセスはI/Oを持たず、シグナルにのみ応答します。設定を読み、サイクルを生成し、子プロセスを開始及び制御します。 -
NGX_PROCESS_WORKER
— ワーカープロセスはngx_worker_process_cycle()
関数を実行します。ワーカープロセスはマスターによって開始され、クライアント接続を処理します。それらはマスターから送られるシグナルとチャネルコマンドにも応答します。 -
NGX_PROCESS_SINGLE
— シグナルプロセスはmaster_process off
モードに存在する唯一のプロセスの型です。このプロセスのためのサイクル関数はngx_single_process_cycle()
です。このプロセスはサイクルを生成し、クライアント接続を処理します。 -
NGX_PROCESS_HELPER
— 現在のところ、二つの型のヘルパープロセスがあります: キャッシュマネージャーとキャッシュローダー。それらの両方とも同じサイクル関数ngx_cache_manager_process_cycle()
を共有します。
全てのnginxプロセスは以下のシグナルを処理します:
-
NGX_SHUTDOWN_SIGNAL
(SIGQUIT
) — graceful シャットダウン。このシグナルを受け取ると、マスタープロセスは全ての子プロセスにシャットダウンシグナルを送信します。子プロセスが無くなると、マスターはサイクルプールを破壊し、終了します。このシグナルを受け取ったワーカープロセスは、全てのlistenソケットを閉じ、タイムアウトツリーが空になるまで待ち、サイクルプールを破壊して終了します。キャッシュマネージャープロセスはこのシグナルを受け取るとすぐに終了します。変数ngx_quit
はこのシグナルを受け取った後で設定され、処理された後ですぐに再設定されます。変数ngx_exiting
はワーカープロセスがシャットダウン状態になると設定されます。 -
NGX_TERMINATE_SIGNAL
(SIGTERM
) - 終了します。このシグナルを受け取ると、マスタープロセスは全ての子プロセスに終了シグナルを送信します。子プロセスが1秒以内に終了しない場合、それらはSIGKILL
シグナルでkillされます。子プロセスが無くなると、マスタープロセスはサイクルプールを破壊し、終了します。このシグナルを受け取ったワーカーあるいはキャッシュマネージャープロセスはサイクルを破壊し終了します。変数ngx_terminate
はこのシグナルを受け取った後で設定されます。 -
NGX_NOACCEPT_SIGNAL
(SIGWINCH
) - ワーカープロセスをgracefullyにシャットダウンします。 -
NGX_RECONFIGURE_SIGNAL
(SIGHUP
) - 再設定します。このシグナルを受け取ると、マスタープロセスは設定ファイルから新しいサイクルを生成します。新しいサイクルの生成が成功すると、古いサイクルは削除され、新しい子プロセスが開始されます。一方で、古いプロセスはシャットダウンシグナルを受け取ります。シングルプロセスモードでは、nginxは同じく新しいサイクルを生成しますが、古いサイクルに紐付けられている全てのクライアントが終了するまで古いサイクルが維持されます。ワーカーとヘルパープロセスはこのシグナルを無視します -
NGX_REOPEN_SIGNAL
(SIGUSR1
) — ファイルを開きなおします。マスタープロセスはこのシグナルをワーカーに渡します。ワーカープロセスはサイクルから全てのopen_files
を開きなおします -
NGX_CHANGEBIN_SIGNAL
(SIGUSR2
) — nginxのバイナリを変更します。マスタープロセスは新しいnginxバイナリを開始し、全てのlistenソケットのリストをそれに渡します。リストは環境変数“NGINX”
にディスクリプタの数値がセミコロンで分割されたテキスト形式で渡されます。新しいnginxインスタンスは変数を読み込み、initサイクルにソケットを追加します。他のプロセスはこのシグナルを無視します
全てのnginxワーカープロセスはPOSIXのシグナルを受け取り適切に処理することができますが、マスタープロセスは通常どのようなシグナルも標準のkill()
syscollを持つワーカーやヘルパーに渡しません。代わりに、nginxは全てのnginxプロセス間でメッセージを送信することができる内部プロセスチャネルを使います。しかし、現在のところ、メッセージはマスターからその子プロセスにのみ送信されます。これらのメッセージは同じシグナルを伝搬することができます。チャネルは異なるプロセスに終端を持つソケットのペアです。
実行中のnginxバイナリの場合、-s
パラメータの次に幾つかの値を指定することができます。これらの値は、stop
, quit
, reopen
, reload
です。それらはシグナルNGX_TERMINATE_SIGNAL
, NGX_SHUTDOWN_SIGNAL
, NGX_REOPEN_SIGNAL
および NGX_RECONFIGURE_SIGNAL
に変換され、nginx pidファイルからpidを読み込んでnginxマスタープロセスに送信されます。
モジュール
新しいモジュールの追加
スタンドアローンのnginxモジュールは少なくとも以下の2つのファイルを含む別個のディレクトリ内にあります: config
とモジュールのソースと一緒のファイル最初のファイルはnginxがモジュールを統合するために必要な全ての情報を含みます。例えば:
ngx_module_type=CORE ngx_module_name=ngx_foo_module ngx_module_srcs="$ngx_addon_dir/ngx_foo_module.c" . auto/module ngx_addon_name=$ngx_module_name
ファイルはPOSIXのシェルスクリプトで以下の変数を設定(あるいはアクセス)することができます:
-
ngx_module_type
— ビルドするモジュールの型。利用可能なオプションは、CORE
,HTTP
,HTTP_FILTER
,HTTP_INIT_FILTER
,HTTP_AUX_FILTER
,MAIL
,STREAM
あるいはMISC
です -
ngx_module_name
— モジュール名。空白で区切られた値のリストが受け付けられ、1つのソースファイルのセットから複数のモジュールをビルドするために使うことができます。最初の名前は動的モジュールのための出力バイナリの名前を示します。このリスト内の名前はモジュール内で使われる名前に一致しなければなりません。 -
ngx_addon_name
— 設定スクリプトのコンソール出力テキスト内でのモジュールの名前を提供します。 -
ngx_module_srcs
— モジュールをコンパイルするために使われるソースファイルの空白区切りのリスト。モジュールソースのパスのためのプレースフォルダーとして、$ngx_addon_dir 変数を使うことができます。 -
ngx_module_incs
— モジュールをビルドするために必要なインクルードパス -
ngx_module_deps
— モジュールのヘッダファイルのリスト。 -
ngx_module_libs
— モジュールとリンクするライブラリのリスト。例えば、ngx_module_libs=-lpthread
を使って libpthread がリンクされるでしょう。The following macros can be used to link against the same libraries as nginx:LIBXSLT
,LIBGD
,GEOIP
,PCRE
,OPENSSL
,MD5
,SHA1
,ZLIB
, andPERL
-
ngx_module_link
— ビルドシステムによって動的モジュールについてはDYNAMIC
が、あるいは動的モジュールについてはADDON
が、リンク型に依存して異なるアクションを実施するために使われます。 -
ngx_module_order
—HTTP_FILTER
とHTTP_AUX_FILTER
モジュール型に便利なモジュールのためのロード順を設定します。順番は逆順で格納されます。ngx_http_copy_filter_module
はリストの一番下近くにあり、最初に実行されるものの一つです。これは他のフィルタのためにデータを読み込みます。リストの一番上近くには データを書き出すngx_http_write_filter_module
があり、そして最後に実行されるものの一つです。このオプションのための形式は、前に挿入するための空白区切りのモジュールのリストが続く現在のモジュール名で、従って後で実行します。モジュールは現在ロードするために見つけられるリスト内の最後のモジュールの前に挿入されるでしょう。
By default for filter modules this is set to “
ngx_http_copy_filter
” which will insert the module before the copy filter in the list and therefore will execute after the copy filter. デフォルトが空である他のモジュールの型について。
静的なコンパイルについては--add-module=/path/to/module
を、動的なコンパイルについては--add-dynamic-module=/path/to/module
を使って、設定スクリプトをによってnginxにモジュールを追加することができます。
コアモジュール
モジュールはnginxのブロックを構築し、その機能のほとんどはモジュールとして実装されます。モジュールのソースファイルは以下のように定義されるグローバル変数ngx_module_t
型を含まなければなりません:
struct ngx_module_s { /* private part is omitted */ void *ctx; ngx_command_t *commands; ngx_uint_t type; ngx_int_t (*init_master)(ngx_log_t *log); ngx_int_t (*init_module)(ngx_cycle_t *cycle); ngx_int_t (*init_process)(ngx_cycle_t *cycle); ngx_int_t (*init_thread)(ngx_cycle_t *cycle); void (*exit_thread)(ngx_cycle_t *cycle); void (*exit_process)(ngx_cycle_t *cycle); void (*exit_master)(ngx_cycle_t *cycle); /* stubs for future extensions are omitted */ };
省略されたprivate部分はモジュールのバージョン、シグネチャーを含み、事前定義されたマクロNGX_MODULE_V1
を使って埋められます。
各モジュールはprivateデータをctx
フィールドに保持し、特定の設定ディレクティブを理解し、commands
配列の中で指定され、nginxのライフサイクルの特定のステージで起動されるかも知れません。モジュールのライフサイクルは以下のイベントから成ります:
- 設定ディレクティブハンドラはマスタープロセスのコンテキスト中の設定ファイルの中で現れた時に呼ばれます。
-
init_module
ハンドラは設定のパースが成功した後でマスタープロセスのコンテキストの中で呼ばれます。 -
マスタープロセスはワーカープロセス(s)を生成し、それぞれの中で
init_process
ハンドラが呼ばれます。 -
ワーカープロセスがマスターからシャットダウンコマンドを受け取ると、それは
exit_process
ハンドラを起動します。 -
マスタープロセスは終了前に
exit_master
ハンドラを呼びます。
設定の再読み込みが要求された場合には、init_module
ハンドラがマスタープロセス内で複数回呼ばれるかも知れません。
init_master
, init_thread
および exit_thread
ハンドラは今のところ実装されていません; nginxでのスレッドは独自のAPIによって補助的なI/O機能としてのみ使われており、init_master
ハンドラは必要無いように思われます。
モジュールのtype
型はctx
フィールド内に何が保持されるかを正確に定義します。モジュールの型には幾つかあります:
NGX_CORE_MODULE
NGX_EVENT_MODULE
NGX_HTTP_MODULE
NGX_MAIL_MODULE
NGX_STREAM_MODULE
NGX_CORE_MODULE
は最も基本的で、従って最も一般的で最も低レベルのモジュールの型です。他のモジュール型はその上に実装され、イベントあるいはhttpリクエストの処理のような対応する問題ドメインを扱うための便利な方法を提供します。
コアモジュールの例は ngx_core_module
, ngx_errlog_module
, ngx_regex_module
, ngx_thread_pool_module
, ngx_openssl_module
モジュール、そしてもちろん http, stream, mail および イベントモジュール自身です。コアモジュールのコンテキストは以下のように定義されます:
typedef struct { ngx_str_t name; void *(*create_conf)(ngx_cycle_t *cycle); char *(*init_conf)(ngx_cycle_t *cycle, void *conf); } ngx_core_module_t;
ここで、name
は便利なようにモジュール名を持つ文字列で、create_conf
と init_conf
はそれぞれモジュールの設定を生成および初期化する関数へのポインタです。コアモジュールについては、nginxは新しい設定をパースする前にcreate_conf
を呼び、全ての設定のパースが成功した後で init_conf
を呼ぶでしょう。代表的な create_conf
関数は設定のためのメモリを割り当て、デフォルトの値を設定します。init_conf
は良く知られた設定を扱い、従って正常性チェックと徹底的な初期化をおこなうかも知れません。
例えば、極度に単純化されたngx_foo_module
は以下のように見えるかも知れません:
/* * Copyright (C) Author. */ #include <ngx_config.h> #include <ngx_core.h> typedef struct { ngx_flag_t enable; } ngx_foo_conf_t; static void *ngx_foo_create_conf(ngx_cycle_t *cycle); static char *ngx_foo_init_conf(ngx_cycle_t *cycle, void *conf); static char *ngx_foo_enable(ngx_conf_t *cf, void *post, void *data); static ngx_conf_post_t ngx_foo_enable_post = { ngx_foo_enable }; static ngx_command_t ngx_foo_commands[] = { { ngx_string("foo_enabled"), NGX_MAIN_CONF|NGX_DIRECT_CONF|NGX_CONF_FLAG, ngx_conf_set_flag_slot, 0, offsetof(ngx_foo_conf_t, enable), &ngx_foo_enable_post }, ngx_null_command }; static ngx_core_module_t ngx_foo_module_ctx = { ngx_string("foo"), ngx_foo_create_conf, ngx_foo_init_conf }; ngx_module_t ngx_foo_module = { NGX_MODULE_V1, &ngx_foo_module_ctx, /* module context */ ngx_foo_commands, /* module directives */ NGX_CORE_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ NULL, /* init process */ NULL, /* init thread */ NULL, /* exit thread */ NULL, /* exit process */ NULL, /* exit master */ NGX_MODULE_V1_PADDING }; static void * ngx_foo_create_conf(ngx_cycle_t *cycle) { ngx_foo_conf_t *fcf; fcf = ngx_pcalloc(cycle->pool, sizeof(ngx_foo_conf_t)); if (fcf == NULL) { return NULL; } fcf->enable = NGX_CONF_UNSET; return fcf; } static char * ngx_foo_init_conf(ngx_cycle_t *cycle, void *conf) { ngx_foo_conf_t *fcf = conf; ngx_conf_init_value(fcf->enable, 0); return NGX_CONF_OK; } static char * ngx_foo_enable(ngx_conf_t *cf, void *post, void *data) { ngx_flag_t *fp = data; if (*fp == 0) { return NGX_CONF_OK; } ngx_log_error(NGX_LOG_NOTICE, cf->log, 0, "Foo Module is enabled"); return NGX_CONF_OK; }
設定ディレクティブ
ngx_command_t
は1つの設定ディレクティブを記述します。設定をサポートする各モジュールは、引数をどうやって処理するか、どのハンドラを呼ぶかを記述する、そのような仕様の配列を提供します:
struct ngx_command_s { ngx_str_t name; ngx_uint_t type; char *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf); ngx_uint_t conf; ngx_uint_t offset; void *post; };
配列は特別な値 “ngx_null_command
” を使って終わらなければなりません。The name
is the literal name of a directive, as it appears in configuration file, for example “worker_processes
” or “listen
”. type
は対応するフラグを使った、引数の数、コマンド型、および他のプロパティを制御するビット列です。引数のフラグ:
-
NGX_CONF_NOARGS
— 引数無しのディレクティブ NGX_CONF_1MORE
— 1つの必須引数NGX_CONF_2MORE
— 2つの必須引数-
NGX_CONF_TAKE1..7
— 正確に、1..7 の引数 -
NGX_CONF_TAKE12, 13, 23, 123, 1234
— 1または2つの引数。あるいはそのほかの組み合わせ
ディレクティブ型:
-
NGX_CONF_BLOCK
— ディレクティブはブロックです。つまり、中括弧内に他のディレクティブを含むか、内部のコンテンツを処理するために独自のパーサを実装しさえするかも知れません。 -
NGX_CONF_FLAG
— ディレクティブの値は、“on
” あるいは “off
” 文字列によって真偽値を表すフラグです。
ディレクティブのコンテキストは設定のどこに現れるか、そして対応する値を格納するためにモジュールコンテキストにアクセスする方法を定義します。
-
NGX_MAIN_CONF
— トップレベルの設定 -
NGX_HTTP_MAIN_CONF
— httpブロック内 -
NGX_HTTP_SRV_CONF
— serverブロック内 -
NGX_HTTP_LOC_CONF
— http location内 -
NGX_HTTP_UPS_CONF
— http upstream ブロック内 -
NGX_HTTP_SIF_CONF
— http server の“if”内 -
NGX_HTTP_LIF_CONF
— http location の“if”内 -
NGX_HTTP_LMT_CONF
— http “limit_except”内 -
NGX_STREAM_MAIN_CONF
— streamブロック内 -
NGX_STREAM_SRV_CONF
— stream server ブロック内 -
NGX_STREAM_UPS_CONF
— stream upstream ブロック内 -
NGX_MAIL_MAIN_CONF
— mail ブロック内 -
NGX_MAIL_SRV_CONF
— mail server ブロック内 -
NGX_EVENT_CONF
— event ブロック内 -
NGX_DIRECT_CONF
— コンテキストの階層を生成しないモジュールで使われ、ctx内に直接モジュールの設定を格納します。
設定パーサは間違ったディレクティブの場合にエラーを投げるためにこのフラグを使用し、適切な設定ポインタによって提供されるディレクティブハンドラを呼び出します。そしやって、異なるlocation内の同じディレクティブが個々の場所でそれらの値を格納できるようにします。
set
フィールドはディレクティブを処理するハンドラを定義し、パースされた値を対応する設定に格納します。Nginxは共通の変換を行う便利な関数のセットを提供します:
-
ngx_conf_set_flag_slot
— 文字の “on
” あるいは “off
” 文字列を1 または0の値を持つngx_flag_t
型に変換します -
ngx_conf_set_str_slot
— 文字列をngx_str_t
型の値として格納します -
ngx_conf_set_str_array_slot
—ngx_str_t
のngx_array_t
を新しい値で追加します。配列がまだ存在しない場合は生成されます -
ngx_conf_set_keyval_slot
—ngx_keyval_t
のngx_array_t
を新しい値で追加します。キーは最初の文字列で値は2つ目の文字列です。配列がまだ存在しない場合は生成されます -
ngx_conf_set_num_slot
— ディレクティブの引数をngx_int_t
の値に変換します -
ngx_conf_set_size_slot
— size をsize_t
のバイトの値に変換します -
ngx_conf_set_off_slot
— offset をoff_t
のバイトの値に変換します -
ngx_conf_set_msec_slot
— time をngx_msec_t
のミリ秒の値に変換します -
ngx_conf_set_sec_slot
— time をtime_t
の秒の値に変換します -
ngx_conf_set_bufs_slot
— 二つの引数をngx_int_t
個のsize のバッファを保持するngx_bufs_t
に変換します -
ngx_conf_set_enum_slot
— 引数をngx_uint_t
の値に変換します。post
で渡されるnullで終了するngx_conf_enum_t
の配列は受付可能な文字列と対応する整数値を定義します -
ngx_conf_set_bitmask_slot
— arguments are converted tongx_uint_t
value and OR'ed with the resulting value, forming a bitmask.post
で渡されるnullで終了するngx_conf_bitmask_t
の配列は受付可能な文字列と対応するマスク値を定義します -
set_path_slot
— 引数をngx_path_t
型に変換し全ての必要とされる初期化を行います。詳細はproxy_temp_path ディレクティブの説明を見てください -
set_access_slot
— 引数をファイルパーミッションのマスクに変換します。詳細はproxy_store_access ディレクティブの説明を見てください
conf
フィールドはどのコンテキストがディレクティブの値を格納するために使われるかを定義します。コンテキストが使われない場合はゼロです。1つのコアモジュールだけがコンテキスト無しの設定を使用し、NGX_DIRECT_CONF
フラグを設定します。実際には、httpあるいはstreamのようなモジュールはpre-serverあるいはpre-location、あるいはもっと正確に“if
” ディレクティブあるいは何らかの制限の中に適用することができるようなもっと洗練された設定を必要とします。このモジュール内では、設定構造はもっと複雑です。それらが設定をどう管理するかについて理解するために対応するモジュールの説明を参照してください。
-
NGX_HTTP_MAIN_CONF_OFFSET
— http ブロックの設定 -
NGX_HTTP_SRV_CONF_OFFSET
— http server の設定 -
NGX_HTTP_LOC_CONF_OFFSET
— http location の設定 -
NGX_STREAM_MAIN_CONF_OFFSET
— stream block の設定 -
NGX_STREAM_SRV_CONF_OFFSET
— stream server の設定 -
NGX_MAIL_MAIN_CONF_OFFSET
— mail block の設定 -
NGX_MAIL_SRV_CONF_OFFSET
— mail server の設定
offset
はこの特定のディレクティブの値を保持するモジュール設定構造内のフィールドのオフセットを定義します。代表的な使い方はoffsetof()
マクロを使うことです。
post
は二つの部分からなるフィールドです: メインのハンドラが終了した後で呼ばれるか、あるいは追加のデータをメインのハンドラに渡すために使われるかも知れません。最初の場合には、ngx_conf_post_t
構造はハンドラへのポインタを使って初期化される必要があります。例えば:
static char *ngx_do_foo(ngx_conf_t *cf, void *post, void *data); static ngx_conf_post_t ngx_foo_post = { ngx_do_foo };
post
の引数はngx_conf_post_t
オブジェクト自身で、data
は値へのポインタで、適切な型を持つメインのハンドラによって引数から変換されます。
HTTP
接続
各クライアントのHTTP接続は以下のステージを通過します:
-
ngx_event_accept()
クライアントのTCP接続を受け付けます。このハンドラはlistenソケット上での通知の読み込みに応じて呼ばれます。新しいngx_connecton_t
オブジェクトはこのステージで生成されます。オブジェクトは新しく受け付けられたクライアントソケットをラップします。各nginxのlistenerは新しい接続オブジェクトを渡すためにハンドラを提供します。HTTP接続については、それはngx_http_init_connection(c)
です -
ngx_http_init_connection()
はHTTP接続の初期の初期化を実施します。このステージで、接続のためのngx_http_connection_t
オブジェクトが生成され、そのリファレンスが接続のdata
フィールド内に保持されます。後で、それはHTTPリクエストオブジェクトに置き換えられます。PROXY プロトコル パーサとSSLハンドシェイクもこのステージで開始されます。 -
ngx_http_wait_request_handler()
は読み込みイベントハンドラで、クライアントのソケットでデータが利用可能になると呼ばれます。このステージで、HTTPリクエストオブジェクトngx_http_request_t
が生成され、接続のdata
フィールドが設定されます。 -
ngx_http_process_request_line()
は読み込みイベントハンドラで、クライアントリクエストの行を読み込みます。ハンドラはngx_http_wait_request_handler()
によって設定されます。読み込みは接続のbuffer
に行われます。バッファのサイズは最初はディレクティブclient_header_buffer_sizeによって設定されます。クライアントヘッダの全体はバッファに収まると仮定されます。初期のサイズが十分では無い場合は、より大きなバッファが割り当てられます。サイズはlarge_client_header_buffers
ディレクティブによって設定されます。 -
ngx_http_process_request_headers()
は読み込みイベントハンドラで、クライアントリクエストヘッダを読み込むためにngx_http_process_request_line()
の後に設定されます。 -
ngx_http_core_run_phases()
はリクエストヘッダが完全に読み込みおよびパースされた時に呼ばれます。この関数はNGX_HTTP_POST_READ_PHASE
からNGX_HTTP_CONTENT_PHASE
までリクエストのフェーズを実行します。最後のフェーズは応答を生成し、それをフィルタチェーンによって渡すとされています。このフェーズでは応答はクライアントに送信される必要はありません。バッファされたままかも知れず、完了ステージで送信されるでしょう。 -
ngx_http_finalize_request()
は通常リクエストが全ての出力を生成あるいはエラーを生成した時に呼ばれます。後者では、適切なエラーページが調べられ、応答として使われます。もし応答がこの時点までに完全にクライアントに送信されていない場合は、出力データの送信を完了するためにHTTP書き込みngx_http_writer()
が起動されます。 -
応答がクライアントに完全に送信され、リクエストを破壊することができる場合は、
ngx_http_finalize_connection()
が呼ばれます。クライアント接続のkeepalive機能が有効な場合、ngx_http_set_keepalive()
が呼ばれます。それが現在のリクエストを破壊し、接続上の次のリクエストを待ちます。そうでなければ、ngx_http_close_request()
がリクエストと接続の両方を破壊します
リクエスト
各クライアントのHTTPリクエストに関して、ngx_http_request_t
オブジェクトが生成されます。このオブジェクトの幾つかのフィールド:
-
connection
—ngx_connection_t
クライアント接続オブジェクトへのポインタ幾つかのリクエストは同時に同じ接続オブジェクトを参照するかも知れません - 1つのメインのリクエストとそのサブリクエスト。リクエストが削除された後で、新しいリクエストが同じ接続上で生成されるかもしれません。Note that for HTTP connections
ngx_connection_t
'sdata
field points back to the request. Such request is called active, as opposed to the other requests tied with the connection. アクティブなリクエストはクライアント接続イベントを処理するために使われ、応答をクライアントに出力することができます。通常、各リクエストは出力を送信できるように同じ場所でアクティブになります。 -
ctx
— HTTPモジュールコンテキストの配列各モジュールの型NGX_HTTP_MODULE
はリクエスト内に任意の値(通常、構造へのポインタ)を保持することができます。値はモジュールのctx_index
の場所のctx
配列の中に格納されます。以下のマクロはリクエストコンテキストを取得および設定する便利な方法を提供します:-
ngx_http_get_module_ctx(r, module)
—module
のコンテキストを返す -
ngx_http_set_ctx(r, c, module)
—module
のコンテキストとしてc
を設定する
-
-
main_conf, srv_conf, loc_conf
— 現在のリクエスト設定の配列設定はモジュールのctx_index
の場所に格納されます -
read_event_handler
,write_event_handler
- リクエストのための読み込みおよび書き込みイベントハンドラ通常、HTTP接続は読み込みおよび書き込みの両方のイベントハンドラとして設定されたngx_http_request_handler()
を持ちます。この関数は現在有効なリクエストのread_event_handler
とwrite_event_handler
のハンドラを呼びます -
cache
— upstream応答をキャッシュするためのリクエストキャッシュオブジェクト -
upstream
— プロキシのためのリクエストupstreamオブジェクト -
pool
— リクエストプール。このプールはリクエストが削除される時に破壊されます。リクエストオブジェクト自身はこのプール内に割り当てられます。クライアント接続のライフタイムを通して利用可能でなければならない割り当てのために、ngx_connection_t
のプールが代わりに使われなければなりません -
header_in
— buffer where client HTTP request header in read -
headers_in, headers_out
— 入力および出力HTTPヘッダオブジェクト。両方のオブジェクトはヘッダの生リストを保持する型ngx_list_t
のheaders
フィールドを含みます。それに加えて、例えばcontent_length_n
,status
のような分離されたフィールドとして取得および設定のための特定のヘッダが利用可能です。 -
request_body
— クライアントのリクエストボディオブジェクト -
start_sec, start_msec
— リクエストが生成された時の時間ポイント。リクエストの持続時間を追跡するために使われます -
method, method_name
— クライアントHTTPリクエストメソッドの数値および文字表現。メソッドの数値はマクロNGX_HTTP_GET, NGX_HTTP_HEAD, NGX_HTTP_POST
などを使ってsrc/http/ngx_http_request.h
内で定義されます。 -
http_protocol, http_version, http_major, http_minor
- client HTTP protocol version in its original textual form (“HTTP/1.0”, “HTTP/1.1” etc), numeric form (NGX_HTTP_VERSION_10
,NGX_HTTP_VERSION_11
etc) and separate major and minor versions -
request_line, unparsed_uri
— クライアントの元のリクエスト行とURI -
uri, args, exten
— 現在のリクエストURI、引数およびファイル拡張子。ここでのURIの値は正規化のためクライアントによって送信された元のURIとは異なるかも知れません。リクエストの処理の間、これらの値は内部リダイレクトをする間に変更されるかも知れません -
main
— メインのリクエストオブジェクトへのポインタこのオブジェクトはメインのリクエスト内で特定のサブタスクを実施するために生成されるサブリクエストとは対照的に、クライアントのHTTPリクエストを処理するために生成されます。 -
parent
— サブリクエストの親リクエストへのポインタ -
postponed
— 出力バッファおよびサブリクエストの送信され生成された順のリスト。リストはリクエストの出力の一部がサブリクエストによって生成された時に、一貫したリクエストの出力を提供するために後段のフィルタで使われます。 -
post_subrequest
— サブリクエストが完了した時にコンテキストと一緒に呼ばれるハンドラへのポインタ。メインのリクエストに使われないもの -
posted_requests
— 開始または再開されるリクエストのリスト。開始あるいは再開はリクエストのwrite_event_handler
を呼ぶことで行われます。通常、このハンドラはリクエストのメイン関数を保持します。これは最初にリクエストフェーズを実行し、その後に出力を生成します。リクエストは通常
ngx_http_post_request(r, NULL)
の呼び出しによって投稿されます。それは常にメインのリクエストposted_requests
リストに投稿されます。関数ngx_http_run_posted_requests(c)
は通過した接続のアクティブなリクエストのメインのリクエストの中で投稿された全てのリクエストを実行します。この関数は全てのイベントハンドラの中で呼ばれる必要があります。これが新しい投稿のリクエストに繋がることがあります。通常、それはリクエストの読み込みあるいは書き込みハンドラを起動した後で常に呼ばれます -
phase_handler
— 現在のリクエストフェーズのインデックス -
ncaptures, captures, captures_data
— リクエストの最後のregexの合致によって生成されたregexのキャプチャ。リクエストの処理の間、regexが合致するかも知れない場所が多数あるかもしれません: mapの調査、SNIあるいはHTTPホストによるサーバ調査、rewrite, proxy_redirect など。調査によって生成されたキャプチャは上で述べられたフィールドに格納されます。フィールドncaptures
はキャプチャの数を、captures
は境界を、captures_data
は文字列を保持します。それらはregexが合致し、キャプチャを抽出するために使われるべきものです。それぞれの新しいregexがリクエストに一致した後で、キャプチャは新しい値を保持するために再設定されます -
count
— リクエストの参照カウンタ。フィールドはメインのリクエストについてのみ意味を持ちます。カウンタの増加は単純にr->main->count++
で行われます。カウンタを減少するにはngx_http_finalize_request(r, rc)
が呼ばれるべきです。サブリクエストの生成、あるいはリクエストボディの読み込み処理の実行は、カウンタを増加します。 -
subrequests
— 現在のサブリクエストの入れ子のレベル。各サブリクエストは親の入れ子レベルから1減ったものを持ちます。値が0になると、エラーが生成されます。メインのリクエストの値はNGX_HTTP_MAX_SUBREQUESTS
定数によって定義されます -
uri_changes
— number of URI changes left for the request. リクエストがURIを変更することがっできる回数の総数はNGX_HTTP_MAX_URI_CHANGES
定数によって制限されます。各変更に従って、値は0になるまで減ります。後者の場合は、エラーが生成されます。URIの変更と見なされるアクションは、rewrite、および通常あるいは名前付きのlocationへの内部リダイレクトです -
blocked
— リクエスト上で保持されるブロックの数。この値は非0の間、リクエストは中止することができません。現在のところ、この値はAIO操作(POSIX AIO とスレッド操作)の延期とアクティブキャッシュのロックによって増加されます -
buffered
— どのモジュールがリクエストによって生成された出力をバッファしているかを示すビットマスク。A number of filters can buffer output, for example sub_filter can buffer data due to a partial string match, copy filter can buffer data because of the lack of free output_buffers etc. この値が非0である限り、リクエストは終了されず、フラッシュを期待します -
header_only
— 出力がボディを必要としないことを示すフラグ。例えば、このフラグはHTTP HEADリクエストによって使われます -
keepalive
— クライアント接続のkeepaliveがサポートされるかを示すフラグ。値はHTTPバージョンと “Connection” ヘッダ値から継承されます -
header_sent
— 出力ヘッダがリクエストによって既に送信されたことを示すフラグ -
internal
— 現在のリクエストが内部的なものであることを示すフラグ。内部の状態に入るために、リクエストはリクエストが内部リダイレクトされるかサブリクエストである必要があります。内部リクエストは内部のlocationに入ることができます -
allow_ranges
— HTTP Rangeヘッダによってリクエストされた場合、部分的な応答がクライアントに送信できることを示すフラグ -
subrequest_ranges
— サブリクエストを処理している間、部分的な応答を送信することができることを示すフラグ -
single_range
— 出力データの1つの連続する範囲だけがクライアントに送信することができることを示すフラグ。このフラグは通常データのストリームが送信される時に設定されます。例えば、プロキシされるサーバから一度に全ての応答が利用可能でない場合 -
main_filter_need_in_memory, filter_need_in_memory
— 出力がメモリバッファ内でなくファイル内で生成されなければならないことを示すフラグ。これはsendfileが有効な場合でもファイルバッファからデータを読み込むためのcopyフィルタへのシグナルです。これら二つのフラグの違いは、それらを送信するフィルタモジュールの場所です。フィルタチェーン内のpostponeフィルタの前に呼ばれるフィルタは、現在のリクエストの出力だけがメモリバッファから来なければならないことを要求するfilter_need_in_memory
を設定します。フィルタチェーン内で後で呼ばれるフィルタは、出力の送信の間にメインのリクエストと全てのサブリクエストの両方がメモリ内のファイルを読み込むことを要求するmain_filter_need_in_memory
を設定します -
filter_need_temporary
— リクエストの出力がreadonlyメモリバッファあるいはfileバッファではなく、一時バッファ内で生成されなければならないことを示すフラグ。これは、送信される時に出力が直接バッファ内で変更されるかも知れないフィルタによって使われます
設定
各HTTPモジュールは3つの種類の設定を持つかも知れません:
- メインの設定。この設定はnginxのhttp{}ブロック全体に適用されます。これはグローバル設定です。モジュールのためのグローバル設定が格納されます
- サーバ設定。こお設定は1つのnginx server{}に適用されます。モジュールのサーバ固有の設定が格納されます
- location設定。この設定は1つの location{}, if{} あるいは limit_except() ブロックに適用されます。この設定はlocationに固有の設定を格納します
設定構造は関数の呼び出しによってnginx設定ステージで生成されます。これらの構造を割り当て、初期化し、そして合併します。以下の例は1つのモジュールの location 設定を生成する方法を示します。設定は1つのunsigned integer型のfoo
を持ちます。
typedef struct { ngx_uint_t foo; } ngx_http_foo_loc_conf_t; static ngx_http_module_t ngx_http_foo_module_ctx = { NULL, /* preconfiguration */ NULL, /* postconfiguration */ NULL, /* create main configuration */ NULL, /* init main configuration */ NULL, /* create server configuration */ NULL, /* merge server configuration */ ngx_http_foo_create_loc_conf, /* create location configuration */ ngx_http_foo_merge_loc_conf /* merge location configuration */ }; static void * ngx_http_foo_create_loc_conf(ngx_conf_t *cf) { ngx_http_foo_loc_conf_t *conf; conf = ngx_pcalloc(cf->pool, sizeof(ngx_http_foo_loc_conf_t)); if (conf == NULL) { return NULL; } conf->foo = NGX_CONF_UNSET_UINT; return conf; } static char * ngx_http_foo_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child) { ngx_http_foo_loc_conf_t *prev = parent; ngx_http_foo_loc_conf_t *conf = child; ngx_conf_merge_uint_value(conf->foo, prev->foo, 1); }
例にあるように、ngx_http_foo_create_loc_conf()
関数は新しい設定構造を生成し、ngx_http_foo_merge_loc_conf()
は設定を高レベルからの他の設定とマージします。実際、serverとlocation設定はserverとlocationレベルだけに存在するだけでなく、その上の全ての設定のためにも生成されます。特に、server設定はmainレベルに生成され、location設定はmain, server および location レベルのために生成されます。これらの設定によりnginx設定ファイルの任意のレベルでserverおよびlocation固有の設定を指定することができます。結果的に設定がマージされます。マージの間で消える設定と無視される設定を示すために、nginxはNGX_CONF_UNSET
およびNGX_CONF_UNSET_UINT
のような多くのマクロを提供します。ngx_conf_merge_value()
およびngx_conf_merge_uint_value()
のような標準のnginxマージ マクロ は、明示的な値で設定がされない場合に設定をマージしデフォルト値を設定する簡単な方法を提供します。異なる型のための完全なマクロのリストについては、src/core/ngx_conf_file.h
を見てください。
設定時の任意のHTTPモジュールの設定にアクセスするには、以下のマクロが利用可能です。それらは最初の引数としてngx_conf_t
の参照を受け取ります。
-
ngx_http_conf_get_module_main_conf(cf, module)
-
ngx_http_conf_get_module_srv_conf(cf, module)
-
ngx_http_conf_get_module_loc_conf(cf, module)
以下の例は標準nginxコアモジュール ngx_http_core_module のlocation設定へのポインタを取得し、構造の handler
フィールド内に保持されたlocationコンテントハンドラを変更します。
static ngx_int_t ngx_http_foo_handler(ngx_http_request_t *r); static ngx_command_t ngx_http_foo_commands[] = { { ngx_string("foo"), NGX_HTTP_LOC_CONF|NGX_CONF_NOARGS, ngx_http_foo, 0, 0, NULL }, ngx_null_command }; static char * ngx_http_foo(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { ngx_http_core_loc_conf_t *clcf; clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); clcf->handler = ngx_http_bar_handler; return NGX_CONF_OK; }
実行時には、以下のマクロがHTTPモジュールの設定を取得するために利用可能です。
-
ngx_http_get_module_main_conf(r, module)
-
ngx_http_get_module_srv_conf(r, module)
-
ngx_http_get_module_loc_conf(r, module)
これらのマクロはHTTPリクエスト ngx_http_request_t
へのリファレンスを受け取ります。リクエストのメインの設定は変更されません。server 設定は、リクエストのためのバーチャルサーバを選択した後で、デフォルトのものから変わるかもしれません。リクエストのlocation設定は、rewriteあるいは内部リダイレクトの結果として、複数回変更されるかも知れません。以下の例は実行時にHTTP設定へアクセスする方法を示します。
static ngx_int_t ngx_http_foo_handler(ngx_http_request_t *r) { ngx_http_foo_loc_conf_t *flcf; flcf = ngx_http_get_module_loc_conf(r, ngx_http_foo_module); ... }
フェーズ
各HTTPリクエストはHTTPフェーズのリストを通過します。各フェーズは特定の処理が得意です。ほとんどのフェーズはハンドラを差し込むことができます。フェーズハンドラは、いったんリクエストがフェーズに到達すると連続して呼ばれます。多くの標準のnginxモジュールが特定のリクエストの処理ステージで呼ばれる方法としてフェーズハンドラを差し込みます。以下はnginx HTTPフェーズのリストです。
-
NGX_HTTP_POST_READ_PHASE
は最も早いフェーズです。ngx_http_realip_module はこのフェーズにハンドラを差し込みます。これにより他のモジュールが起動される前にクライアントアドレスを置き換えることができます。 -
NGX_HTTP_SERVER_REWRITE_PHASE
はlocationブロックの外にあるserverレベルで定義され、rewriteスクリプトを実行するために使われます。ngx_http_rewrite_module はこのフェーズにハンドラを差し込みます。 -
NGX_HTTP_FIND_CONFIG_PHASE
— リクエストURIに基づいたlocationを選択するために使われる特別なフェーズ。このフェーズはハンドラを差し込むことができません。locationの選択のデフォルトのアクションのみを実施します。このフェーズの前に、serverのデフォルトのlocationがリクエストに割り当てられます。location設定を求める全てのモジュールはデフォルトのserver location 設定を受け取るでしょう。このフェーズの後で新しいlocationがリクエストに割り当てられます。 -
NGX_HTTP_REWRITE_PHASE
—NGX_HTTP_SERVER_REWRITE_PHASE
と似ていますが、以前のフェーズで選択された新しいlocationのためのものです。 -
NGX_HTTP_POST_REWRITE_PHASE
— URIがrewriteの間に変更された場合、リクエストを新しいlocationへリダイレクトするために使われる特別なフェーズ。リダイレクトはNGX_HTTP_FIND_CONFIG_PHASE
に戻ることによって行われます。このフェーズではハンドラは許可されません -
NGX_HTTP_PREACCESS_PHASE
— アクセスチェックに関係しない、ハンドラの異なる型のための共通のフェーズ。標準のnginxモジュールngx_http_limit_conn_module および ngx_http_limit_req_module はこのフェーズにハンドラを登録します -
NGX_HTTP_ACCESS_PHASE
— リクエストのためのアクセスパーミッションをチェックするために使われます。ngx_http_access_module および ngx_http_auth_basic_module のような標準のnginxモジュールはこのフェーズにハンドラを登録します。satisfy ディレクティブによってそのように設定された場合、アクセスフェーズのハンドラのうちの一つだけが処理を継続するためにリクエストへアクセスすることができます -
NGX_HTTP_POST_ACCESS_PHASE
— satisfy any の場合のための特別なフェーズ。If some access phase handlers denied the access and none of them allowed, the request is finalized. このフェーズではサポートされるハンドラはありません -
NGX_HTTP_TRY_FILES_PHASE
— try_files 機能のための特別なフェーズ。このフェーズではハンドラは許可されません -
NGX_HTTP_CONTENT_PHASE
— 応答が生成されると思われるフェーズ。例えば ngx_http_index_module あるいはngx_http_static_module
の複数のnginxの標準モジュールがこのフェーズにハンドラを登録します。それらのうちの一つが最終的に出力を生成するまで、これら全てのハンドラが連続して呼ばれます。locationごとにコンテントハンドラを設定することもできます。ngx_http_core_moduleのlocation設定がhandler
セットを持つ場合、このハンドラはコンテントハンドラとして呼ばれ、コンテントフェーズハンドラは無視されます -
NGX_HTTP_LOG_PHASE
はリクエストの記録を実施するために使われます。現在のところ ngx_http_log_module だけがアクセスログのためにこのステージでハンドラを登録します。ログフェーズハンドラはリクエスト処理のかなり最後の方で、リクエストを解放する直前に呼ばれます
以下はアクセス前のフェーズハンドラの例です。
static ngx_http_module_t ngx_http_foo_module_ctx = { NULL, /* preconfiguration */ ngx_http_foo_init, /* postconfiguration */ NULL, /* create main configuration */ NULL, /* init main configuration */ NULL, /* create server configuration */ NULL, /* merge server configuration */ NULL, /* create location configuration */ NULL /* merge location configuration */ }; static ngx_int_t ngx_http_foo_handler(ngx_http_request_t *r) { ngx_str_t *ua; ua = r->headers_in->user_agent; if (ua == NULL) { return NGX_DECLINED; } /* reject requests with "User-Agent: foo" */ if (ua->value.len == 3 && ngx_strncmp(ua->value.data, "foo", 3) == 0) { return NGX_HTTP_FORBIDDEN; } return NGX_DECLINED; } static ngx_int_t ngx_http_foo_init(ngx_conf_t *cf) { ngx_http_handler_pt *h; ngx_http_core_main_conf_t *cmcf; cmcf = ngx_http_conf_get_module_main_conf(cf, ngx_http_core_module); h = ngx_array_push(&cmcf->phases[NGX_HTTP_PREACCESS_PHASE].handlers); if (h == NULL) { return NGX_ERROR; } *h = ngx_http_foo_handler; return NGX_OK; }
フェーズハンドラは特定のコードを返すことを期待されます:
-
NGX_OK
— 次のフェーズに進みます -
NGX_DECLINED
— 現在のフェーズの次のハンドラに進みます。現在のハンドラが現在のフェーズの最後の場合、次のフェーズに進みます -
NGX_AGAIN, NGX_DONE
— 何らかの将来のイベントまでフェーズの処理を中断します。これは例えば非同期I/O操作あるいは単なる遅延になりえます。ngx_http_core_run_phases()
の呼び出しによってフェーズの処理が後で再開されることが期待されます - フェーズハンドラによって返される他のどのような値もリクエストの終了コード、特にHTTP応答コードとして扱われます。リクエストは与えられたコードで終了されます
幾つかのフェーズは戻りコードを少し異なった方法で扱います。コンテントフェーズでは、NGX_DECLINED
以外のどのようなコードも終了コードと見なされます。locationコンテントハンドラについては、それらからのどのような返り値も終了コードと見なされます。satisfy any モードのアクセスフェーズでは、NGX_OK, NGX_DECLINED, NGX_AGAIN, NGX_DONE
以外の戻りコードは拒否と見なされます。将来のアクセスハンドラのいずれもが新しいコードでアクセスあるいは拒否しない場合は、拒否コードが終了コードになるでしょう。
変数
既存の変数へのアクセス
変数はインデックス(これは最も一般的な方法です)あるいは名前(変数の生成については以下の章を見てください)を使って参照することができます。インデックスは変数が設定に追加される時に設定ステージで生成されます。変数のインデックスはngx_http_get_variable_index()
を使って取得することができます:
ngx_str_t name; /* ngx_string("foo") */ ngx_int_t index; index = ngx_http_get_variable_index(cf, &name);
ここで、cf
はnginxの設定へのポインタで、name
は変数名を持つ文字列へのポインタです。関数はエラー時にNGX_ERROR
を返すか、そうでなければ有効なインデックスを返します。これは一般的に後で使うためにモジュール内のどこかに格納されます。
全てのHTTP変数はHTTPリクエストのコンテキスト内で評価され、結果はHTTPリクエストに固有でその中にキャッシュされます。変数を評価する全ての関数はngx_http_variable_value_t
型を返し、変数の値を表します:
typedef ngx_variable_value_t ngx_http_variable_value_t; typedef struct { unsigned len:28; unsigned valid:1; unsigned no_cacheable:1; unsigned not_found:1; unsigned escape:1; u_char *data; } ngx_variable_value_t;
ここで:
-
len
— 値の長さ -
data
— 値そのもの -
valid
— 値が有効性 -
not_found
— 変数が見つからず、従ってdata
とlen
フィールドは無関係です; 例えば、対応する引数がリクエスト内で渡されなかった場合の$arg_foo
のような変数で起こるかも知れません -
no_cacheable
— 結果をキャッシュしません -
escape
— 値が出力でエスケープされる必要があると値にマークをするためにロギングモジュールによって内部的に使われます
ngx_http_get_flushed_variable()
と ngx_http_get_indexed_variable()
関数は変数の値を取得するために使われます。それらは同じインタフェースを持ちます - HTTP リクエスト r
を変数を評価するためのコンテキストとして受け取り、それを識別するためのindex
を受け取ります。一般的な使い方の例:
ngx_http_variable_value_t *v; v = ngx_http_get_flushed_variable(r, index); if (v == NULL || v->not_found) { /* we failed to get value or there is no such variable, handle it */ return NGX_ERROR; } /* some meaningful value is found */
関数間の違いはngx_http_get_indexed_variable()
はキャッシュされた値を返し、ngx_http_get_flushed_variable()
はキャッシュできない変数のためにキャッシュをフラッシュすることです。
例えばSSIあるいはPerlモジュールのように、設定時には名前が知られておらず従ってインデックスを使ってアクセスすることができない変数を扱う必要がある場合があります。ngx_http_get_variable(r, name, key)
関数はそのような場合に使われるかも知れません。指定されたname
とそのハッシュkey
を使ってvariable
を検索します
変数の作成
変数を作成するためにngx_http_add_variable()
関数が使われます。それは、挙動を制御する設定(ここで変数が登録されます)、変数名およびフラグを取ります:
NGX_HTTP_VAR_CHANGEABLE
— 変数を再定義することができます; もし他のモジュールがそのような名前の変数を定義する場合は、衝突は起きないでしょう。例えば、ユーザがsetディレクティブを使って変数を上書きすることができます。NGX_HTTP_VAR_NOCACHEABLE
— キャッシングを無効にします。$time_local
のような変数にとって便利ですNGX_HTTP_VAR_NOHASH
— この変数が名前ではなくインデックスによってのみアクセス可能であることを示します。これはSSIあるいはPerlのようなモジュール内で変数が必要とされないことが分かっている場合に、使われるかも知れない小さな最適化です。NGX_HTTP_VAR_PREFIX
— この変数の名前のプリフィックスです。ハンドラは特定の変数の値を取得するために余分なロジックを実装しなければなりません。例えば、リクエストの引数を検索し特定の引数の値を返す同じハンドラによって、全ての“arg_
” 変数が処理されます。
関数は、エラー時にはNULL、そうでなければngx_http_variable_t
へのポインタを返します:
struct ngx_http_variable_s { ngx_str_t name; ngx_http_set_variable_pt set_handler; ngx_http_get_variable_pt get_handler; uintptr_t data; ngx_uint_t flags; ngx_uint_t index; };
get
および set
ハンドラは変数値を取得あるいは設定するために呼ばれ、data
は変数ハンドラに渡され、index
変数を参照するために使われる割り当てられた可変のインデックスを持つでしょう。
通常、そのような構造おnullで終わる静的な配列はモジュールによって生成され、変数を設定に追加するために事前設定のステージで処理されます:
static ngx_http_variable_t ngx_http_foo_vars[] = { { ngx_string("foo_v1"), NULL, ngx_http_foo_v1_variable, NULL, 0, 0 }, { ngx_null_string, NULL, NULL, 0, 0, 0 } }; static ngx_int_t ngx_http_foo_add_variables(ngx_conf_t *cf) { ngx_http_variable_t *var, *v; for (v = ngx_http_foo_vars; v->name.len; v++) { var = ngx_http_add_variable(cf, &v->name, v->flags); if (var == NULL) { return NGX_ERROR; } var->get_handler = v->get_handler; var->data = v->data; } return NGX_OK; }
この関数はHTTPモジュールのコンテキストのpreconfiguration
フィールドを初期化するために使われ、HTTP設定をパースする前に呼ばれます。つまり、それはこれらの変数を参照することができます。
get
ハンドラは特定のリクエストのコンテキストの中で変数を評価する責任があります。例えば:
static ngx_int_t ngx_http_variable_connection(ngx_http_request_t *r, ngx_http_variable_value_t *v, uintptr_t data) { u_char *p; p = ngx_pnalloc(r->pool, NGX_ATOMIC_T_LEN); if (p == NULL) { return NGX_ERROR; } v->len = ngx_sprintf(p, "%uA", r->connection->number) - p; v->valid = 1; v->no_cacheable = 0; v->not_found = 0; v->data = p; return NGX_OK; }
内部エラー(例えば、メモリ割り当ての失敗)の場合はNGX_ERROR
を返し、そうでなければNGX_OK
を返します。変数の評価の状態はngx_http_variable_value_t
(上の説明を見てください)のフラグの精査によって理解されるかも知れません。
set
ハンドラによって変数によるプロパティの参照を設定することができます。例えば、$limit_rate
変数の設定ハンドラはリクエストの limit_rate
フィールドを修正します:
... { ngx_string("limit_rate"), ngx_http_variable_request_set_size, ngx_http_variable_request_get_size, offsetof(ngx_http_request_t, limit_rate), NGX_HTTP_VAR_CHANGEABLE|NGX_HTTP_VAR_NOCACHEABLE, 0 }, ... static void ngx_http_variable_request_set_size(ngx_http_request_t *r, ngx_http_variable_value_t *v, uintptr_t data) { ssize_t s, *sp; ngx_str_t val; val.len = v->len; val.data = v->data; s = ngx_parse_size(&val); if (s == NGX_ERROR) { ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "invalid size \"%V\"", &val); return; } sp = (ssize_t *) ((char *) r + data); *sp = s; return; }
comoplex値
複雑な値という名前にも関わらず、それはテキスト、変数およびそれらの組み合わせを含む表現の評価を簡単にする方法を提供します。
ngx_http_compile_complex_value
内のcomplex値の概要は設定ステージにおいて、評価された表現の結果を取得するために実行時に使われるngx_http_complex_value_t
へコンパイルされます。
ngx_str_t *value; ngx_http_complex_value_t cv; ngx_http_compile_complex_value_t ccv; value = cf->args->elts; /* directive arguments */ ngx_memzero(&ccv, sizeof(ngx_http_compile_complex_value_t)); ccv.cf = cf; ccv.value = &value[1]; ccv.complex_value = &cv; ccv.zero = 1; ccv.conf_prefix = 1; if (ngx_http_compile_complex_value(&ccv) != NGX_OK) { return NGX_CONF_ERROR; }
ここで、ccv
はcomplex値 cv
を初期化することを必要とする全てのパラメータを保持します:
-
cf
— 設定ポインタ -
value
— パースする文字列(入力) -
complex_value
— コンパイルされた値(出力) -
zero
— 0で終了する値を有効にするフラグ -
conf_prefix
— prefixes result with configuration prefix (the directory where nginx is currently looking for configuration) -
root_prefix
— prefixes result with root prefix (this is the normal nginx installation prefix)
ゼロで終了する文字列を必要とするライブラリに結果が渡される場合はzero
フラグが利用可能です。ファイル名を扱う場合にはプリフィックスが便利です。
Upon successful compilation, cv.lengths
may
be inspected to get information about the presence of variables
in the expression.
The NULL value means that the expression contained static text only,
and there is no need in storing it as a complex value,
so a simple string can be used.
ngx_http_set_complex_value_slot()
はディレクティブ定義の中でcomplex値を完全に正しく初期化するために使われる便利な関数です。
実行時には、complex値はngx_http_complex_value()
関数を使って計算されるかも知れません:
ngx_str_t res; if (ngx_http_complex_value(r, &cv, &res) != NGX_OK) { return NGX_ERROR; }
Given the request r
and previously compiled
value cv
the function will evaluate
expression and put result into res
.
応答
nginxでのHTTP応答は、任意の応答ボディが続く応答ヘッダを送信することで生成されます。ヘッダとボディの両方はフィルタチェインを通過し、結果的にクライアントのソケットに書き込まれます。nginxモジュールはハンドラをヘッダあるいはボディフィルタに差し込み、以前のハンドラからの出力を処理することができます。
応答ヘッダ
出力ヘッダは関数ngx_http_send_header(r)
によって送信されます。この関数の呼び出しの前に、r->headers_out
はHTTP応答ヘッダを生成するために必要な全てのデータを含める必要があります。常にr->headers_out
のstatus
フィールドを設定することが必要とされます。もし応答ステータスがヘッダに続く応答ボディを暗示する場合、content_length_n
も同様に設定することができます。このフィールドのデフォルトの値は-1です。このことはボディサイズが未知であることを意味します。この場合、chunked transfer encoding が使われます。任意のヘッダを出力するには、headers
リストが追加されなければなりません。
static ngx_int_t ngx_http_foo_content_handler(ngx_http_request_t *r) { ngx_int_t rc; ngx_table_elt_t *h; /* send header */ r->headers_out.status = NGX_HTTP_OK; r->headers_out.content_length_n = 3; /* X-Foo: foo */ h = ngx_list_push(&r->headers_out.headers); if (h == NULL) { return NGX_ERROR; } h->hash = 1; ngx_str_set(&h->key, "X-Foo"); ngx_str_set(&h->value, "foo"); rc = ngx_http_send_header(r); if (rc == NGX_ERROR || rc > NGX_OK || r->header_only) { return rc; } /* send body */ ... }
ヘッダフィルタ
ngx_http_send_header(r)
関数はトップヘッダフィルタハンドラngx_http_top_header_filter
を呼び出すことでヘッダフィルタチェーンを起動します。最後のハンドラngx_http_header_filter(r)
が呼ばれるまで、各ヘッダハンドラがチェーン内の次のハンドラを呼ぶと仮定します。最後のヘッダハンドラはr->headers_out
に基づいたHTTP応答を構築し、それを出力のためにngx_http_writer_filter
に渡します。
ヘッダフィルタチェーンにハンドラを追加するには、そのアドレスを設定時にngx_http_top_header_filter
グローバル変数に格納する必要があります。前のハンドラのアドレスは通常モジュールの静的変数に格納され、終了する前に新しく追加されたハンドラによって呼ばれます。
以下は、HTTPヘッダ "X-Foo: foo" をステータス200で各出力に追加するヘッダフィルタモジュールの例です。
#include <ngx_config.h> #include <ngx_core.h> #include <ngx_http.h> static ngx_int_t ngx_http_foo_header_filter(ngx_http_request_t *r); static ngx_int_t ngx_http_foo_header_filter_init(ngx_conf_t *cf); static ngx_http_module_t ngx_http_foo_header_filter_module_ctx = { NULL, /* preconfiguration */ ngx_http_foo_header_filter_init, /* postconfiguration */ NULL, /* create main configuration */ NULL, /* init main configuration */ NULL, /* create server configuration */ NULL, /* merge server configuration */ NULL, /* create location configuration */ NULL /* merge location configuration */ }; ngx_module_t ngx_http_foo_header_filter_module = { NGX_MODULE_V1, &ngx_http_foo_header_filter_module_ctx, /* module context */ NULL, /* module directives */ NGX_HTTP_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ NULL, /* init process */ NULL, /* init thread */ NULL, /* exit thread */ NULL, /* exit process */ NULL, /* exit master */ NGX_MODULE_V1_PADDING }; static ngx_http_output_header_filter_pt ngx_http_next_header_filter; static ngx_int_t ngx_http_foo_header_filter(ngx_http_request_t *r) { ngx_table_elt_t *h; /* * The filter handler adds "X-Foo: foo" header * to every HTTP 200 response */ if (r->headers_out.status != NGX_HTTP_OK) { return ngx_http_next_header_filter(r); } h = ngx_list_push(&r->headers_out.headers); if (h == NULL) { return NGX_ERROR; } h->hash = 1; ngx_str_set(&h->key, "X-Foo"); ngx_str_set(&h->value, "foo"); return ngx_http_next_header_filter(r); } static ngx_int_t ngx_http_foo_header_filter_init(ngx_conf_t *cf) { ngx_http_next_header_filter = ngx_http_top_header_filter; ngx_http_top_header_filter = ngx_http_foo_header_filter; return NGX_OK; }
応答ボディ
応答ボディは関数 ngx_http_output_filter(r, cl)
の呼び出しによって送信されます。関数は複数回呼び出すことができます。各回でバッファチェーンとして渡された応答ボディの部分を送信します。最後のボディバッファはlast_buf
フラグ セットを持つ必要があります。
以下の例はボディとして "foo" を持つ完全なHTTP出力を生成します。例がメインのリクエストとしてだけでなくサブリクエストとしても動作するために、出力の最後のバッファにlast_in_chain_flag
が設定されます。最後のバッファは出力全体の最後では無いので、last_buf
フラグはメインのリクエストのためだけに設定されます。
static ngx_int_t ngx_http_bar_content_handler(ngx_http_request_t *r) { ngx_int_t rc; ngx_buf_t *b; ngx_chain_t out; /* send header */ r->headers_out.status = NGX_HTTP_OK; r->headers_out.content_length_n = 3; rc = ngx_http_send_header(r); if (rc == NGX_ERROR || rc > NGX_OK || r->header_only) { return rc; } /* send body */ b = ngx_calloc_buf(r->pool); if (b == NULL) { return NGX_ERROR; } b->last_buf = (r == r->main) ? 1: 0; b->last_in_chain = 1; b->memory = 1; b->pos = (u_char *) "foo"; b->last = b->pos + 3; out.buf = b; out.next = NULL; return ngx_http_output_filter(r, &out); }
ボディ フィルタ
関数 ngx_http_output_filter(r, cl)
はトップのボディフィルタハンドラを呼び出すことでボディフィルタを起動します。最後のハンドラngx_http_write_filter(r, cl)
が呼ばれるまで、各ボディハンドラがチェーン内の次のハンドラを呼ぶと仮定します。
ボディフィルタハンドラはバッファのチェーンを受け取ります。ハンドラはバッファを処理し、できる限り新しいチェーンを次のハンドラに渡すとされています。It's worth noting that the chain links ngx_chain_t
of the incoming chain belong to the caller. それらは再利用されたり変更されたりすべきではありません。ハンドラが完了するとすぐに、呼び出し元はそれを送信したバッファの追跡を続けるために出力チェーンのリンクを使うことができます。更に送信する前に、バッファチェーンの保存あるいは幾つかのバッファの置き換えをするために、ハンドラは自身のチェーンリンクを割り当てる必要があります。
以下はボディのバイト数をカウントする簡単なボディフィルタの例です。結果はアクセスログ内で使うことができる $counter
変数として利用可能です。
#include <ngx_config.h> #include <ngx_core.h> #include <ngx_http.h> typedef struct { off_t count; } ngx_http_counter_filter_ctx_t; static ngx_int_t ngx_http_counter_body_filter(ngx_http_request_t *r, ngx_chain_t *in); static ngx_int_t ngx_http_counter_variable(ngx_http_request_t *r, ngx_http_variable_value_t *v, uintptr_t data); static ngx_int_t ngx_http_counter_add_variables(ngx_conf_t *cf); static ngx_int_t ngx_http_counter_filter_init(ngx_conf_t *cf); static ngx_http_module_t ngx_http_counter_filter_module_ctx = { ngx_http_counter_add_variables, /* preconfiguration */ ngx_http_counter_filter_init, /* postconfiguration */ NULL, /* create main configuration */ NULL, /* init main configuration */ NULL, /* create server configuration */ NULL, /* merge server configuration */ NULL, /* create location configuration */ NULL /* merge location configuration */ }; ngx_module_t ngx_http_counter_filter_module = { NGX_MODULE_V1, &ngx_http_counter_filter_module_ctx, /* module context */ NULL, /* module directives */ NGX_HTTP_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ NULL, /* init process */ NULL, /* init thread */ NULL, /* exit thread */ NULL, /* exit process */ NULL, /* exit master */ NGX_MODULE_V1_PADDING }; static ngx_http_output_body_filter_pt ngx_http_next_body_filter; static ngx_str_t ngx_http_counter_name = ngx_string("counter"); static ngx_int_t ngx_http_counter_body_filter(ngx_http_request_t *r, ngx_chain_t *in) { ngx_chain_t *cl; ngx_http_counter_filter_ctx_t *ctx; ctx = ngx_http_get_module_ctx(r, ngx_http_counter_filter_module); if (ctx == NULL) { ctx = ngx_pcalloc(r->pool, sizeof(ngx_http_counter_filter_ctx_t)); if (ctx == NULL) { return NGX_ERROR; } ngx_http_set_ctx(r, ctx, ngx_http_counter_filter_module); } for (cl = in; cl; cl = cl->next) { ctx->count += ngx_buf_size(cl->buf); } return ngx_http_next_body_filter(r, in); } static ngx_int_t ngx_http_counter_variable(ngx_http_request_t *r, ngx_http_variable_value_t *v, uintptr_t data) { u_char *p; ngx_http_counter_filter_ctx_t *ctx; ctx = ngx_http_get_module_ctx(r, ngx_http_counter_filter_module); if (ctx == NULL) { v->not_found = 1; return NGX_OK; } p = ngx_pnalloc(r->pool, NGX_OFF_T_LEN); if (p == NULL) { return NGX_ERROR; } v->data = p; v->len = ngx_sprintf(p, "%O", ctx->count) - p; v->valid = 1; v->no_cacheable = 0; v->not_found = 0; return NGX_OK; } static ngx_int_t ngx_http_counter_add_variables(ngx_conf_t *cf) { ngx_http_variable_t *var; var = ngx_http_add_variable(cf, &ngx_http_counter_name, 0); if (var == NULL) { return NGX_ERROR; } var->get_handler = ngx_http_counter_variable; return NGX_OK; } static ngx_int_t ngx_http_counter_filter_init(ngx_conf_t *cf) { ngx_http_next_body_filter = ngx_http_top_body_filter; ngx_http_top_body_filter = ngx_http_counter_body_filter; return NGX_OK; }
フィルタモジュールのビルド
ボディあるいはヘッダフィルタを書く時に、フィルタの順番に特に注意が必要です。nginxの標準モジュールによって登録された多くのヘッダとボディフィルタがあります。他のフィルタを考慮して正しい場所にフィルタモジュールを登録することが重要です。通常、フィルタは事前設定ハンドラの中でモジュールによって登録されます。フィルタが呼ばれる順番は、当然それらが登録された時の逆順です。
サードパーティフィルタモジュールのための特別なスロット HTTP_AUX_FILTER_MODULES
がnginxによって提供されます。スロット内でフィルタモジュールを登録するために、モジュールの設定の中で ngx_module_type
変数が HTTP_AUX_FILTER
の値に設定されるべきです。
以下の例は、たった一つのソースファイル ngx_http_foo_filter_module.c
を持つと仮定するフィルタモジュールの設定ファイルを示します。
ngx_module_type=HTTP_AUX_FILTER ngx_module_name=ngx_http_foo_filter_module ngx_module_srcs="$ngx_addon_dir/ngx_http_foo_filter_module.c" . auto/module
バッファの再利用
バッファのストリームを発行あるいは変更する時、割り当てられたバッファを再利用することがしばしば望ましいです。nginxのコードの中で広範囲に適用される標準的なやり方は、この目的のために二つのバッファのチェーンを保持します: free
と busy
. free
チェーンは全てのフリーなバッファを保持します。これらのバッファは再利用することができます。busy
チェーンは幾つかの他のフィルタハンドラによってまだ使われている現在のモジュールによって送信される全てのバッファを保持します。もしサイズが0より大きければ、バッファは使用中だと見なされます。通常、バッファがフィルタによって消費された場合、そのpos
(あるいはファイルバッファについては file_pos
) は last
(ファイルバッファについてはfile_last
)に進みます。いったんバッファが完全に消費されると、再利用することができます。free
チェーンを新しくfreeにされたバッファを使って更新するには、busy
チェーンの一番上でサイズが0のバッファをfree
に移動するのを繰り返すことで十分です。この操作は一般的で、これを行う特別な関数ngx_chain_update_chains(free, busy, out, tag)
があります。関数は出力チェーンout
を busy
に追加し、freeなバッファをbusy
の一番上から free
に移動します。指定されたtag
を持つバッファだけが再利用されます。これはモジュールによって割り当てられたバッファだけがモジュールによって再利用されます。
以下の例は各入力のバッファの前に “foo” 文字列を挿入するボディフィルタの例です。モジュールによって割り当てられた新しいバッファは可能であれば再利用されます。この例を適切に動作させるには、ヘッダフィルタを設定しcontent_length_n
を -1 に再設定することも必要なことに注意してください。これはこの章の範囲を超えます。
typedef struct { ngx_chain_t *free; ngx_chain_t *busy; } ngx_http_foo_filter_ctx_t; ngx_int_t ngx_http_foo_body_filter(ngx_http_request_t *r, ngx_chain_t *in) { ngx_int_t rc; ngx_buf_t *b; ngx_chain_t *cl, *tl, *out, **ll; ngx_http_foo_filter_ctx_t *ctx; ctx = ngx_http_get_module_ctx(r, ngx_http_foo_filter_module); if (ctx == NULL) { ctx = ngx_pcalloc(r->pool, sizeof(ngx_http_foo_filter_ctx_t)); if (ctx == NULL) { return NGX_ERROR; } ngx_http_set_ctx(r, ctx, ngx_http_foo_filter_module); } /* create a new chain "out" from "in" with all the changes */ ll = &out; for (cl = in; cl; cl = cl->next) { /* append "foo" in a reused buffer if possible */ tl = ngx_chain_get_free_buf(r->pool, &ctx->free); if (tl == NULL) { return NGX_ERROR; } b = tl->buf; b->tag = (ngx_buf_tag_t) &ngx_http_foo_filter_module; b->memory = 1; b->pos = (u_char *) "foo"; b->last = b->pos + 3; *ll = tl; ll = &tl->next; /* append the next incoming buffer */ tl = ngx_alloc_chain_link(r->pool); if (tl == NULL) { return NGX_ERROR; } tl->buf = cl->buf; *ll = tl; ll = &tl->next; } *ll = NULL; /* send the new chain */ rc = ngx_http_next_body_filter(r, out); /* update "busy" and "free" chains for reuse */ ngx_chain_update_chains(r->pool, &ctx->free, &ctx->busy, &out, (ngx_buf_tag_t) &ngx_http_foo_filter_module); return rc; }
ロードバランシング
ngx_http_upstream_module はリクエストをリモートサーバに渡す基本的な機能を提供します。この機能はHTTPあるいはFastCGIのような特定のプロトコルを実装するモジュールによって使われます。モジュールは独自のロードバランシングモジュールを作成するためのインタフェースも提供し、デフォルトのラウンドロビンバランシングメソッドを実装します。
別のロードバランシングメソッドを実装するモジュールの例は、least_conn と hash です。これらのモジュールは実際にはupstreamモジュールの拡張として実装されており、serverグループの表現のような多くのコードを共有することに注意してください。keepalive モジュールはupstream機能を拡張し、依存しないモジュールの例です。
The ngx_http_upstream_module may be configured explicitly by placing the corresponding upstream block into the configuration file, or implicitly by using directives that accept a URL evaluated at some point to the list of servers, for example, proxy_pass. 明示的な設定だけが代替のロードバランシングメソッドを使うかも知れません。upstreamモジュールの設定は独自のディレクティブコンテキスト NGX_HTTP_UPS_CONF
を持ちます。その構造は以下のように定義されます:
struct ngx_http_upstream_srv_conf_s { ngx_http_upstream_peer_t peer; void **srv_conf; ngx_array_t *servers; /* ngx_http_upstream_server_t */ ngx_uint_t flags; ngx_str_t host; u_char *file_name; ngx_uint_t line; in_port_t port; ngx_uint_t no_port; /* unsigned no_port:1 */ #if (NGX_HTTP_UPSTREAM_ZONE) ngx_shm_zone_t *shm_zone; #endif };
-
srv_conf
— configuration context of upstream modules -
servers
—upstream
ブロック内のserverディレクティブの配列をパースした結果である、ngx_http_upstream_server_t
の配列 -
flags
— 特定のロードバランシングメソッドによって主にどの機能(server ディレクティブのパラメータとして設定)がサポートされるかをマークするスラグ。-
NGX_HTTP_UPSTREAM_CREATE
— 明示的に定義されたupstreamをproxy_pass と “friends” (FastCGI, SCGI など)によって自動的に生成されたものから区別するために使われます -
NGX_HTTP_UPSTREAM_WEIGHT
— “weight
” がサポートされます -
NGX_HTTP_UPSTREAM_MAX_FAILS
— “max_fails
” がサポートされます -
NGX_HTTP_UPSTREAM_FAIL_TIMEOUT
— “fail_timeout
” がサポートされます -
NGX_HTTP_UPSTREAM_DOWN
— “down
” がサポートされます -
NGX_HTTP_UPSTREAM_BACKUP
— “backup
” がサポートされます -
NGX_HTTP_UPSTREAM_MAX_CONNS
— “max_conns
” がサポートされます
-
-
host
— upstreamの名前 -
file_name, line
— 設定ファイルの名前とupstream
ブロックが置かれている行 -
port
とno_port
— 明示的なupstreamでは使われません -
shm_zone
— もしあれば、このupstreamによって使われる共有メモリゾーン -
peer
— upstream設定の初期化のための一般的なメソッドを保持するオブジェクト:
ロードバランシングアルゴリズムを実装するモジュールは、これらのメソッドを設定しprivatetypedef struct { ngx_http_upstream_init_pt init_upstream; ngx_http_upstream_init_peer_pt init; void *data; } ngx_http_upstream_peer_t;
data
を初期化しなければなりません。もしinit_upstream
が設定のパースの間に初期化されなかった場合は、ngx_http_upstream_module
はそれをデフォルトのngx_http_upstream_init_round_robin
に設定します。-
init_upstream(cf, us)
— 成功時には、サーバのグループの初期化とinit()
メソッドの初期化に責任がある設定時のメソッド。代表的なロードバランシングモジュールは、独自の設定をdata
フィールドに保持し使用する幾つかの有効なデータ構造を作成するために、upstreamブロック内のサーバのリストを利用します。 -
init(r, us)
— ロードバランシングのために使われるリクエストあたりのngx_http_upstream_peer_t.peer
(上で説明したupstreamあたりのngx_http_upstream_srv_conf_t.peer
と混同しないでください) 構造を初期化します。data
引数としてサーバ選択を扱う全てのコールバックに渡されるでしょう。
-
nginxがリクエストを処理のために他のホストに渡す必要がある場合は、接続先のアドレスを取得するために設定されたロードバランシングメソッドを使います。メソッドは型ngx_peer_connection_t
のngx_http_upstream_peer_t.peer
オブジェクトから取り出されます:
struct ngx_peer_connection_s { [...] struct sockaddr *sockaddr; socklen_t socklen; ngx_str_t *name; ngx_uint_t tries; ngx_event_get_peer_pt get; ngx_event_free_peer_pt free; ngx_event_notify_peer_pt notify; void *data; #if (NGX_SSL || NGX_COMPAT) ngx_event_set_peer_session_pt set_session; ngx_event_save_peer_session_pt save_session; #endif [..] };
構造は以下のフィールドを持ちます:
-
sockaddr
,socklen
,name
— 接続先のupstreamサーバのアドレス; これはロードバランシングメソッドの出力パラメータです -
data
— リクエストあたりのロードバランシングメソッドのデータ; 選択アルゴリズムの状態を保持し、通常はupstream設定へのリンクを含みます。引数としてサーバ選択を扱う全てのメソッドへ渡されるでしょう(以下を見てください) -
tries
— upstreamへ接続できる試行の数。 -
get
,free
,notify
,set_session
およびsave_session
- ロードバランシングモジュールのメソッド。以下の説明を見てください
全てのメソッドは少なくとも二つの引数を受け付けます; ngx_http_upstream_srv_conf_t.peer.init()
によって生成された peer接続オブジェクト pc
と data
。ロードバランシングモジュールの“chaining”のため、一般的にはpc.data
とは異なることに注意してください。
-
get(pc, data)
— メソッドは、upstreamモジュールがリクエストをupstreamサーバに渡す準備ができ、そのアドレスを知る必要がある時に呼ばれます。メソッドはngx_peer_connection_t
構造のsockaddr
,socklen
およびname
フィールドを提供する責任があります。返り値は以下のうちの一つです:-
NGX_OK
— サーバが選択された -
NGX_ERROR
— 内部エラーが発生した -
NGX_BUSY
— 現時点で利用可能なサーバが無いこれは以下のような多くの理由で起こり得ます: 動的なサーバグループが空、グループ内の全てのサーバが失敗状態にある、グループ内の全てのサーバが接続の最大数を既に扱っている、など。 -
NGX_DONE
— これは背後にある接続が再利用され、upstreamサーバへの新しい接続を作成する必要が無いことを示すためにkeepalive
モジュールによって設定されます。
-
-
free(pc, data, state)
— upstreamモジュールが特定のサーバを使った作業が完了したした時にメソッドが呼ばれます。state
引数はupstream接続の完了の状態です。これはビットマスクで、以下の値を設定することができます:NGX_PEER_FAILED
— この試行は unsuccessful と見なされる。NGX_PEER_NEXT
— コード 403 と 404 (上のリンクを見てください)の特別な場合。これは失敗と見なされます。NGX_PEER_KEEPALIVE
. また、tries
カウンターはこのモジュールによって減少されます。 -
notify(pc, data, type)
— OSSバージョンでは、現在のところ使われていません。 -
set_session(pc, data)
とsave_session(pc, data)
— upstreamサーバへセッションをキャッシュすることができるSSL固有のメソッド。実装はラウンドロビンバランシングメソッドによって提供されます。