我了解 FastCGI 在性能方面优于其他网关接口的目的。但是，如果实现 FastCGI 的库已经不得不通过艰苦的措施来实现安全高效的 TCP 服务，为什么不直接将应用程序编写为 Web 服务器呢？前端 Web 服务器实现反向代理的效率是否比 FCGI 低？还是 FCGI 的规范比 HTTP 简单得多？
【问题讨论】：
标签： fastcgi
我有一个 Web 服务器程序，我用 FCGI 程序替换了它。我这样做的部分原因是因为程序的要求。它需要在现有的 Web 服务器下运行，因为这样做不需要额外的配置。
另一个要求是它能够跟踪一些经常变化的状态值。现有程序效率不高，在外部跟踪这些状态值并为每个请求重新加载它们。 FCGI 程序的一个优点是它是持久的，因此它可以轮询这些状态值，并且它们将可用并为每个请求做好准备。
我不必实现任何 FCGI 规范，我只是使用了现有的 FCGI 库，它为我处理了与 Web 服务器的所有通信。与我编写的其他具有嵌入式 Web 服务器的应用程序相比，使用 FCGI 库实现一个相对简单。
FCGI 的另一个优点是 FCGI 应用程序不需要实际驻留在 Web 服务器可访问的磁盘上。您可以将服务器配置为与另一台服务器上的 FCGI 应用程序实例建立 TCP 连接。如果您无法直接访问 Web 服务器，这将非常有用。用其他方法完成同样的事情可能很麻烦，但 FCGI 应用程序甚至不需要修改。只需配置服务器，在 FCGI 主机下启动您的应用程序，就可以开始了。
FCGI 的另一个优点是您可以配置 Web 服务器以在预设数量的应用程序实例之间分发请求。如果您的 Web 应用程序通过同步处理每个请求而工作得最好，那么 FCGI 是理想的，因为您可以将每个请求集中到一个实例中，并且该实例可以在一个循环中处理每个请求。如果您最多需要 2、3 或 n 个实例，您只需更改服务器上的值即可。
因此，FCGI 并非适用于所有情况。当您面临不同寻常的要求时，FCGI 最有吸引力。
【讨论】：