nginx 和 Perl：FastCGI 与反向代理（PSGI/Starman）答案

【问题标题】：nginx and Perl: FastCGI vs reverse proxy (PSGI/Starman)nginx 和 Perl：FastCGI 与反向代理（PSGI/Starman）
【发布时间】：2010-10-23 11:20:50
【问题描述】：

如今运行 Perl Web 应用程序的一个非常流行的选择似乎是在 nginx 网络服务器后面，该服务器将请求代理到 FastCGI 守护程序或启用 PSGI 的网络服务器（例如 Starman）。

关于为什么一般人会这样做的问题很多（例如Why use nginx with Catalyst/Plack/Starman?）并且答案似乎在这两种情况下都适用（例如，允许 nginx 提供静态内容、轻松重启应用服务器、负载平衡等）

但是，我对使用 FastCGI 与反向代理方法的优缺点特别感兴趣。似乎 Starman 被广泛认为是最快和最好的 Perl PSGI 应用程序/Web 服务器，我很难看到使用 FastCGI 的任何优势。这两种方法似乎都支持：

同样，任一选项的 nginx 配置都非常相似。

那么为什么你会选择一个而不是另一个呢？

【问题讨论】：

【解决方案1】：

反向代理设置（例如 nginx 将 HTTP 请求转发给 Starman）具有以下优点：

但是，它有以下缺点：

后端服务器必须找出真正的原始 IP，因为它所看到的只是前端服务器地址（通常是 localhost）；几乎有一种简单的方法可以在 HTTP 标头中找出客户端 IP 地址，但这是需要弄清楚的额外内容；
后端服务器通常不知道原始的“Host:” HTTP 标头，因此无法自动生成本地资源的绝对 URL； Zope 使用特殊的 URL 解决了这个问题，将原始协议、主机和端口嵌入到后端的请求中，但这与 FastCGI/Plack/... 无关；
前端无法自动生成后端进程，例如它可以使用 FastCGI。

选择你最喜欢的优点/缺点并做出你的选择，我猜 ;-)

【讨论】：

原始客户端IP地址在X-Forwarded-For头中传递，原始Host头在X-Forwarded-Host头中传递，所以前两个缺点并不重要。
+1 感谢您的比较。由于可以运行一个主进程来管理后端进程和线程，因此第 3 点不成问题。您提出了一个关于 Zope 的有趣观点以及了解原始客户端 IP 和主机名以构建有效 URL 的方法

【解决方案2】：

HTTP 为大多数系统管理员所熟知，并且易于调试。几乎总是已经部署了某种反向代理，因此只需将另一个配置节添加到其配置中以便在几秒钟内启动并运行您的应用程序是小菜一碟。从未测试过两种设置的速度差异，但另一方面，我在该区域从未遇到任何问题，所以它不会那么糟糕。

【讨论】：