nginxでできること

Nginx の制作

Nginx について聞いたことがありませんか?それなら、その「ピア」である Apache について聞いたことがあるはずです。 Nginx は、Apache と同様に WEB サーバーです。 REST アーキテクチャ スタイルに基づいて、Uniform Resource Identifier URI または Uniform Resource Locator URL を通信の基礎として使用し、HTTP プロトコルを通じてさまざまなネットワーク サービスが提供されます。

ただし、これらのサーバーは、ユーザー規模、ネットワーク帯域幅、製品機能など、設計当時の環境によって制限されており、それぞれの位置づけや展開が異なっていました。 。このため、各 WEB サーバーにも独自の特徴があります。

Apache は開発期間が長く、誰もが認める世界ナンバーワンのサーバーです。安定性、オープンソース、クロスプラットフォームなど、多くの利点があります。それはあまりにも長い間存在していましたが、それが登場した時代には、インターネット業界は現在よりもはるかに劣っていました。そのため、重量級に設計されています。同時実行性の高いサーバーはサポートされていません。 Apache で数万の同時アクセスを実行すると、サーバーが大量のメモリを消費します。また、オペレーティング システムによるプロセスまたはスレッド間の切り替えによっても、大量の CPU リソースが消費され、結果として HTTP リクエストの平均応答速度が低下します。

これらのことから、Apache では高性能な WEB サーバーにはなり得ないと判断され、軽量で同時実行性の高いサーバーである Nginx が登場しました。

ロシア人エンジニアの Igor Sysoev は、Rambler Media で働きながら C 言語を使用して Nginx を開発しました。 Nginx は WEB サーバーとして、常に優れた安定したサービスを Rambler Media に提供してきました。

その後、Igor Sysoev は Nginx コードをオープンソース化し、フリー ソフトウェア ライセンスを付与しました。

理由:

• Nginx はイベント駆動型アーキテクチャを使用しているため、数百万の TCP 接続をサポートできます
• 高度にモジュール化されたフリー ソフトウェア ライセンス証明書により、3 番目のパーティー モジュールが際限なく登場します (これはオープンソースの時代です~)
• Nginx は、Linux、Windows、FreeBSD、Solaris、AIX、Mac OS およびその他のオペレーティング システムで実行できるクロスプラットフォーム サーバーです
• これらの優れた設計は優れた安定性をもたらします

つまり、Nginx は人気があるのです。

Nginx の登場

Nginx は、無料のオープンソースの高性能 HTTP サーバーおよびリバース プロキシ サーバーであり、IMAP、POP3、および SMTP プロキシ サーバーでもあります。 Web サイトを公開するための HTTP サーバーとして使用でき、負荷分散を実装するためのリバース プロキシとして Nginx を使用できます。

代理店について

代理店と言えば、まずコンセプトを明確にする必要がありますが、いわゆる代理店とは代表者でありチャネルであり、

現時点では、エージェント ロールとターゲット ロールの 2 つのロールが関係しており、エージェント キャラクターがターゲット ロールにアクセスして、このエージェントを通じてタスクを完了するプロセスをエージェント操作プロセスと呼びます。これは専門店と同じです。 in life ~ 顧客が adidas 専門店に行き、靴を購入しました。この専門店はエージェントであり、エージェントの役割はアディダスのメーカーであり、ターゲットの役割はユーザーです。

フォワード プロキシ

リバース プロキシについて話す前に、フォワード プロキシについて見てみましょう。フォワード プロキシは、誰もが接触する最も一般的なプロキシ モードでもあります。以下から見ていきます。フォワードプロキシの処理モデルについて、ソフトウェア面とライフ面からフォワードプロキシとは何かを説明します。

今日のネットワーク環境では、技術的な理由から特定の海外のWebサイトにアクセスする必要がある場合、ブラウザから特定の海外のWebサイトにアクセスできないことがわかります。このとき、誰もが操作FQを使用することができます。 FQ の主な方法は、海外の Web サイトにアクセスできるプロキシ サーバーを見つけることです。プロキシ サーバーにリクエストを送信すると、プロキシ サーバーは海外の Web サイトにアクセスし、アクセスされたデータを私たちに渡します。

上記のプロキシ モードはフォワード プロキシと呼ばれます。フォワード プロキシの最大の特徴は、クライアントがアクセスしたいサーバー アドレスを明確に認識していることです。サーバーはどのプロキシ サーバーのみを知っています。リクエストの送信元が不明ですが、どのクライアントから送信されたのかは不明です。フォワード プロキシ モード は、実際のクライアント情報をシールドまたは非表示にします。 概略図を見てみましょう (クライアントとフォワード プロキシをまとめています。これらは同じ環境に属しています。後で紹介します):

