fastcgi 多路复用？

Posted 2023-02-16

【中文标题】fastcgi 多路复用？

【英文标题】：fastcgi multiplexing?

【发布时间】：2011-12-16 06:34:10

【问题描述】：

我正在实现一个 fastcgi 应用程序，在阅读了 fastCGI 规范后，我发现了一个名为“请求多路复用”的功能。它让我想起了 Adob​​e RTMP 多路复用在协议是专有和封闭的日子里。

据我了解，多路复用允许减少创建与 FCGI 客户端的新连接的开销，有效地交织请求块，同时启用“保持活动”模型连接。后者允许通过单个连接发送多个请求。

第一个问题是我做对了吗？

下一个是 - 经过一番谷歌搜索后，我发现没有实现 FCGI 多路复用的服务器，我首先对“流行”服务器感兴趣，我的意思是 nginx 和 lighttpd。我什至发现了一些关于弃用 FCGI 请求多路复用的讨论。

所以问题是 - 有没有支持此功能的服务器？

【参考方案1】：

我不知道有没有服务器实现 FASTCGI 多路复用（我相信你理解正确，但细节在 FASTCTI 协议规范中），我不会打扰。

您很可能会通过 existing FASTCGI library 使用 FASTCGI（例如，如果您在 Ocaml 中编码，则使用 Ocamlnet 等）。如果它这样做，该库将进行多路复用。从您（该库用户）的角度来看，您不应该真正关心，除非您自己编写这样的库。

如果 FASTCGI 多路复用困扰您，您可以使用 SCGI 协议，它提供类似的功能，但更简单、效率稍低且非多路复用。

【参考方案2】：

问：多路复用允许减少创建与 FCGI 客户端的新连接的开销，有效地交织请求块

答：没错。但是 keep-alive 也在减少新的连接。

问：同时启用“keep-alive”模型连接

A：keep-alive 不需要多路复用。

问：后者允许通过单个连接发送多个请求

A：keep-alive 允许多个请求一个接一个。多路复用允许多个请求并行。

没有广泛使用的支持多路复用的支持 FastCGI 的 Web 服务器。但是nginx支持FastCGI keep-alive。

FastCGI 多路复用通常不是一个好主意，因为 FastCGI 不支持流控制。这意味着：如果 FastCGI 后端发送数据，但 http 客户端无法足够快地接收数据，则 Web 服务器必须保存所有这些数据，直到它们可以发送到客户端。

当不使用多路复用时，如果 http 客户端太慢而有效地积压了 fastcgi 后端，则 Web 服务器可能无法从 fastcgi 后端读取数据。使用多路复用时，Web 服务器需要从 fastcgi 后端读取所有数据，即使其中一个客户端接收数据的速度不够快。

【参考方案3】：

试图更准确地陈述上面的答案（并更正某些部分）......

多路复用允许减少创建与 FCGI 客户端的新连接的开销，有效地交织请求块

与保持活动相反，它会大幅减少新连接，尤其是在高负载服务器上或使用微服务（大量微请求）时。此外，在跨网络平衡的情况下几乎需要它（因此不能再使用 unix-sockets 并且连接建立过程获得越来越多的优先级）。

同时启用“keep-alive”模型连接

虽然keep-alive不需要多路复用，但多路复用几乎都需要keep-alive（否则就没有意义了）。

我发现没有实现 FCGI 多路复用的服务器

支持开箱即用多路复用的服务器很少，但是... 我已经看到了其他开发人员的几个模块，并且我有自己的用于 nginx 的 fcgi 模块（作为替代），它支持 FastCGI 多路复用请求。 它可以显示实践中的实际性能提升，尤其是在上游通过网络连接的情况下。 如果有人需要，我会尽量找时间在 github 等上提供。

[来自上面的回答] FastCGI 多路复用通常是个坏主意，因为 FastCGI 不支持流控制。这意味着：如果 FastCGI 后端发送数据，但 http 客户端无法足够快地接收数据，则 Web 服务器必须保存所有这些数据，直到它们可以发送到客户端。

这不是真的。通常，FastCGI 处理程序是完全异步的，工作人员池与交付工作人员分开，等等。 所以每个块都有一个 request-id，所以如果两个或多个上游工作人员同时写入单个连接，nginx 将获得的块会更小。这是唯一的缺点。 至于“网络服务器必须保存所有这些数据”，它在任何情况下都会这样做（无论是否使用多路复用），否则如果有太多待处理的数据可用于响应，就会出现内存不足的情况。因此，要么后端应该产生更少的数据（或被阻止），要么网络服务器应该尽快接收它并将其传输给客户端或将其保存到一些临时存储中（例如，如果待处理的数据大小超过了使用 fastcgi_buffer_size 和 fastcgi_buffers 指令配置的值）。

[来自上述答案] 当使用多路复用时，Web 服务器需要从 fastcgi 后端读取所有数据，即使其中一个客户端接收数据的速度不够快。

这也是错误的。网络服务器必须只读取单个响应块到最后，并且好的工作池具有“智能”处理，因此会尽快自动将块发送到网络服务器（意味着它是否可用），所以如果多个内容提供者写入同一真实连接的所谓“反射”通道，则待处理的数据包将被分离，并在响应数据可用时立即从 nginx 接收块。 因此，几乎只有连接的吞吐量是至关重要的，客户端接收数据的速度并不重要。 同样，多路复用大大节省了建立连接的时间，因此减少了待处理请求的数量以及常见的请求执行时间（事务率）。