NginxとGunicornのようなものが必要なのはなぜですか？
私は次の質問に対する過度に単純化された答えを探しています。私はNginxがGunicornのようなものと一緒にどのように機能するかについての基礎的な理解を構築しようとしています。
DjangoアプリをNginxにデプロイするには、NginxとGunicornのようなものが必要ですか？
もしそうなら、実際にHTTPリクエストを処理するのは何ですか？
Ps。 Apacheとmod_wsgiを使いたくない！
過度に単純化：Pythonを実行するものが必要ですが、Pythonはすべてのタイプのリクエストを処理するのに最適ではありません。
[免責事項：私はGunicorn開発者です]
あまり単純化されていない：使用するアプリサーバー（Gunicorn、mod_wsgi、mod_uwsgi、cherrypy）に関係なく、重要なデプロイメントには、Djangoアプリが許可しないリクエストを処理する上流の要素が含まれます。このようなリクエストの簡単な例は、静的アセット（images/css/js）を提供することです。
これにより、古典的な「3層アーキテクチャ」の最初の2つの層ができます。つまり、ウェブサーバー（あなたの場合はNginx）が画像や静的リソースに対する多くのリクエストを処理します。動的に生成する必要のあるリクエストは、アプリケーションサーバー（例ではGunicorn）に渡されます。 （余談ですが、3つの層の3番目はデータベースです）
歴史的に言えば、これらの各層は別々のマシンでホストされていました（そして、最初の2つの層には複数のマシンが存在する可能性が高いです。
現代では、現在、あらゆる形状とサイズのアプリケーションがあります。毎週末のプロジェクトや小規模ビジネスサイトが実際に複数のマシンの処理能力を必要とするわけではなく、単一のボックスで非常に満足して動作します。これにより、ホスティングソリューションの配列に新しいエントリが生まれました。一部のソリューションは、アプリサーバーとWebサーバーを結合します（Apache httpd + mod_wsgi、Nginx + mod_uwsgiなど）。また、これらのWebサーバーとアプリサーバーの組み合わせの1つと同じマシンでデータベースをホストすることも珍しくありません。
ここでGunicornの場合、Nginxのプロキシ動作に依存しながら、物事をNginxから分離するように特定の決定（RubyのUnicornからのコピー）を行いました。具体的には、Gunicornがインターネットから直接接続を読み取らないと想定できる場合は、遅いクライアントについて心配する必要はありません。これは、Gunicornの処理モデルが非常に単純であることを意味します。
この分離により、Gunicornを純粋なPython=で記述することもできます。これにより、パフォーマンスに大きな影響を与えずに開発コストを最小限に抑えることができます。また、ユーザーが他のプロキシを使用できるようになります（それらが正しくバッファリングされている場合）。
実際にHTTPリクエストを処理するものについての2番目の質問については、簡単な答えはGunicornです。完全な答えは、NginxとGunicornの両方が要求を処理することです。基本的に、Nginxはリクエストを受信し、それが動的リクエスト（通常はURLパターンに基づく）の場合は、そのリクエストをGunicornに送信し、Gunicornがリクエストを処理してから、Nginxにレスポンスを返し、Nginxが元のレスポンスを転送します。クライアント。
最後に、はい。適切なDjangoデプロイメントにはNginxとGunicorn（または類似の何か）の両方が必要です。特にホストDjango Nginxを使用している場合は、 Django側の候補として、Gunicorn、mod_uwsgi、そして多分CherryPyを調査してください。
私はその単純さでこの説明が好きでした：
Nginxは外の世界に直面します。メディアファイル（画像、CSSなど）をファイルシステムから直接提供します。ただし、Djangoアプリケーションと直接通信することはできません。アプリケーションを実行し、Webからリクエストを送り、応答を返すためのものが必要です。
それがGunicornの仕事です。 GunicornはUnixソケットを作成し、wsgiプロトコルを介してnginxへの応答を提供します-ソケットは双方向でデータを渡します。
The outside world <-> Nginx <-> The socket <-> Gunicorn
ユニコーンは資源の浪費です。 Django上でgunicornを実行する代わりにポートでリッスンするプロキシDjangoそしてすべての上にnginxをプロキシすることができます。ベンチマークでは、 NginxはDjangoへの直接リクエストを簡単に処理できます。Gunicornは、通常の道路の上空にある高架道路（実際には低速の高架道路）にすぎません。ただ座ってリソースを食べ、ウェブサイトに電力を供給していると主張しようとするだけです。
nginxは基本的にすべてのリクエストをバッファリングし、それ自体で静的ファイルリクエストを処理します（そのように構成した場合）。そして、すべての動的コンテンツを別のサーバーにプロキシします（gunicorn/Django）。
Gunicornは、リクエストをアプリケーションに渡す以外に用途はありません。グラスから直接飲むか、ストローから限られたペースで飲むことができるストローのようなものです（ここで飲む人はジャンゴです）。そしてnginxはあなたにジュースのグラスを持ってきたウェイターです。
私はベンチマークしてこれを見つけました-gunicornあり：22k req/s gunicornなし：34k req/s
あなたのサイトは、高負荷で追加の要求/秒が必要になります。
過度に単純化した答えを探しています...
DjangoアプリをNginxにデプロイするには、NginxとGunicornのようなものが必要ですか？
もしそうなら、実際にHTTPリクエストを処理するのは何ですか？
過度に単純化された答え：
はい。
NginxとGunicornの両方。
Nginxにデプロイしているので、もちろんNginxが必要です。
WebフレームワークであるDjangoをデプロイしているので、Webサーバー（Nginx）とWebフレームワーク（Django）の間のやり取りを橋渡しするものが必要です。 Python世界では、このようなものはWSGIサーバーと呼ばれます（ただし、ミドルウェアのように考えます）。その例として、GunicornやuWSGIがあります。リクエストを処理するとき、NginxはリクエストをGunicornにプロキシしますまたはDjangoコードを呼び出し、応答を返すuWSGI。
このドキュメント とPaulの答えは、それをよりよく学ぶのに役立ちます。