クライアント フォワードプロキシサーバーのセットアップが必要です もちろん、フォワードプロキシサーバーのIPアドレスとエージェントプログラムのポートがわかっていることが前提となります。写真の通り。

要約: フォワード プロキシ、「クライアントのプロキシとして機能し、クライアントに代わってリクエストを行います。」, は、次の場所にあるプロキシです。クライアントとサーバー間 オリジン サーバー間オリジン サーバーからコンテンツを取得するために、クライアントはプロキシにリクエストを送信し、ターゲット (オリジン サーバー) を指定します。プロキシはリクエストをオリジン サーバーに転送し、取得したコンテンツをクライアントに提供します。フォワード プロキシを使用するには、クライアントで特別な設定を行う必要があります。

フォワードプロキシの使用:
(1) Google など、元々アクセスできなかったリソースにアクセス可能
(2) キャッシュを使用してリソースへのアクセスを高速化できます
(3) クライアントアクセス オンラインで認可および認証する
(4) エージェントはユーザーのアクセス記録 (オンライン行動管理) を記録し、ユーザー情報を外部から隠すことができます

リバース プロキシ

フォワード プロキシとは何かを理解する, リバース プロキシの処理方法については引き続き検討していきます。たとえば、私の国の特定の Web サイトでは、毎日同時に Web サイトに接続する訪問者の数が爆発的に増えています。単一のサーバーでは到底不可能です。このとき、分散配置というよく知られた用語が使用されますが、つまり、訪問者数の制限の問題を解決するために複数のサーバーを配置することで、特定の Web サイトのほとんどの機能も実装されます。リバース プロキシに Nginx を直接使用する方法と、Nginx などをカプセル化する方法 このコンポーネントには、後に Tengine という素敵な名前が付けられました。興味のあるお子様は Tengine の公式 Web サイトにアクセスして、特定の情報を参照してください: http://tengine.taabao.org/。では、リバース プロキシはどのような方法で分散クラスター操作を実装するのでしょうか? まず、概略図を見てみましょう (サーバーとリバース プロキシを一緒に組み立てており、両方とも同じ環境に属しています。後で紹介します)。

上の図から、複数のクライアントからサーバーに送信されたリクエストを受信した後、Nginx サーバーが特定のルールに従ってそれらのリクエストをバックエンド ビジネスに分散することが明確にわかります。処理サーバーが処理しました。このとき、リクエストの送信元、つまりクライアントは明らかですが、どのサーバーがリクエストを処理するかは不明であり、Nginx がリバースプロキシの役割を果たします。

クライアントはプロキシの存在を知りません。リバース プロキシは外部に対して透過的です。訪問者はプロキシを訪問していることを知りません。クライアントはアクセスするための構成を必要としないためです。

リバース プロキシ、「サーバーのプロキシとして機能し、サーバーに代わってリクエストを受信します」, は主にサーバーに使用されます。クラスター分散展開の場合、リバース プロキシはサーバー情報を隠します。

リバース プロキシの役割:

(1) 内部ネットワークのセキュリティを確保するため、通常、リバース プロキシはパブリック ネットワークのアクセス アドレスとして使用され、Web サーバーはそのアドレスとして使用されます。内部ネットワーク
(2) ロードバランス、リバースプロキシサーバー経由でWebサイトの負荷を最適化

プロジェクトシナリオ

通常、実際のプロジェクトを運用する際には、フォワードプロキシとリバースプロキシを利用します。 1 つのアプリケーション シナリオでは、フォワード プロキシ プロキシ クライアントがターゲット サーバーへのアクセスを要求します。ターゲット サーバーは、複数の実際のビジネス処理サーバーをリバース プロキシするリバース単一関心サーバーです。具体的なトポロジ図は次のとおりです:

2 つの違い

フォワード プロキシとリバース プロキシの違いを示すためにスクリーンショットを撮りました。図に示すように。

図:

フォワード プロキシでは、プロキシとクライアントは同じ LAN (図のボックス内) に属し、クライアントは情報は隠されています;

リバース プロキシでは、プロキシとサーバーは同じ LAN (図のボックス内) に属し、サーバー情報が隠されます。

