Nginx で何ができるかの包括的な分析

序文

この記事は、サードパーティのモジュールをロードせずにNginxで処理できることのみに焦点を当てています。サードパーティのモジュールが多すぎるため、すべてを紹介することは不可能です。もちろん、この記事自体が完全ではない可能性があります。結局のところ、個人的に使用して理解したことだけです。どうぞお許しください。メッセージを残してくださると嬉しいです

Nginxでできること

1. リバースプロキシ
2. 負荷分散
3. HTTPサーバー（動的および静的分離を含む）
4. フォワードプロキシ

上記は、サードパーティのモジュールに頼らずにNginxで何ができるかについて私が知っていることです。以下は、各機能を実行する方法の詳細な説明です。

リバースプロキシ

リバース プロキシは、おそらく Nginx が行う最も一般的なことです。リバース プロキシとは何でしょうか? Baidu 百科事典には次のように書かれています。リバース プロキシとは、プロキシ サーバーを使用してインターネット上の接続要求を受け付け、その要求を内部ネットワーク上のサーバーに転送し、サーバーから取得した結果をインターネット上の接続を要求しているクライアントに返すことを指します。このとき、プロキシ サーバーは外部からはリバース プロキシ サーバーのように見えます。簡単に言うと、実サーバーは外部ネットワークから直接アクセスできないため、プロキシサーバーが必要になります。プロキシサーバーは外部ネットワークからアクセスでき、実サーバーと同じネットワーク環境にあります。もちろん、ポートが異なる同じサーバーでもかまいません。

リバースプロキシを実装するための簡単なコードは次のとおりです。

サーバー{
    聞く 80;                             
    server_name ローカルホスト;                        
    クライアントの最大ボディサイズ 1024M;

    位置 / {
      proxy_pass http://localhost:8080;
      proxy_set_header ホスト $host:$server_port;
    }
  }

設定ファイルを保存したら、Nginx を起動します。localhost にアクセスすると、localhost:8080 にアクセスするのと同じになります。

負荷分散

負荷分散も Nginx でよく使用される機能です。負荷分散とは、Web サーバー、FTP サーバー、企業の主要なアプリケーション サーバー、その他のミッション クリティカルなサーバーなど、複数の操作ユニットに実行を分散して、作業タスクをまとめて完了することを意味します。簡単に言うと、サーバーが 2 台以上ある場合、リクエストは指定されたサーバーにランダムに分散され、ルールに従って処理されます。負荷分散構成では、通常、リバース プロキシの構成も同時に必要であり、リバース プロキシを介して負荷分散にジャンプします。 Nginx は現在、3 つの組み込み負荷分散戦略と 2 つの一般的に使用されるサードパーティ戦略をサポートしています。

1. RR（デフォルト）

各リクエストは時系列順に 1 つずつ異なるバックエンド サーバーに割り当てられます。バックエンド サーバーがダウンしている場合は、自動的に削除されます。

シンプルな構成

 上流テスト{
    サーバー localhost:8080;
    サーバー localhost:8081;
  }
  サーバー{
    聞く 81;                             
    server_name ローカルホスト;                        
    クライアントの最大ボディサイズ 1024M;

    位置 / {
      proxy_pass http://test;
      proxy_set_header ホスト $host:$server_port;
    }
  }

負荷分散のコアコードは

  上流テスト{
    サーバー localhost:8080;
    サーバー localhost:8081;
  }

ここでは 2 つのサーバーを設定しましたが、もちろん実際には 1 つですが、ポートが異なり、サーバー 8081 は存在しないため、アクセスできません。ただし、http://localhost にアクセスすると、問題なく、デフォルトで http://localhost:8080 にジャンプします。これは、Nginx がサーバーの状態を自動的に判断するためです。サーバーにアクセスできない場合 (サーバーがダウンしている場合)、このサーバーにジャンプしないため、サーバーがダウンして使用に影響する状況も回避できます。Nginx はデフォルトで RR ポリシーになっているため、他の設定は必要ありません。

2. 重量

ポーリング確率を指定します。重みはアクセス率に比例し、バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。

例えば

  上流テスト{
    サーバー localhost:8080 weight=9;
    サーバー localhost:8081 weight=1;
  }

すると、一般的に 10 人中 1 人だけが 8081 にアクセスし、10 人中 9 人が 8080 にアクセスします。

3. ip_ハッシュ

上記の 2 つの方法には問題があります。つまり、次のリクエストが来たときに、リクエストが別のサーバーに分散される可能性があります。プログラムがステートレスではない場合 (セッションを使用してデータを保存する場合)、この時点で大きな問題が発生します。たとえば、ログイン情報がセッションに保存されている場合、別のサーバーにジャンプするときに再度ログインする必要があります。そのため、多くの場合、顧客が 1 つのサーバーにのみアクセスする必要がある場合は、ip_hash を使用する必要があります。ip_hash の各リクエストは、アクセス IP のハッシュ結果に従って割り当てられるため、各訪問者は固定のバックエンド サーバーにアクセスし、セッションの問題を解決できます。

  上流テスト{
    ip_ハッシュ;
    サーバー localhost:8080;
    サーバー localhost:8081;
  }

4. 公正（第三者）

リクエストはバックエンド サーバーの応答時間に基づいて分散され、応答時間が短いリクエストが優先されます。

  アップストリームバックエンド{ 
    公平; 
    サーバー localhost:8080;
    サーバー localhost:8081;
  }

5. url_hash（サードパーティ）

