この回答は他の回答を補足するものであり、ユニコーンがその前にnginxを必要とする理由を説明しています。
TL; DR Unicornが通常nginxのようなリバースプロキシと一緒に展開される理由は、その作成者が故意に設計したものであり、単純化と引き換えにトレードオフを行うためです。
まず第一に、リバースプロキシなしで Unicorn を展開することを妨げるものは何もありません。しかし、それはあまり良い考えではありません。その理由を見てみましょう。
Unicornは、1つのことをうまく実行するというUnixの哲学に従っています。これは、高速で低レイテンシのクライアントにサービスを提供することです（これについては後で説明します）。Unicornが高速で低レイテンシのクライアント用に設計されているという事実は、低速で高レイテンシのクライアントにはあまり適していないことも意味しています。これはユニコーンの弱点の1つであり、リバースプロキシが機能する場所です。リバースプロキシはユニコーンの前に位置し、これらの遅いクライアントを処理します（後で説明します）。
幸い、このようなリバースプロキシは既に存在しており、nginxと呼ばれています。
高速なクライアントのみを処理するという決定により、Unicornの設計が大幅に簡素化され、コードベースがはるかにシンプルで小さくなりますが、展開部門の複雑さが増します（つまり、Unicornに加えてnginxも展開する必要があります）。
代替の決定は、リバースプロキシを必要としないような方法でユニコーンを設計することです。ただし、これは、nginxが実行するすべての処理を実行するために追加の機能を実装する必要があり、その結果、コードベースが複雑になり、エンジニアリングの労力が増えることを意味します。
代わりに、その作成者は、十分にテストされ、十分に設計された既存のソフトウェアを活用し、他のソフトウェアによって既に解決されている問題に時間とエネルギーを浪費しないように決定しました。
しかし、技術的になって、あなたの質問に答えましょう：
Unicornをnginxと一緒に展開する必要があるのはなぜですか？
主な理由は次のとおりです。
UnicornはクライアントにブロッキングI / Oを使用します
リバースプロキシに依存しているということは、ユニコーンがノンブロッキングI / Oを使用する必要がないことを意味します。代わりに、プログラマーが本質的に単純で簡単なブロックI / Oを使用できます。
また、設計ドキュメントには次のように記載されています。
[ブロッキングI / Oの使用]により、Rubyインタープリター内でたどるコードパスを簡素化し、syscallを減らすことができます。
ただし、これにはいくつかの影響もあります。
キーポイント＃1：ユニコーンは遅いクライアントでは効率的ではない
（簡単にするために、ユニコーンワーカーが1人のセットアップを想定しています）
ブロッキングI / Oが使用されているため、Unicornワーカーは一度に1つのクライアントしか処理できません。そのため、遅いクライアント（つまり、接続が遅いクライアント）は、（速いクライアントが行うよりも）長時間にわたってワーカーをビジー状態に保ちます。 ）。その間、他のクライアントはワーカーが再び解放されるまで待機します（つまり、リクエストがキューに蓄積されます）。
この問題を回避するために、ユニコーンの前にリバースプロキシが展開されます。リバースプロキシは、着信要求と アプリケーション応答を完全にバッファーし、それぞれを一度に（別名スプーンフィードで）ユニコーンとクライアントにそれぞれ送信 します。その点で、リバースプロキシはUnicornを低速のネットワーククライアントから「シールド」すると言えます。
幸い、Nginxは、何千もの数の同時クライアントを効率的に処理するように設計されているため、この役割の優れた候補です。
リバースプロキシがUnicornと同じローカルネットワーク内（通常、Unixドメインソケットを介してUnicornと通信する同じ物理マシン内）にあることが非常に重要です。これにより、ネットワーク遅延が最小限に抑えられます。
したがって、このようなプロキシは、 ユニコーンが最初にサービスを提供するように設計されている高速クライアントの役割を効果的に果たします。これは、ユニコーンへのリクエストを高速にプロキシし、ワーカーのビジー状態を可能な限り最短時間（クライアントの時間と比較して）にするためです。遅い接続では十分です）。
キーポイント＃2：UnicornはHTTP / 1.1キープアライブをサポートしていません
ユニコーンはブロッキングI / Oを使用するため、遅いクライアントの永続的な接続は使用可能なすべてのユニコーンワーカーをすぐに占有するため、HTTP / 1.1キープアライブ機能をサポートできないことも意味します。
したがって、HTTPキープアライブを活用するには、リバースプロキシを使用する必要があります。
一方、nginxは、数スレッドのみを使用して数千の同時接続を処理できます。したがって、Unicornのようなサーバーの同時実行制限（ワーカープロセスの数に本質的に制限されている）はありません。つまり、永続的な接続を適切に処理できます。これが実際にどのように機能するかについては、こちらをご覧ください。
そのため、nginxはクライアントからのキープアライブ接続を受け入れ、通常のUnixソケット経由のプレーン接続を介してそれらをUnicornにプロキシします。
ポイント＃3：ユニコーンは静的ファイルの提供があまり得意ではない
繰り返しますが、静的ファイルの提供はUnicorn が実行できることですが、効率的に実行するようには設計されていません。
一方、nginxのようなリバースプロキシは、はるかに優れています（つまり、sendfile(2)キャッシュ）。
もっと
PHILOSOPHYドキュメントで概説されている他のポイントがあります（「リバースプロキシによるパフォーマンスの向上」を参照）。
nginxの基本機能の一部もご覧ください。
Unicornは、既存のソフトウェア（nginx）を活用し、Unixの「1つのことをうまく実行する」という哲学に従って、ラックアプリ（例： Railsアプリ）。
詳細については、Unicornの設計の背後にある選択、およびnginxがUnicornの優れたリバースプロキシと見なされる理由をより詳細に説明するUnicornの哲学および設計ドキュメントを参照してください。