#実際には、プロキシも同じことを行います。サーバーに代わってリクエストやレスポンスを送受信しますが、構造的には左右が入れ替わるので、後から登場したプロキシ方式をリバースプロキシと呼びます。

ロードバランシング

いわゆるプロキシサーバーの概念が明確になったので、次はNginxがリバースプロキシサーバーの役割を果たし、どのようなルールでリクエストを振り分けるのかを毛織で説明します。 ?さまざまなプロジェクトの適用シナリオに合わせて配布ルールを制御できますか?

ここで言及する、クライアントによって送信され、Nginx リバース プロキシ サーバーによって受信されるリクエストの数は、負荷と呼ばれるものです。

リクエストの数を特定のルールに従って異なるサーバーに分散して処理するルールは、バランシング ルールです。

つまり、サーバーが受信したリクエストをルールに従って分散するプロセスをロード バランシングと呼びます。

実際のプロジェクト運用プロセスでは、負荷分散にはハードウェア負荷分散とソフトウェア負荷分散の2種類があり、ハードウェア負荷分散はF5負荷分散などのハード負荷とも呼ばれ、比較的コストが高く高価ですが、データは安定していて安全です。パフォーマンスなどについては非常に優れた保証があります。チャイナモバイルやチャイナユニコムなどの企業だけがハードロード操作を選択します。コスト上の理由から、より多くの企業がソフトウェアロードバランシングを使用することを選択します。ソフトウェアロードバランシングは既存のテクノロジーを使用します。」ホスト ハードウェアと組み合わせて実装されるメッセージ キュー分散メカニズム。

Nginx でサポートされている負荷分散スケジューリング アルゴリズムは次のとおりです。

1. 重みポーリング (デフォルト、一般的に使用されます): 受信したリクエストは次のように分散されます。異なるバックエンド サーバーに対して、使用中に特定のバックエンド サーバーがダウンした場合でも、Nginx はそのサーバーをキューから自動的に削除し、リクエストの受け入れには一切影響しません。このように、異なるバックエンド サーバーに重み値 (重み) を設定して、異なるサーバーへのリクエストの割り当て率を調整できます。重みデータが大きいほど、リクエストに割り当てられる確率が高くなります。重み値, 主に、実際の作業環境におけるさまざまなバックエンド サーバーのハードウェア構成に合わせて調整されています。
2. ip_hash (一般的に使用されます): 各リクエストは、開始クライアントの IP のハッシュ結果に従って照合されます。このアルゴリズムでは、固定 IP アドレスを持つクライアントは常に同じバックエンド サーバーにアクセスします。これにより、クラスター展開環境におけるセッション共有の問題がある程度解決されます。
3. fair: スケジューリング アルゴリズムをインテリジェントに調整し、バックエンド サーバーのリクエスト処理から応答までの時間に基づいて動的かつバランスのとれた割り当てを行い、応答時間が短く、処理効率が高いサーバーは、高い確率で優先されます。応答時間の長いサーバーには処理効率が高く、応答時間の短いサーバーには少ないリクエストが割り当てられるという、前 2 つの利点を組み合わせたスケジューリング アルゴリズムです。ただし、Nginx はデフォルトではフェア アルゴリズムをサポートしていないため、このスケジューリング アルゴリズムを使用したい場合は、upstream_fair モジュールをインストールしてください。
4. url_hash: アクセスされた URL のハッシュ結果に従ってリクエストを分散します。各リクエストの URL はバックエンドの固定サーバーを指すため、Nginx を静的サーバーとして使用する場合にキャッシュ効率を向上させることができます。なお、Nginx はデフォルトではこのスケジューリング アルゴリズムをサポートしていないため、使用したい場合は Nginx ハッシュ ソフトウェア パッケージをインストールする必要があります。

一般的に使用されるいくつかの Web サーバーの比較

##ホット デプロイメントシステム圧力安定性セキュリティ静的ファイルの処理リバース プロキシ

比較項目\サーバー	Apache	Nginx	Lighttpd
プロキシ proxy	非常に良い	非常に良い	平均
リライター	良い	非常に良い	平均
#Fcgi	悪い	良い	非常に良い
#サポート対象外	サポート対象	サポート対象外
非常に高い	非常に小さい	比較的小さい
良い	非常に良い	悪い
良い	一般	一般
平均	非常に良い	良い
平均	非常に良い 良い	一般

Nginx 関連の技術記事の詳細については、

Nginx チュートリアル## をご覧ください。 #勉強になるコラム！

以上がnginxでできることの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。