基于机架的 Web 服务器是否代表 FastCGI 协议？

Question

我读过 CGI/FastCGI 是一种用于将外部应用程序连接到 Web 服务器的协议。因此，Web 服务器（如 Apache 或 NginX）通过套接字将环境信息和页面请求本身发送到 FastCGI 进程，并且 FastCGI 通过同一连接将响应返回给 Web 服务器，Web 服务器随后将该响应传递给最终用户。

现在我在这个和 Rack 之间感到困惑，几乎所有的 Ruby web 框架和库都使用它。它通过包装 HTTP 请求和响应，为在 Ruby 中开发 Web 应用程序提供了一个接口。

那么，像 Unicorn、Thin、Passenger 或 Puma 这样的基于机架的 Web 服务器是否代表了相同的 FastCGI 方法？我可以说 Unicorn 是 FastCGI 的 Ruby 实现吗？

Answer 1

正如你所说，FastCGI 是一个协议，而 Rack 是一个 API。所以这实际上是两个完全不同的东西，尽管它们可以一起使用。

FastCGI 作为一种协议，指定了两个不同的进程（名义上是 Web 服务器和应用程序服务器或“FastCGI 服务器”）应该如何通过网络连接相互通信。该规范定义了由两个进程发送和接收的特定格式的数据记录。

发送和接收这些消息的程序究竟是什么样的没有指定，可以是任何东西。一方面，你可能有一个 C 程序，它在内存中组装数据，然后进行系统调用让操作系统发送数据，另一方面，你可能有一个 Ruby 程序，它打开一个套接字，将数据读入数组，然后解析这些数据，并构建一个封装请求的新对象。

另一方面，作为Ruby API 规范的Rack精确地指定了哪些 Ruby 对象和方法必须可供实现某种 Web 应用程序的高级软件使用，以及这些对象和方法必须如何表现，从角度来看应用程序。（不要被上面链接的文档中“协议”一词的使用所迷惑。这里使用的不是通过通信链接发送的数据格式，而是概念性的面向对象编程意义上的“消息”在对象之间交换以表达程序行为，尽管这实际上是在不同级别和时间实现为函数调用。）

作为一个 API 规范，当 Rack API 的用户调用 Rack 实现所呈现的各种对象的方法时，它至少应该表现得好像它不知道引擎盖下发生了什么。（通常它不知道。）可能的情况是，该库实际上已经通过 FastCGI 或其他协议与充当 Web 服务器的单独进程建立了通信，并从其他进程读取消息并将消息发送回它，基于使用 API 实现的应用程序的功能。但另一方面，你同样可以（至少在理论上）使用完全不同的 API 实现，它本身具有运行 Web 服务器的 Ruby 代码，

所以不，你不能说 Unicorn（或 Rack API 的任何其他实现）是“FastCGI 的 Ruby 实现”；问这样的问题实际上是错误的，因为 Rack API 规范的重点是您明确避免考虑通过该 API 提供的服务的实际实现。很可能某些实现正在使用 FastCGI，但您的应用程序应该与一个不使用 FastCGI 的应用程序同样良好地工作，而且您真的不想关心幕后发生的事情。