Nginxの仕組みの詳細な説明

Nginxの仕組み

Nginx はコアとモジュールで構成されています。

Nginx 自体は実際にはほとんど作業を行いません。HTTP リクエストを受信すると、設定ファイルを参照してリクエストをロケーションブロックにマッピングするだけです。このロケーションに設定されたさまざまな命令によって、さまざまなモジュールが起動され、作業が完了します。したがって、このモジュールは Nginx の実際の労働者と見なすことができます。通常、ある場所の命令には、ハンドラーモジュールと複数のフィルターモジュールが含まれます (もちろん、複数の場所で同じモジュールを再利用できます)。ハンドラーモジュールはリクエストの処理と応答コンテンツの生成を担当し、フィルターモジュールは応答コンテンツを処理します。

ユーザーが独自のニーズに応じて開発したモジュールがサードパーティモジュールです。 Nginx が非常に強力なのは、非常に多くのモジュールをサポートしているからです。

Nginx モジュールは構造的にコアモジュール、基本モジュール、サードパーティモジュールに分かれています。

コアモジュール: HTTPモジュール、EVENTモジュール、MAILモジュール
基本モジュール: HTTP アクセスモジュール、HTTP FastCGI モジュール、HTTP プロキシモジュール、HTTP Rewrite モジュール。
サードパーティモジュール: HTTP アップストリームリクエストハッシュモジュール、通知モジュール、HTTP アクセスキーモジュール。

Nginx モジュールは、機能に基づいて次の 3 つのカテゴリに分類されます。

ハンドラー（プロセッサモジュール）。このタイプのモジュールは、リクエストを直接処理し、コンテンツの出力やヘッダー情報の変更などの操作を実行します。通常、ハンドラープロセッサモジュールは 1 つだけです。
フィルター（フィルターモジュール）。このタイプのモジュールは、主に他のプロセッサモジュールによって出力されたコンテンツを変更し、最終的に Nginx によって出力します。
プロキシ (プロキシクラスモジュール)。このタイプのモジュールは、Nginx の HTTP Upstream のようなモジュールです。これらのモジュールは主に FastCGI などのバックエンドサービスと対話して、サービスプロキシや負荷分散などの機能を実装します。

Nginx プロセスモデル

Nginx はデフォルトでマルチプロセス作業モードを使用します。Nginx が起動すると、マスタープロセスと複数のワーカープロセスが実行されます。マスターは、プロセスグループ全体とユーザー間の対話インターフェイスとして機能します。プロセスを監視し、ワーカープロセスを管理して、サービスの再起動、スムーズなアップグレード、ログファイルの置き換え、構成ファイルのリアルタイムでの有効化などの機能を実現します。ワーカーは基本的なネットワークイベントを処理するために使用されます。ワーカーは平等であり、クライアントからの要求を処理するために競合します。

nginx のプロセスモデルを図に示します。

マスタープロセスを作成するときは、まずリッスンする必要があるソケット (listenfd) を作成し、次にマスタープロセスから複数のワーカープロセスを fork() して、各ワーカープロセスがユーザーが要求したソケットをリッスンできるようにします。一般的に、接続が入ると、すべてのワーカーが通知を受け取りますが、接続要求を受け入れることができるのは 1 つのプロセスのみで、他のプロセスは失敗します。これがいわゆる群れ現象です。 nginx は accept_mutex (ミューテックスロック) を提供します。このロックを使用すると、1 つのプロセスのみが同時に accept に接続されるため、集団パニックの問題は発生しません。

まず、accept_mutex オプションをオンにします。accept_mutex を取得したプロセスのみが accept イベントを追加します。 nginx は、ngx_accept_disabled という変数を使用して、accept_mutex ロックを競合するかどうかを制御します。 ngx_accept_disabled = 単一の nginx プロセスの接続総数 / 8 - アイドル接続数。ngx_accept_disabled が 0 より大きい場合、accept_mutex ロックの取得は試行されません。ngx_accept_disable の値が大きいほど、放棄する機会が増え、他のプロセスがロックを取得する可能性が高くなります。受け入れない場合は、ワーカープロセスごとの接続数が制御され、他のプロセスの接続プールが活用されます。このようにして、nginx は複数のプロセス間の接続のバランスを制御します。

各ワーカープロセスには独立した接続プールがあり、接続プールのサイズは worker_connections です。ここでの接続プールは実際には実際の接続を保存するわけではなく、worker_connections のサイズの ngx_connection_t 構造体の配列にすぎません。さらに、nginx は、リンクリスト free_connections を通じてすべてのアイドル状態の ngx_connection_t を保存します。接続が取得されるたびに、空き接続リンクリストから接続が取得され、使用後は空き接続リンクリストに戻されます。 nginx が確立できる接続の最大数は、worker_connections * worker_processes である必要があります。もちろん、ここで話題にしているのは最大接続数です。ローカルリソースへの HTTP リクエストの場合、サポートできる同時接続の最大数は、worker_connections * worker_processes です。HTTP をリバースプロキシとして使用する場合、同時接続の最大数は、worker_connections * worker_processes/2 になります。リバースプロキシサーバーの場合、同時接続ごとにクライアントとの接続とバックエンドサービスとの接続が確立され、2 つの接続が占有されることになります。

NginxはHTTPリクエストを処理する

HTTP リクエストは、典型的なリクエスト応答型のネットワークプロトコルです。 HTTP はファイルプロトコルなので、リクエストラインとリクエストヘッダーを解析し、レスポンスラインとレスポンスヘッダーを出力する場合、行ごとに処理することがよくあります。通常、接続が確立された後、データ行が読み取られ、リクエスト行に含まれるメソッド、uri、および http_version 情報が分析されます。次に、リクエストヘッダーを 1 行ずつ処理し、リクエストメソッドとリクエストヘッダー情報に基づいて、リクエストボディの有無とリクエストボディの長さを判断し、リクエストボディを読み取ります。リクエストを受信した後、リクエストを処理して出力する必要があるデータを生成し、レスポンス行、レスポンスヘッダー、レスポンス本文を生成します。応答がクライアントに送信された後、完全なリクエストが処理されます。

処理フローチャート: