nginx関連のナレッジポイントのまとめと共有

Nginx 自体は PHP を解析しません。PHP ページに対するターミナルのリクエストは、Nginx によって FastCGI プロセスによって監視される IP アドレスとポートに渡され、動的解析サーバーとして php-fpm によって処理されます。処理結果はnginxに返されます。実際、Nginx はリバース プロキシ サーバーです。 Nginx は、リバースプロキシ機能を通じて動的リクエストをバックエンド php-fpm に転送することで、PHP 解析のサポートを実現します。これが、Nginx が PHP 動的解析を実装する原理です。

Nginx は、外部プログラムの直接呼び出しや解析をサポートしていません。すべての外部プログラム (PHP を含む) は、FastCGI インターフェイスを通じて呼び出す必要があります。 FastCGI インターフェイスは、Linux 上のソケットです (このソケットはファイル ソケットまたは IP ソケットにすることができます)。 CGI プログラムを呼び出すには、FastCGI ラッパーも必要です (ラッパーは、別のプログラムを開始するために使用されるプログラムとして理解できます)。このラッパーは、ポートやファイル ソケットなどの固定ソケットにバインドされます。 Nginx が CGI リクエストをこのソケットに送信すると、ラッパーは FastCGI インターフェイスを通じてリクエストを受信し、新しいスレッドを生成してスクリプトを処理し、返されたデータを読み取ります。返されたデータは、FastCGI インターフェイスを介して固定ソケット経由で Nginx に渡され、最後に、Nginx は返されたデータをクライアントに送信します。

古典的なモデルは、Nginx で使用されるマスター-ワーカー マルチプロセス非同期ドライバー モデルです。

親プロセスがソケットを作成し、バインドしてリッスンすると、フォークを通じて複数の子プロセスが作成され、各子プロセスは親プロセスのソケットを継承し、accpet を呼び出してネットワーク接続のリッスンと待機を開始します。このとき、同時に複数のプロセスがネットワーク接続イベントを待っていますが、このイベントが発生すると、これらのプロセスが同時に目覚めることになり、これは「ショック」です。プロセスが起動されると、各プロセスがこのイベントに同時に応答するようにカーネルを再スケジュールする必要があり、最終的に 1 つのプロセスだけがイベントを正常に処理でき、他のプロセスは再スリープするか、イベントの処理に失敗します。イベント。

実際、Linux バージョン 2.6 以降、カーネルは accept() 関数の「ショック」問題を解決しました。カーネルは顧客接続を受信すると、待機キュー内の最初のプロセスまたはスレッドのみを起動します。

この問題を解決するには、Nginx で accept_mutexmutex ミューテックス ロックが使用されます。具体的な対策には、アプリケーションが取得できない場合は、グローバル ミューテックス ロックを適用することが含まれます。取得されると、待機して負荷分散アルゴリズム (特定のサブプロセスのタスク量が設定された合計量の 7/8 に達すると、ロックの適用はそれ以上試行されなくなります) を設定して、タスク量のバランスをとります。それぞれのプロセス。

ここで、サンダーリンググループと Nginx の処理を​​次のように要約します:

• accept はサンダーリンググループを引き起こしませんが、epoll_wait はサンダーリンググループを引き起こします。

• Nginx の accept_mutex は、accept パニックの問題を解決しませんが、epoll_wait パニックの問題を解決します。

• Nginx が epoll_wait パニック問題を解決するのは、リッスンするソケットを epoll に追加するかどうかだけを制御する、というのも間違いです。待機ソケットは 1 つの子プロセスの epoll 内にのみ存在します。新しい接続が到着しても、他の子プロセスは確実に起動しません。

簡単に言うと、同時に 1 つの nginx ワーカーだけが、自身の epoll でリスニング ハンドルを処理できます。負荷分散も非常に簡単で、最大接続の 7/8 に達すると、ワーカーは受け入れロックを取得しようとせず、新しい接続を処理しないため、他の nginx ワーカー プロセスが接続を処理する機会が増えます。新しい接続が確立されます。また、タイムアウトの設定により、ロックを取得していないワーカープロセスがロックを取得する頻度が高くなります。

nginx マルチプロセス モデルは本当にロックフリーですか?実際には、ngx_accept_mutex がまだ存在します。

nginx はマルチプロセス プログラムであり、ポート 80 が各ワーカー プロセスによって共有されるため、接続が来るたびに複数のワーカー プロセスが競合して応答することになります。これがいわゆるサンダーリング ハード現象です。

カーネルがリンクを受け入れると、待機中のすべてのプロセスがウェイクアップされますが、実際には 1 つのプロセスのみが接続を取得でき、他のプロセスは無効にウェイクアップされ、アプリケーションのオーバーヘッドが確実に増加します。この目的を達成するために、nginx は受け入れロックを提供し、9 人の息子が相続人を引き継ぐという悲劇を回避します。

ngx_accept_mutex の機能は、現在負荷の高いワーカー プロセス

が新しい受信リクエストの処理を積極的に放棄できるようにし、

アプリケーションの全体的なウェイクアップ効率を向上させ、それによってアプリケーションの全体的なパフォーマンスを向上させることです。 。

proxy_cache

upstream

fastcgi_pass

location

非標準ステータス コード 444 は、接続が閉じられ、クライアントに応答ヘッダーが送信されないことを意味します。