アクセスされた URL のハッシュ結果に応じてリクエストが分散され、各 URL が同じバックエンド サーバーに送られます。これは、バックエンド サーバーがキャッシュされている場合に、より効果的です。 アップストリームにハッシュ ステートメントを追加します。重みなどの他のパラメータは、サーバー ステートメントに書き込むことはできません。hash_method は、使用されるハッシュ アルゴリズムです。

  アップストリームバックエンド{ 
    $request_uri をハッシュします。 
    ハッシュメソッドCRC32; 
    サーバー localhost:8080;
    サーバー localhost:8081;
  }

上記の 5 種類の負荷分散はそれぞれ異なる状況に適しているため、実際の状況に応じてどの戦略モードを使用するかを選択できます。ただし、fair と url_hash を使用するには、サードパーティのモジュールをインストールする必要があります。この記事では主に Nginx で何ができるかを紹介するため、Nginx 用のサードパーティ モジュールのインストールについてはこの記事では紹介しません。

HTTP サーバー

Nginx 自体も静的リソース サーバーです。静的リソースしかない場合は、Nginx をサーバーとして使用できます。同時に、静的リソースと動的リソースを分離することも非常に人気があり、これは Nginx を通じて実現できます。まず、静的リソース サーバーとしての Nginx を見てみましょう。

  サーバー{
    聞く 80;                             
    server_name ローカルホスト;                        
    クライアントの最大ボディサイズ 1024M;
    位置 / {
        ルート e:wwwroot;
        インデックス index.html;
      }
  }

このように、http://localhost にアクセスすると、デフォルトではドライブ E の wwwroot ディレクトリにある index.html にアクセスすることになります。Web サイトが単なる静的ページである場合は、この方法で展開できます。

静的と動的の分離

動的と静的の分離とは、動的ウェブサイト内の動的ウェブページが、一定のルールに従って、頻繁に変更されるリソースから不変のリソースを区別できるようにすることです。動的リソースと静的リソースを分離した後、静的リソースの特性に応じてキャッシュすることができます。これがウェブサイトの静的処理の核心的な考え方です。

上流テスト{ 
    サーバー localhost:8080; 
    サーバー localhost:8081; 
  }  

  サーバー{ 
    聞く 80; 
    server_name ローカルホスト; 

    位置 / { 
      ルート e:wwwroot; 
      インデックス index.html; 
    } 

    # すべての静的リクエストはnginxによって処理され、htmlディレクトリに保存されます 
    場所 ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ { 
      ルート e:wwwroot; 
    } 

    # すべての動的リクエストは処理場所として Tomcat に転送されます ~ .(jsp|do)$ { 
      proxy_pass http://test; 
    } 

    エラーページ 500 502 503 504 /50x.html; 
    場所 = /50x.html { 
      ルート e:wwwroot; 
    } 
  }

このように、HTML、画像、CSS、JSをwwwrootディレクトリに置くことができ、Tomcatはjspとリクエストの処理のみを担当します。たとえば、サフィックスがgifの場合、Nginxはデフォルトでwwwrootから現在のリクエストの動的な画像ファイルを取得して返します。もちろん、ここでの静的ファイルはNginxと同じサーバー上にあります。別のサーバーを使用して、リバースプロキシとロードバランシングを介して構成することもできます。最も基本的なプロセスを理解している限り、多くの構成は非常に簡単になります。さらに、localtionの後に実際には正規表現が続くため、非常に柔軟性があります。

フォワードプロキシ

フォワードプロキシは、クライアントとオリジンサーバーの間にあるサーバーです。クライアントは、オリジンサーバーからコンテンツを取得するために、プロキシにリクエストを送信し、ターゲット（オリジンサーバー）を指定します。プロキシは、リクエストをオリジンサーバーに転送し、取得したコンテンツをクライアントに返します。クライアントはフォワードプロキシを使用できます。サーバーをプロキシサーバーとして使用する必要がある場合は、Nginx を使用してフォワードプロキシを実装できます。ただし、現在、Nginx には問題があり、HTTPS をサポートしていません。Baidu で HTTPS フォワードプロキシを構成する方法を検索しましたが、プロキシとして使用できないことがわかりました。もちろん、私の構成が間違っている可能性もありますので、正しい方法を知っている同志がメッセージを残して説明してくれることを願っています。

リゾルバ 114.114.114.114 8.8.8.8;
  サーバー{

    リゾルバタイムアウト 5秒;

    聞く 81;

    アクセスログ e:wwwrootproxy.access.log;
    error_log e:wwwrootproxy.error.log;

    位置 / {
      proxy_pass http://$host$request_uri;
    }
  }

Resolver はフォワード プロキシを構成する DNS サーバーであり、listen はフォワード プロキシのポートです。構成が完了すると、IE や他のプロキシ プラグインでプロキシにサーバー IP + ポート番号を使用できるようになります。

最後に

Nginx はホット スタートをサポートしています。つまり、設定ファイルを変更した後、Nginx をシャットダウンせずに設定を有効にすることができます。もちろん、これを知っている人がどれだけいるかはわかりません。とにかく、最初は知らなかったので、Nginx スレッドを強制終了してから再起動することがよくありました。 。 。 Nginxが設定を再読み込みするためのコマンドは

nginx -s reload

Windowsでは

nginx.exe -s reload

要約する

以上が、Nginx で何ができるかについてご紹介しました。お役に立てれば幸いです。ご質問があれば、メッセージを残していただければ、すぐに返信いたします。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。