nginxの（エンジンX）は、高性能HTTPサーバであり、プロキシウェブサーバを逆転するだけでなく、IMAP / POP3 / SMTPサービスを提供します。
nginxの最大の特徴は、高い並行性と効率的な負荷分散のためにサポートされ、高度に同時需要シナリオでは、Apacheサーバは良い代替品です。
、nginxの利点と欠点
1.メリット
（1）高い同時実行：公式与えられた回答によると、50,000の同時接続をサポートできます。
以下（2）メモリの消費量：静的ファイル、同じWebサービスからは、それのすべてが軽量で、Apacheとリソースよりも少ないメモリを使用しています。
（3）単純かつ安定した：簡単な構成は、confファイル内の基本的な構成は、性能が比較的安定している、それは7×24時間の長い連続運転することができます。
（4）モジュールの高度：nginxのは、高度にモジュール設計である、調製物はgzipping、バイト範囲を含む、比較的単純なモジュールであり、フィルタのような応答、およびSSI-フィルタをチャンク、およびSSL TLSSNIをサポートします。
別のドメイン名、URLによると、HTTP要求は、異なるバックエンド・サーバ・グループに配布されます（5）RWRITE書き換えルールをサポートしています。
（6）低コスト：nginxのは、高い同時負荷分散を行うことができます、とnginxのは、無料のオープンソースであり、他のハードウェアを行うには、F5のロードバランシングを使用する場合、ハードウェアのコストが高くなっています。
（7）マルチシステムをサポートしています：NginxはC言語で書かれた最初からコードは、を含む多くのアーキテクチャとオペレーティングシステムに移植されています。Linux、FreeBSDの、Solaris版、マックOS X、AIXおよびMicrosoft Windows、原因nginxのは、無料のオープンソースですこれは、コンパイルされ、様々なシステム上で使用することができます。
2.欠点
（1）動的プロセスの間の差：リバースプロキシnginxのダイナミックバックエンド処理要求として、Apacheの圧力に耐えるようにnginxのは、静的ファイルは、より少ないメモリを消費する処理が、プロセスは非常に無味動的ページで、フロントエンドは、現在一般的に用いられています。
（2）弱い書き換え：nginxの書き換え機能のサポートはしたのですが、Apacheに比べものの、しかし、nginxのの書き換えよりも強力なApacheの。
二、nginxのアプリケーションシナリオ
- フォワードプロキシ
- リバースプロキシ
- （静的および動的分離を含む）HTTPサーバ
- ロードバランシング
1.フォワードプロキシ
フォワードプロキシはクライアントプロキシに要求を送信し、ターゲット（元のサーバー）を指定し、その後、クライアントに取得するには、元のプロキシサーバとコンテンツへの要求を転送しています。
リゾルバ114.114.114.114 8.8.8.8。
サーバ{
resolver_timeoutの5S、
81を聞きます。
access_logのE：/wwwrootproxy.access.log。
error_logにE：/wwwrootproxy.error.log。
場所/ {
proxy_passます。http：// $ホストの$ REQUEST_URI。
}
}
2.リバースプロキシ
nginxのリバースプロキシは、一つのことで作られるべきです。リバースプロキシ：プロキシサーバは、内部ネットワーク上のサーバに要求を転送し、結果が戻ってインターネットへの接続を要求しているクライアントに、サーバから取得し、その後、インターネット上の接続要求を受け入れ、そのために外部のプロキシサーバー場合リバースプロキシサーバーのパフォーマンスに。それは単に、もちろん、それは同じサーバ、ポートかもしれプロキシサーバを必要とするので、真のサーバが直接、外部のネットワークにアクセスし、プロキシサーバが同時にネットワーク環境で同じ実サーバとのすべての接続の外部ネットワークにアクセスすることができません異なります。
コードのシンプルな一枚を達成するためにリバースプロキシ：
サーバー{
80を聞きます。
サーバー名はlocalhost。
1024Mをclient_max_body_size。
位置/ {
proxy_passのhttp：// localhostを：8080。
proxy_set_headerホスト$ホスト：$ SERVER_PORT。
}
}
8080：nginxのを開始するように設定ファイルを保存した後、我々はアクセスはlocalhostと同等のローカルホストを、訪問したときになるように。
（静的および動的分離を含む）3. HTTPサーバ
（1）場合にのみ静的リソースnginxの自体は、静的リソースサーバで、あなたはnginxのは、実行するサーバーを使用することができますが、今も人気動き分離はnginxのによって達成することができます。
サーバー{
80を聞きます。
サーバー名はlocalhost。
1024Mをclient_max_body_size。
位置/ {
ルートE：/ wwwrootに。
インデックスのindex.html;
}
}
今回の訪問の場合はhttp：// localhostのはへのアクセスデフォルトとなるEディスクのwwwroot下にディレクトリをindex.htmlサイトだけで静的なページならば、あなたはこのような方法で達成するために展開することができます。
静的および動的な分離は、資源の動きは、我々はキャッシュ操作を行うための静的リソースの特性に応じてすることができ、分割後行うには、一定のルールに従った動的なページが同じリソースを区別するための動的なWebサイトを作ることであり、多くの場合、リソース領域となりますこれは、サイトの静的プロセスの核となるアイデアです。
{試験上流
サーバーはlocalhost：8080;
サーバーはlocalhost：8081;
}
サーバー{
80を聴く、
サーバー名はlocalhost、
LOCATION / {
ルートE：/ wwwrootに、
インデックスのindex.html;
}
すべての静的nginxの処理によって＃要求、ストレージディレクトリHTML
。LOCATION〜（GIF | JPG | JPEG | PNG | BMP | SWF | CSS | JS）$ {
ルートE：/ wwwrootに;
}
＃すべての動的要求はTomcatのプロセスに転送されます
。LOCATION〜（JSP |ん）$ {
proxy_pass HTTP ：//試験;
}
error_page 500 502 503 504 /50x.html。
LOCATION = {/50x.html
ルートE：/ wwwrootに。
}
}
私たちは、現在の動的マップファイルから取得するには写真やHTMLやCSSやJS wwwrootディレクトリの下に置くが、唯一のハンドルJSP Tomcatとの要求は、そのような私たちは時間のGIFのサフィックスときのように、nginxのデフォルトのwwwrootのを入れてリターンを要求できるように、もちろんnginxのと同じ静的ファイルサーバがある、我々はまた、別のサーバでは、その後、限り最も基本的なプロセスを見つけると、リバースプロキシとロードバランシングのように非常にシンプルな構成の多くを過去に設定することができます、他のlocaltionバックは、それは非常に柔軟性があり、実際には正規表現です。
4.ロードバランシング
nginxのロードバランシングは、タスクを完了するために連携して動作するように、そのようなWebサーバ、FTPサーバ、ビジネスクリティカルなアプリケーションサーバや他のミッションクリティカルなサーバなどの実行に割り当てられた複数のオペレーティング・ユニット、全体でその負荷分散を意味共通の特徴です。簡単に言えば、それは、指定されたサーバー・プロセスへのランダムなルールの要求に応じて分散サーバの2つの以上のセットが、存在する場合には、負荷分散の構成は、一般的に、リバースプロキシ、ロードバランサを介してジャンプする、リバースプロキシを設定する必要があるということです。nginxのは、現在、ネイティブの負荷分散戦略の3種類をサポートし、一般的なサードパーティポリシーの2種類があります。
（1）RR（デフォルト）
場合は、個別に異なる時間順バックエンドサーバー、バックエンドサーバーに割り当てられた各要求down失われたが、自動的に削除することができます。
上流のテスト{
サーバーはlocalhost：8080。
サーバーはlocalhost：8081;
}
サーバー{
81を聴きます。
サーバー名はlocalhost。
1024Mをclient_max_body_size。
位置/ {
proxy_passのhttp：//テスト。
proxy_set_headerホスト$ホスト：$ SERVER_PORT。
}
}
＃负载均衡的核心代码
上流テスト{
サーバーはlocalhost：8080。
サーバーはlocalhost：8081;
}
もちろん、ここで設定する2台のサーバは、実際に1であるが、ちょうどない、同じポート、および8081サーバはそれが訪問することはありませんが、存在していませんが、私たちが訪問にhttp：// localhostの時間、それはしません問題がある、それはへジャンプするデフォルトになりますのhttp：// localhostを：8080、自動的にサーバが（サーバがハングアップ）アクセス可能でない場合、それは、このサーバーにジャンプしませんだろうな状態を決定するので、それを避けることができ、具体的理由はnginxのサーバーの影響力の使用にリンクされているサーバーの場合、デフォルトはnginxののRRポリシーですので、我々は非常に多くのより多くの設定は必要ありません。
（2）重量
ポーリング凹凸バックエンドサーバーのパフォーマンス場合の重量比は、アクセスに比例した確率。例えば：
上流のテスト{
サーバーはlocalhost：8080重量= 9。
サーバーはlocalhost：8081重量= 1;
}
だから、10時間は通常、唯一持っている1だろう訪問する時間を8081、しかし、ある9回にアクセスする必要があります8080。
方法の上記2種類のは、私たちのプログラムはステートレスでない場合、要求に次の要求は、（データの保存セッションを使用して）、別のサーバーに配布することができるとき、この時間は偉大な存在であるという問題がありますセッションへのログイン情報を保存するよう再度ログインする必要がある場合、その後、別のサーバーに移動するように非常に問題が、我々は唯一のサーバーのクライアントアクセスを必要とするので、何度も、あなたはiphash使用する必要がある、とiphash各訪問者は、一定のバックエンドサーバーにアクセスするには、セッションの問題を解決できるように、各要求は、訪問のIPハッシュ結果に従って割り当てられています。
上流のテスト{
ip_hash。
サーバーはlocalhost：8080;
サーバーはlocalhost：8081;
}
（4）公正（サードパーティ）
バックエンドサーバ、短い応答時間優先割り当てに割り当て要求の応答時間によって。
上流のバックエンド{
公正。
サーバーはlocalhost：8080;
サーバーはlocalhost：8081;
}
（5）url_hash（サードパーティ）
割り当て要求に押してアクセスURLのハッシュ結果は、同じバックエンドサーバに向けた各URLは、バックエンドサーバは、ときにキャッシュ効果的です。上流の、サーバー文で文をハッシュ結合、体重などの他のパラメータを記述することはできません、hash_methodハッシュアルゴリズムが使用されています。
上流のバックエンド{
ハッシュの$ REQUEST_URI。
hash_method CRC32;
サーバーはlocalhost：8080;
サーバーはlocalhost：8081;
}
5以上のロードバランシングあなたは実際の状況に応じてモードを使用するポリシーを選択することができますが、公正かつurl_hashを使用するサードパーティ製のモジュールをインストールする必要があるので、異なる状況で適用可能な各使用を。
三つは、Apache、Nginxは、Lighttpdの比較
