FCGI_LISTENSOCK_FILENO在FCGI应用程序中的角色

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

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

web服务器FCGI服务器应用程序

工作。声明“Web服务器”留下一个文件描述符

FCGI\u LISTENSOCK\u FILENO（0）

，可用于读取FCGI数据包。但是，如果FCGI服务器与Web服务器位于不同的服务器上，那么该如何工作呢？对我来说，这听起来像规范假设的那样，FCGI进程与web服务器托管在同一个系统上，或者将web服务器与FCGI服务器混淆

这是我目前对fcgi livecycle的理解：

Web服务器接收HTTP请求并启动fcgi请求到预配置的套接字/网络地址，例如：

192.168.20.2:9090

FastCGI应用程序/服务器在端口9090上侦听传入请求并接受连接。规范中没有规定任何

FCGI\u LISTENSOCK\u FILENO

，Web服务器也没有创建任何文件描述符/套接字。fcgi服务器在没有任何预先存在的套接字的情况下执行此操作。它负责多路输入/输出数据

如果FCGI服务器本身未实现应用程序，则作为响应程序的服务器将生成一个新进程，其中stdin、stdout通过管道传输到FastCGI服务器。如果CGI应用程序将某些内容写入标准输出，则FastCGI进程将数据封装在fcgi数据包中

---

生命周期到底是如何工作的？涉及哪些方面？

FCGI\u LISTENSOCK\u FILENO

在哪里起作用？为什么规范说web服务器留下一个socket/fd，应用程序应该在这个socket/fd上调用Accept（）。对我来说，这完全没有意义，因为如果web服务器创建一个侦听套接字，另一端必须调用connect来建立连接，但通常web服务器负责建立FCGI连接。FCGI服务器（/Application）只通过调用Accept（）响应连接请求。

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

该规范假设FastCGI应用程序是独立的可执行文件，类似于经典的CGI可执行文件，它们通过预定义的描述符编号生成并接收套接字（对于CGI，描述符0和1，对于FastCGI描述符0，不同之处在于FastCGI可执行文件是长期存在的，并且需要调用accept（）在循环中的给定套接字上，然后在生成的套接字上使用二进制协议）

但该规范确实说明了由Web服务器（特别是内置在Web服务器中的FastCGI process manager）或外部FastCGI process manager生成的FastCGI可执行文件。事实上，如果accept（）返回的连接是FCGI_Web_server_ADDRS中传递的允许Web服务器IP的成员，则需要FastCGI可执行文件来检查该连接的对等IP地址。此场景仅在外部FastCGI process manager生成可执行文件时发生

外部FastCGI process manager的工作方式是：在启动时创建TCP或Unix域套接字（用于接收来自Web服务器的连接），在该套接字上执行listen（），并生成FastCGI可执行文件（在启动期间或在第一次请求时），将该套接字作为描述符0传递。如果FastCGI可执行文件是单线程的（最有可能的情况），则需要生成多个实例。不过，相同的套接字将被传递给所有实例，它们将同时接受该套接字上的（）连接（这是典型的Unix pre-fork模型）。请注意，它们直接在该套接字上接受（），进程管理器实际上并不参与数据路径。它只用于创建初始侦听套接字并管理派生进程的生命周期

内部FastCGI进程管理器的工作原理与Unix域套接字类似

在PHP-FPM等现代设置中，不使用上述process manager（外部或内部）和FastCGI可执行文件之间的分离模型，单个外部可执行文件负责侦听和处理FastCGI请求