我正在实现一个 fastcgi 应用程序，在阅读了 fastCGI 规范后，我发现了一个名为“请求多路复用”的功能。它让我想起了 Adobe RTMP 多路复用在协议是专有和封闭的日子里。
据我了解，多路复用允许减少创建与 FCGI 客户端的新连接的开销，有效地交织请求块，同时启用“保持活动”模型连接。后者允许通过单个连接发送多个请求。
第一个问题是我做对了吗？
下一个是 - 经过一番谷歌搜索后，我发现没有实现 FCGI 多路复用的服务器，我首先对“流行”服务器感兴趣，我的意思是 nginx 和 lighttpd。我什至发现了一些关于弃用 FCGI 请求多路复用的讨论。
所以问题是 - 是否有任何服务器支持此功能？
Trying to state the answers above more precisely (and correct some parts)...
multiplexing allows to reduce overhead of creating new connections to FCGI clients effectively interweaving requests chunks
In opposite to keep-alive it reduces new connections drastically, especially on high-load servers or if micro-servicing (a lot of micro requests) in usage. Futhermore it is almost required in case of balancing across network (so one cannot use unix-sockets anymore and the connection buildup process gaining more and more priority).
and at the same time enabling "keep-alive" model to connection
Although the multiplexing is not required for keep-alive, but keep-alive is almost required for multiplexing (otherwise it would make little sense).
I've found there's no server that implements FCGI multiplexing
There is few servers that supports multiplexing out of the box, but...
I saw already several modules of other devs and I have own fcgi-module for nginx (as replacement) that supports FastCGI multiplex requests.
It can show the real performance increase in the practice, especially if the upstreams are connected over the network.
If someone needs it, I will try to find time and make it available on github etc.
[from answer above] FastCGI multiplexing is generally a bad idea, because FastCGI doesn't support flow control. That means: If a FastCGI backend sends data, but the http client can't receive data fast enough, the web server has to save all those data, until they can be sent to the client.
This is not true. Normally the FastCGI handlers are fully asynchronous, pool of workers is separated from the delivering workers, etc. So each chunk gets a request-id, so if two or more upstream workers write to single connection simultaneously, the chunks that nginx will get are just smaller. That is the single cons. As regards the "the web server has to save all those data", it does this in any case (regardless multiplexing used or not), because otherwise one can get out-of-memory situation if too many pending data available for response. So either the backend should produce fewer data (or be thwarted) or the web-server should receive it as soon as possible and transmit it to client or save it to some interim storage (and for example nginx does this if pending data size exceeds the values configured with fastcgi_buffer_size and fastcgi_buffers directives).
[from answer above] When using multiplexing the web server needs to read all data from the fastcgi backend, even though one of the clients isn't receiving data fast enough.
Also this is false. The web-server has to read only the single chunk of response to the end, and good worker pools have "intelligent" handling, so automatically sends the chunks to the web-server as soon as possible (means if it gets available), so if multiple content-providers write to so-called "reflected" channels of the same real connection, the pending packets will be separated and chunks received from nginx as soon as the response data is available. Thereby almost only the throughput of the connection is crucial, and it does not matter at all how fast the clients will receive the data. And again, multiplexing saves vastly the time of the connection buildup, so reduces number of pending requests as well as the common request execution time (transaction rate).
问：多路复用允许减少创建与 FCGI 客户端的新连接的开销，有效地交织请求块
答：没错。但是keep-alive也在减少新的连接。
Q：同时启用“keep-alive”模型连接
A：keep-alive不需要多路复用。
问：后者允许通过单个连接发送多个请求
A：keep-alive 允许多个请求一个接一个。多路复用允许并行的多个请求。
没有广泛使用的支持多路复用的支持 FastCGI 的 Web 服务器。但是 nginx 支持 FastCGI keep-alive。
FastCGI 多路复用通常不是一个好主意，因为 FastCGI 不支持流控制。这意味着：如果 FastCGI 后端发送数据，但 http 客户端无法足够快地接收数据，则 Web 服务器必须保存所有这些数据，直到它们可以发送到客户端。
当不使用多路复用时，如果 http 客户端速度太慢，Web 服务器可能无法从 fastcgi 后端读取数据，从而有效地积压了 fastcgi 后端。使用多路复用时，Web 服务器需要从 fastcgi 后端读取所有数据，即使其中一个客户端接收数据的速度不够快。
我不知道某些服务器是否实现了 FASTCGI 多路复用（我相信您理解正确，但详细信息在 FASTCTI 协议规范中），我不会打扰。
您很可能会通过现有的 FASTCGI 库使用 FASTCGI （例如，如果您在 Ocaml 中编码，则为 Ocamlnet等）。如果它这样做，该库将进行多路复用。从您（该库用户）的角度来看，您不应该真正关心，除非您自己编写这样的库。
如果 FASTCGI 多路复用困扰您，您可以使用SCGI协议，它提供类似的功能，但更简单、效率稍低且非多路复用。