ユニコーンをNginxと一緒に展開する必要があるのはなぜですか？
NginxとUnicornの違いを知りたいです。私の知る限り、NginxはWebサーバーですが、UnicornはRuby HTTPサーバーです。
NginxとUnicornの両方がHTTPリクエストを処理できるので、RoRアプリケーションにNginxとUnicornの組み合わせを使用する必要性は何ですか？
Nginx
Unicorn
詳細については、 githubのユニコーン を参照してください。
Nginxは、静的コンテンツを提供したり、リクエストを別のソケットにリダイレクトしてリクエストを処理したりするための純粋なWebサーバーです。
UnicornはRack Webサーバーであり、通常動的コンテンツを生成する「Rackアプリ」をホストすることのみを目的としています。ラックアプリは静的コンテンツを提供することもできますが、他のほとんどの従来のWebサーバーよりも効率が低くなります。
ほとんどのRoRセットアップでは、従来のWebサーバーとRackサーバーの両方の組み合わせを使用して、両方の機能の長所を活用しています。 Nginxは、プロキシバランシングと静的コンテンツの提供により、リクエストのリダイレクトが非常に高速です。 Unicornは、HTTPヘッダーを処理し、受信リクエストをRubyに処理するためにバランスを取ります。
この答えは他の答えを補完するものであり、説明しますなぜUnicornがその前にnginxを必要とするのか。
TL; DR nicornが通常nginxのようなリバースプロキシと一緒にデプロイされる理由は、作成者が意図的に設計し、単純化とのトレードオフを行っているためです。
まず第一に、Unicornの展開を妨げるものは何もありませんwithoutリバースプロキシ。ただし、それはあまり良い考えではありません。理由を見てみましょう。
Unicornは、Unixの哲学に従います1つのことを行い、それをうまくやる、そしてそれは高速で低遅延のクライアントを提供することです（この意味は後で説明します）オン）。 Unicornが高速、低遅延クライアント向けに設計されているという事実は、低速、高遅延クライアントではあまり良くないことを意味します。これはUnicornの弱点の1つであり、リバースプロキシが作用するところです。Unicornの前に配置され、それらを処理します遅いクライアント（これからhowが表示されます）後で）。
幸いなことに、このようなリバースプロキシは既に存在し、 nginx と呼ばれます。
高速クライアントのみを処理するという決定により、Unicornの設計が大幅に簡素化され、展開部門の複雑さが増します（つまり、Unicornに加えてnginxも展開する必要があります）。
別の決定として、リバースプロキシを必要としないような方法でUnicornを設計することもできます。ただし、これは、nginxが現在行っているすべてのことを行うために追加の機能を実装する必要があることを意味し、より複雑なコードベースとより多くのエンジニアリング努力をもたらします。
代わりに、その作成者は、バトルテスト済みで非常に適切に設計された既存のソフトウェアを活用し、他のソフトウェアによってすでに解決された問題に時間とエネルギーを浪費しないように決定しました。
しかし、技術的な質問をして、質問に答えましょう。
Unicornをnginxと一緒に展開する必要があるのはなぜですか？
主な理由は次のとおりです。
UnicornはクライアントにブロッキングI/Oを使用します
リバースプロキシに依存するということは、Unicornが非ブロッキングI/Oを使用することをneedしないことを意味します。代わりに、プログラマが従うのが本質的に単純で簡単なブロッキングI/Oを使用できます。
[〜＃〜] design [〜＃〜] ドキュメントの状態として：
[ブロッキングI/Oの使用]を使用すると、Rubyインタープリターおよびより少ないsyscalls内でより単純なコードパスをたどることができます。
ただし、これにはいくつかの結果もあります。
キーポイント＃1：ユニコーンは遅いクライアントでは効率的ではありません
（簡単にするために、Unicornワーカーが1人いる設定を想定しています）
ブロッキングI/Oが使用されるため、nicornワーカーは一度に1つのクライアントにしかサービスを提供できませんであるため、低速のクライアント（接続の遅いクライアントなど）はワーカーをより長時間ビジー状態に保ちます。 （高速クライアントが行うよりも）。それまでの間、他のクライアントはワーカーが再び空くまで待機します（つまり、リクエストがキューに蓄積されます）。
この問題を回避するには、Unicornの前にfully buffers受信リクエストandアプリケーションレスポンスを送信し、それぞれを送信します一度に（別名、スプーンフィード）Unicornとクライアントにそれぞれ。その点で、リバースプロキシは低速ネットワーククライアントからUnicornを「シールド」すると言うことができます。
幸いなことに、Nginxはこの役割の有力な候補です。何千もの同時クライアントを効率的に処理するように設計されているからです。
ネットワークレイテンシを最小限に抑えるために、リバースプロキシをUnicornと同じローカルネットワーク内（通常はUnixドメインソケット経由でUnicornと通信する同じ物理マシン内）に配置することが非常に重要です。
そのため、このようなプロキシは[fast clientの役割を効果的に果たします。UnicornはリクエストをUnicornにプロキシするため、そもそもUnicornはサービスを提供するように設計されていますfast可能な限り最短の時間（接続が遅いクライアントが行う時間と比較して）。
キーポイント＃2：UnicornはHTTP/1.1キープアライブをサポートしていません
UnicornはブロッキングI/Oを使用するため、HTTP/1.1キープアライブ機能をサポートできないことも意味します。低速クライアントの永続的な接続は、利用可能なすべてのUnicornワーカーをすぐに占有するためです。
そのため、HTTPキープアライブを活用するには、リバースプロキシが使用されていることを推測します。
一方、nginxは、わずかなスレッドを使用して数千の同時接続を処理できます。したがって、Unicornのようなサーバーの同時実行制限（基本的にワーカープロセスの量に制限されている）はありません。つまり、永続的な接続を適切に処理できます。これが実際にどのように機能するかについての詳細は こちら をご覧ください。
そのため、nginxはクライアントからキープアライブ接続を受け入れ、通常はUnixソケットを介したプレーン接続を介してUnicornにプロキシします。
ポイント＃3：ユニコーンは静的ファイルの提供があまり得意ではありません
繰り返しますが、静的ファイルの提供は、Unicorn canが行うことですが、効率的に行うようには設計されていません。
一方、nginxのようなリバースプロキシははるかに優れています（つまり、 sendfile(2) ＆キャッシング）。
もっと
[〜＃〜] philosophy [〜＃〜] ドキュメントで概説されている他のポイントがあります（「リバースプロキシによるパフォーマンスの改善」を参照）。
nginxの基本機能 も参照してください。
既存のソフトウェア（nginxなど）を活用し、Unixの「1つのことを行い、それをうまくやる」という哲学に従うことで、UnicornはRackアプリ（例：あなたのRails app）。
詳細については、Unicornの philosophy および design ドキュメントを参照してください。これらのドキュメントでは、Unicornの設計の背景にある選択肢と、nginxがUnicornの優れたリバースプロキシと見なされる理由について詳しく説明しています。
Nginxを使用すると、低速クライアントがUnicornサーバーを停止するため、Unicornサーバー上の低速クライアントにサービスを提供できます。 Nginxは、低速クライアントへのすべての要求と応答をバッファリングするプロキシの一種として使用されます。
http://Unicorn.bogomips.org/ を参照してください