FCGI_LISTENSOCK_FILENO在FCGI应用中的作用

Question

我阅读了fcgi规范，但在理解以下内容之间的通信方式方面仍然存在问题：

web-Server <-> FCGI-Server <-> Application

很管用。FastCGI规范声明，“Web”留下一个文件描述符FCGI_LISTENSOCK_FILENO (0)，可用于读取fcgi-包。但是，如果FCGI生活在与how服务器不同的服务器上，该如何工作呢？这听起来就像规范假设的那样，fcgi进程托管在与web服务器相同的系统上，或者混淆web服务器和fcgi-server。

这是我目前对的理解：

1. Web接收一个HTTP请求并启动一个指向预先配置好的套接字/网络地址的fcgi请求，比方说：192.168.20.2:9090。
2. /Server在端口9090上侦听传入请求并接受连接。没有规范规定的FCGI_LISTENSOCK_FILENO，也没有Web创建的文件描述符/套接字。fcgi服务器在没有任何预先存在的套接字的情况下这样做。它负责数据的多路复用。
3. 如果FCGI本身没有实现一个应用程序，充当响应程序的服务器将生成一个新进程，并将stdin发送到FastCGI服务器。如果CGI应用程序将某些内容写入标准输出，则FastCGI进程将数据封装在fcgi-数据包中。

生命周期到底是如何工作的？参与的是哪一方？FCGI_LISTENSOCK_FILENO在哪里发挥作用？为什么规范说web服务器留下了一个套接字/fd，应用程序应该在这个套接字上调用Accept()。对我来说，这是完全没有意义的，因为如果web服务器创建一个侦听套接字，另一端必须调用connect来建立连接，但是通常web服务器负责建立FCGI连接。FCGI(/Application)只通过调用Accept()来响应连接请求。

Answer 1

当我阅读规范并试图充分理解FastCGI时，我也感到非常困惑。我想我想明白了。

规范假定FastCGI应用程序是独立的可执行文件，类似于经典的CGI可执行文件，这些可执行文件在预定义的描述符数字上生成并接收套接字(对于CGI，描述符0和1，而对于FastCGI描述符0，则不同之处在于FastCGI可执行文件在给定套接字上的寿命很长，并期望在给定套接字上调用accept()，然后在产生的套接字上使用二进制协议)。

但是规范确实说明了FastCGI可执行文件是由Web服务器(特别是内置到Web服务器中的FastCGI流程管理器)或外部FastCGI流程管理器生成的。实际上，如果FastCGI可执行文件是在FCGI_WEB_SERVER_ADDRS中传递的允许Web服务器IP的成员，则需要检查从accept()返回的连接的对等IP地址。此场景仅在外部FastCGI流程管理器生成可执行文件时发生。

外部FastCGI进程管理器的工作方式是:在启动时创建TCP或Unix域套接字(接收来自Web服务器的连接)，对该套接字执行侦听()操作，并使用作为描述符0传递的套接字生成FastCGI可执行文件(在启动期间或在第一个请求中)。如果FastCGI可执行文件是单线程的(很可能是这样的)，则需要生成多个实例。不过，相同的套接字将传递给所有实例，它们将同时接受该套接字上的()连接(这是经典的Unix预叉模型)。请注意，它们在套接字上直接接受()，流程管理器实际上并不涉及数据路径。它只用于创建初始侦听套接字，并管理生成的进程的生命周期。

内部FastCGI流程管理器与Unix域套接字的工作方式类似。

对于PHP这样的现代设置，不使用上述流程管理器(外部或内部)与FastCGI可执行文件之间的分离模型，一个外部可执行文件负责侦听和处理FastCGI请求。