nginx -s reload コマンドは、変更された設定ファイルをロードします。

1. Nginx のマスター プロセスが設定ファイルの正しさをチェックし、間違っている場合はエラー メッセージが返され、nginx は続行します。元の設定ファイルを使用して動作するため (ワーカーには影響しないため)

2. Nginx は新しいワーカー プロセスを開始し、新しい設定ファイルを採用します

3. Nginx は新しいリクエストを新しいワーカー プロセスに割り当てます

4.前のワーカー プロセスからのすべてのリクエストが完了するまで待機します。すべて戻ったら、関連するワーカー プロセスを閉じます

5. 古いワーカー プロセスがすべて閉じるまで、上記のプロセスを繰り返します

上記のプロセスは、nginx の関連する公式ドキュメントに基づいています。

proxy_next_upstream を例に挙げると、一般的な設定は次のとおりです:

proxy_next_upstream http_504 タイムアウト;

このコマンドには 2 つの機能があります:

1. 接続タイムアウトが発生し、アップストリームが 504 を返す必要があることを nginx に伝えます。

2. nginx、http 504、接続タイムアウトはリクエストの失敗であると伝えます

一般に、nginx はデフォルトで error、timeout、invalid_header で失敗します。他の動作を失敗として扱いたい場合は、次のようにする必要があります。クラスディレクティブにproxy_next_upstreamのようなものを追加します。 このうち http_403 と http_404 が認識されない場合は失敗です。

サーバー障害の定義と障害後のサーバーの動作の 2 つの点について説明します。

• サーバー障害の定義: 上記のモジュール障害定義は主に、どのような状況でリクエストが失敗するかを説明するために使用されますが、サーバーが障害として定義されるのは何でしょうか? nginx は主に、max_fails とfail_timeout という 2 つのパラメータを使用して制御します。 簡単に言うと、リクエストがfail_timeout以内にmax_fails回失敗した場合、サーバーが現在ダウンしていることを意味します。

• 失敗後の動作: 主に:

• fail_timeout期間中、サーバーは選択されません。

• fail_timeout時間が経過すると、サーバーは通常としてマークされ、既存の動作が繰り返されます。論理。

Ngxinはクライアントリクエストの処理を11のステージに分割します

#1 NGX_HTTP_POST_READ_PHASE: リクエストコンテンツの読み取りステージ

#2 NGX_HTTP_SERVER_REWRITE_PHASE: サーバーリクエストのアドレス書き換えステージ

#3 NGX_ HTTP_FIND_CONFIG_PHASE:探索フェーズ

#4 NGX_HTTP_REWRITE_PHASE: ロケーション要求アドレス書き換えフェーズ

#5 NGX_HTTP_POST_REWRITE_PHASE: アドレス書き換え要求フェーズ

#6 NGX_HTTP_PREACESS_PHASE: アクセス許可チェック準備フェーズ

#7 NGX_HTTP_ACCESS_PHASE: アクセス許可チェックフェーズ

#8 POST_ACCESS_PHASE : アクセス許可チェック送信フェーズ

#9 NGX_HTTP_TRY_FILES_PHASE: 設定項目try_filesの処理フェーズ

#10 NGX_HTTP_CONTENT_PHASE: コンテンツ生成フェーズ

#11 NGX_HTTP_LOG_PHASE: ログモジュールの処理フェーズ

Nginxのリクエスト処理プロセス

#1 Nginxの確認方法?

1. IP + ポートを使用して、IP とポートをリッスンしているサーバーを確認します。

2. リクエストのホストヘッダーに基づいて、リクエストを処理するためにどのサーバーが選択されているかを確認します。

3. 一致するサーバーがない場合、リクエストは処理のためにデフォルトのサーバーに転送されます

一般に、設定がなければ、設定ファイル内で最初に現れるサーバーが

のデフォルトのサーバーになります。

4. listen コマンドでdefault_server フラグを使用して、サーバーを

デフォルトサーバーとして設定できます。

#2 Nginx はホストヘッダーに基づいてどのようにサーバーを照合しますか?

Nginx は主に、サーバー内の server_name と host ヘッダーを比較することによってサーバーを照合します。

比較の順序は次のとおりです:

1. 一致する先頭のワイルドカード名 (*.zhidao.baidu.com など)。例: zhidao.baidu.*);

#3 http リクエストの初期化、http リクエストの 11 段階

位置一致コマンド

~ 波線は、大文字と小文字が区別される通常の一致の実行を示します。

~* は、大文字と小文字を区別せずに通常の一致を実行することを意味します。

^~ ^~ は通常の文字マッチングを意味します。このオプションが一致する場合、このオプションのみが一致し、他のオプションは一致しません。これは通常、ディレクトリを一致させるために使用されます。

= 一般的な文字の完全一致を実行します。

@ "@" は、error_page、try_files などの内部方向付けに使用される名前付きの場所を定義します。

例:

リクエストURIの例:

/ -> 構成Aに準拠

• -> 構成Bに準拠

/images /1.gif -> 構成 C に準拠します
/documents/1.jpg -> 構成 D に準拠します
関連する推奨事項:

• nginx リバース プロキシ メカニズムはフロントエンドのクロスドメインの問題

nginxでアップロードされたファイルのサイズを変更する方法

Nginxの動的と静的分離操作の説明

以上がnginx関連のナレッジポイントのまとめと共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。