nginxでリバースプロキシを実装する方法
- (*-*)浩オリジナル
- 2019-06-06 09:15:1010920ブラウズ
私は最近、nginx のソース コードを研究することを計画しており、nginx をリバース プロキシ サーバーとして使用して負荷分散を完了できるというオンライン紹介を見ました。そこで、リバースプロキシサーバーに関する情報を集めてまとめてみました。
リバース プロキシ サーバーの実装には通常 2 つのモデルがあり、コンテンツ サーバーの代用として、またはコンテンツ サーバー クラスターのロード バランサとして使用できます。
コンテンツ サーバーの代役としてプロキシ サーバーはコンテンツ サーバーの代役として機能します。外部クライアントがコンテンツ サーバーにアクセスしようとすると、プロキシ サーバーに送信されます。実際のコンテンツはコンテンツ サーバー上に存在し、ファイアウォールの内側で安全に保護されています。プロキシ サーバーはファイアウォールの外側に位置し、クライアントにはコンテンツ サーバーとして見えます。 クライアントがサイトにリクエストを行うと、そのリクエストはプロキシ サーバーに送信されます。次に、プロキシ サーバーは、ファイアウォール内の特定のパスを介してクライアントのリクエストをコンテンツ サーバーに送信します。次に、コンテンツ サーバーは、このチャネルを通じて結果をプロキシ サーバーに送り返します。プロキシ サーバーは、プロキシ サーバーが実際のコンテンツ サーバーであるかのように、取得した情報をクライアントに送信します。コンテンツ サーバーがエラー メッセージを返した場合、プロキシ サーバーはメッセージをインターセプトし、メッセージをクライアントに送信する前にヘッダーにリストされている URL を変更します。これにより、外部クライアントが内部コンテンツ サーバーのリダイレクト URL を取得できなくなります。
このように、プロキシ サーバーは、安全なデータベースと潜在的な悪意のある攻撃の間に別の障壁を提供します。たとえ幸運な攻撃が成功したとしても、加害者がアクセスできるのは、データベース全体にアクセスできるのではなく、せいぜい 1 つのトランザクションに関係する情報に限られます。ファイアウォール パスではプロキシ サーバーへのアクセスのみが許可されているため、権限のないユーザーは実際のコンテンツ サーバーにアクセスできません。
コンテンツ サーバーとしてのロード バランサ組織内で複数のプロキシ サーバーを使用して、Web サーバー間でネットワーク負荷のバランスをとることができます。このモデルでは、プロキシ サーバーのキャッシュ機能を利用して、負荷分散用のサーバーのプールを作成できます。この時点で、プロキシ サーバーはファイアウォールのどちら側にあってもかまいません。 Web サーバーが毎日大量のリクエストを受信する場合、プロキシ サーバーを使用して Web サーバーの負荷を分散し、ネットワーク アクセス効率を向上させることができます。 プロキシ サーバーは、クライアントから実サーバーに送信されるリクエストの仲介として機能します。プロキシ サーバーは、要求されたドキュメントをキャッシュします。複数のプロキシ サーバーがある場合、DNS は「ラウンド ロビン」を使用して IP アドレスを選択し、リクエストをランダムにルーティングできます。クライアントは毎回同じ URL を使用しますが、リクエストのルートは毎回異なるプロキシ サーバーを経由する可能性があります。
複数のプロキシ サーバーを使用して、大容量のコンテンツ サーバーへのリクエストを処理できます。この利点は、コンテンツ サーバーが単独で動作する場合よりも高い負荷を処理でき、効率が向上することです。初期起動中、プロキシ サーバーはまずコンテンツ サーバーからドキュメントを取得します。その後、コンテンツ サーバーへのリクエストの数が大幅に減少します。
Nginx 関連の技術記事の詳細については、
Nginx の使用法チュートリアル列にアクセスして学習してください。
以上がnginxでリバースプロキシを実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。