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 サイトにアクセスし、アクセスされたデータを私たちに渡します。

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

nginxでできること

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

nginxでできること

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

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

リバースプロキシ

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

nginxでできること

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

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

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

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

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

プロジェクトシナリオ

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

nginxでできること

2 つの違い

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

nginxでできること

図:

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

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

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

ロードバランシング

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

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

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

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

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

nginxでできること

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

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

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

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

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