我正在寻找对以下问题的简单回答。 我正在努力为Nginx如何与Gunicorn一起工作build立一个基本的理解。
我是否需要Nginx和类似Gunicorn的东西来在Nginx上部署Django应用？
如果是这样，实际处理HTTP请求的是什么？
PS。 我不想使用Apache和mod_wsgi！
过于简化：你需要一些执行Python的东西，但是Python在处理所有types的请求方面并不是最好的。
[免责声明：我是Gunicorn开发人员]
简化：无论使用什么应用程序服务器（Gunicorn，mod_wsgi，mod_uwsgi，cherrypy），任何types的不重要的部署都会有上游的东西来处理Django应用程序不应该处理的请求。 这些请求的简单例子是静态资产（图像/ css / js）。
这导致了经典的“三层架构”的两个第一层。 也就是说，networking服务器（在你的情况下，Nginx）将处理许多图像和静态资源的请求。 然后将需要dynamic生成的请求传递到应用程序服务器（在您的示例中为Gunicorn）。 （另外，三层中的第三层是数据库）
从历史上看，这些层级中的每一个层级将被托pipe在不同的机器上（前两级中最有可能是多台机器，即：5台Web服务器向两台应用服务器发送请求，然后查询单个数据库）。
在现代，我们现在有各种形状和大小的应用。 并不是每个周末的项目或者小型企业的网站都需要多台机器的功率，而且在一个盒子里运行起来相当的愉快。 这已经催生了一系列托pipe解决scheme的新条目。 一些解决scheme将结婚应用服务器到Web服务器（Apache httpd + mod_wsgi，Nginx + mod_uwsgi等）。 而且，将数据库作为这些Web /应用程序服务器组合之一托pipe在同一台计算机上并不罕见。
现在在Gunicorn的情况下，我们做了一个具体的决定（从Ruby的Unicorn复制），以保持与Nginx独立，而依靠Nginx的代理行为。 具体来说，如果我们可以假设Gunicorn永远不会直接从互联网上读取连接，那么我们不必担心客户的速度很慢。 这意味着Gunicorn的处理模型是非常简单的。
分离还允许Gunicorn用纯Python编写，这样可以最大限度地降低开发成本，同时不会显着影响性能。 它还允许用户使用其他代理（假设它们正确缓冲）。
至于你关于实际处理HTTP请求的第二个问题，简单的答案是Gunicorn。 完整的答案是Nginx和Gunicorn处理请求。 基本上，Nginx会收到请求，如果它是一个dynamic的请求（通常基于URL模式），那么它会向Gunicorn发送请求，Gunicorn会处理它，然后返回一个响应给Nginx，然后将响应转发回原来的客户。
所以最后，是的。 您需要Nginx和Gunicorn（或类似的东西）才能正确部署Django。 如果你特别想用Nginx来托pipeDjango，那么我将调查Gunicorn，mod_uwsgi，也许CherryPy作为Django方面的候选者。