我正在寻找以下问题的过于简单的答案。我试图建立对 Nginx 如何与 Gunicorn 之类的工具协同工作的基本理解。
我是否需要 Nginx 和 Gunicorn 之类的东西才能在 Nginx 上部署 Django 应用程序？
如果是的话，那么实际上什么处理 HTTP 请求？
附言：我不想使用 Apache 和 mod_wsgi！
答案1
过于简单：您需要一些可以执行 Python 的东西，但是 Python 并不是处理所有类型请求的最佳选择。
[免责声明：我是 Gunicorn 开发人员]
不太简化：无论您使用哪种应用服务器（Gunicorn、mod_wsgi、mod_uwsgi、cherrypy），任何类型的非平凡部署都会有一些上游的东西来处理您的 Django 应用不应该处理的请求。此类请求的简单示例是提供静态资产（images/css/js）。
这导致了经典“三层架构”的两个第一层。即，Web 服务器（在您的例子中是 Nginx）将处理许多对图像和静态资源的请求。然后，需要动态生成的请求将传递到应用程序服务器（在您的示例中是 Gunicorn）。（顺便说一句，三层中的第三层是数据库）
从历史上看，每个层级都托管在单独的机器上（并且前两层很可能有多台机器，即：5 个 Web 服务器将请求发送到两个应用服务器，然后应用服务器查询单个数据库）。
在现代，我们拥有各种形状和大小的应用程序。并非每个周末项目或小型企业网站实际上都需要多台机器的强大功能，并且它们可以在一台机器上顺利运行。这催生了托管解决方案阵列中的新条目。一些解决方案将应用服务器与 Web 服务器结合起来（Apache httpd + mod_wsgi、Nginx + mod_uwsgi 等）。将数据库托管在与这些 Web/应用服务器组合之一相同的机器上并不罕见。
现在，就 Gunicorn 而言，我们做出了一个特定的决定（从 Ruby 的 Unicorn 复制而来），将事情与 Nginx 分开，同时依赖 Nginx 的代理行为。具体来说，如果我们可以假设 Gunicorn 永远不会直接从互联网读取连接，那么我们就不必担心客户端速度慢。这意味着 Gunicorn 的处理模型非常简单。
这种分离还允许 Gunicorn 用纯 Python 编写，从而最大限度地降低开发成本，同时不会显著影响性能。它还允许用户使用其他代理（假设它们缓冲正确）。
至于你的第二个问题，即实际上由谁来处理 HTTP 请求，简单的答案是 Gunicorn。完整的答案是 Nginx 和 Gunicorn 都处理请求。基本上，Nginx 将接收请求，如果是动态请求（通常基于 URL 模式），则它将把该请求交给 Gunicorn，后者将对其进行处理，然后向 Nginx 返回响应，然后 Nginx 将响应转发回原始客户端。
所以最后，是的。您需要 Nginx 和 Gunicorn（或类似的东西）才能正确部署 Django。如果您专门希望使用 Nginx 托管 Django，那么我会调查 Gunicorn、mod_uwsgi 以及 CherryPy 作为 Django 方面的候选者。
答案2
我喜欢这个简单明了的解释：
Nginx 将面向外部世界。它将直接从文件系统提供媒体文件（图像、CSS 等）。但是，它无法直接与 Django 应用程序对话；它需要某种东西来运行应用程序、向其提供来自 Web 的请求并返回响应。
这就是 Gunicorn 的工作。Gunicorn 将创建一个 Unix 套接字，并通过 wsgi 协议向 nginx 提供响应 - 套接字双向传递数据：
The outside world <-> Nginx <-> The socket <-> Gunicorn
答案3
我正在寻找一个过于简单的答案......
我是否需要 Nginx 和 Gunicorn 之类的东西才能在 Nginx 上部署 Django 应用程序？
如果是的话，那么实际上什么处理 HTTP 请求？
过于简单的答案：
是的。
Nginx 和 Gunicorn。
既然你是在 Nginx 上部署，当然需要 Nginx。
由于您正在部署 Django（一种 Web 框架），因此您需要某种东西来连接 Web 服务器（Nginx）和 Web 框架（Django）。在 Python 世界中，这种东西被称为 WSGI 服务器（但可以将其视为中间件），例如 Gunicorn 和 uWSGI。处理请求时，Nginx 将请求代理到 Gunicorn 或 uWSGI，后者又调用 Django 代码并返回响应。
这个文件保罗的回答将帮助您更好地学习它。
答案4
Gunicorn 浪费资源。您可以简单地将代理传递给在端口上监听的 django，而不是在 django 上运行 gunicorn，然后在所有这些之上再运行 nginx。在基准测试中，我看到了非常明显的速度提升。Nginx 可以轻松处理对 django 的直接请求。Gunicorn 只不过是普通道路上方的一座天桥（实际上是一座较慢的天桥）。它只是坐在那里消耗您的资源，并试图声称为您的网站提供支持。
nginx 基本上会缓冲所有请求并自行处理静态文件请求（如果您已这样配置）。并将所有动态内容代理到另一台服务器。（gunicorn/django）。
Gunicorn 除了将请求传递给应用程序之外没有其他用途。它就像一根吸管，你可以直接从玻璃杯中喝水，也可以以有限的速度用吸管喝水（这里喝水的人是 django）。而 nginx 是给你端来一杯果汁的服务员。
我进行了基准测试并发现了这一点 - 使用 gunicorn：22k req / s 不使用 gunicorn：34k req / s
您的网站在高负载下将需要额外的请求。