基于机架的Web服务器代表FastCGI协议吗？ [英] Are Rack-based web servers represent FastCGI protocol?

问题描述

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

I've read that CGI/FastCGI is a protocol for interfacing external applications to web servers. so the web server (like Apache or NginX) sends environment information and the page request itself to a FastCGI process over a socket and responses are returned by FastCGI to the web server over the same connection, and the web server subsequently delivers that response to the end-user.

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

Now I'm confused between this and Rack, which is used by almost all Ruby web frameworks and libraries. It provides an interface for developing web applications in Ruby by wrapping HTTP requests and responses.

因此，基于机架的Web服务器（如Unicorn，Thin，Passenger或Puma）代表吗？相同的FastCGI方法？我可以说Unicorn是FastCGI的Ruby实现吗？

So, Is Rack-based web-servers like Unicorn, Thin, Passenger or Puma represents the same FastCGI approach? Can I say that Unicorn is a Ruby implementation of FastCGI ?

推荐答案

正如您所说，FastCGI是协议，而Rack是API。因此，尽管它们可以一起使用，但实际上它们是两个截然不同的东西。

As you say, FastCGI is a protocol, and Rack is an API. So these are actually two quite different things, though they could be used together.

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

FastCGI, as a protocol, specifies how two different processes (nominally a web server and an application server or "FastCGI server") should talk to each other over a network connection. The specification defines records of data in a particular format that are sent and received by the two processes.

确切地说，发送和接收这些程序的程序是什么消息看起来好像未指定，可能是任何东西。一方面，您可能有一个C程序，该程序将数据存储在内存中，然后进行系统调用以使OS发送数据；另一方面，您可能有一个Ruby程序，该程序打开一个套接字，将数据读入Array，然后解析这些数据，并构建一个封装请求的新对象。

Exactly what the programs that send and receive these messages look like is not specified, and could be anything. On one side you might have a C program that assembles data in memory and then makes system calls to have the OS send the data, and on the other side you might have a Ruby program that opens a socket, reads in data in to Arrays, and then parses those data, and builds a new object encapsulating the request.

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

On the other hand, Rack, being a Ruby API specification specifies precisely what Ruby objects and methods must be made available to higher-level software implementing some sort of web application, and how those objects and methods must behave, from the point of view of the application. (Don't be confused by the use of the word "protocol" in the document linked above. Here it's used not in the sense of data formats as sent over a communications link, but in the object-oriented programming sense of the conceptual "messages" exchanged between objects to express program behaviour, though this is actually at various levels and times implemented as function calls.)

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

Being an API specification, the user of the Rack API ought at least behave as if it has no idea what's going on underneath the hood when it calls methods on the various objects an implementation of Rack presents. (Frequently it will have no idea.) It could be the case that the library actually has set up communication with a separate process acting as a web server, via FastCGI or some other protocol, and reads messages from the other process and sends messages back to it, based on what the application using the API implementation does. But on the other hand, you could equally (at least in theory) drop in a completely different implementation of the API that itself has Ruby code to run a web server, and the very same process that ran Ruby code for the web application would be running additional Ruby code to talk the HTTP protocol directly with a client web browser or whatever.

因此，不能，您不能说Unicorn（或其他任何实现） Rack API）是 FastCGI的Ruby实现；提出这样的问题实际上是错误的，因为Rack API规范的重点是您明确地避免考虑通过该API提供的服务的实际实现。可能是某些实现使用的是FastCGI，但您的应用程序应该可以与其他应用程序同样良好地运行，并且您真的不想关心引擎盖下的情况。

So no, you can't say that Unicorn (or any other implementation of the Rack API) is a "Ruby implementation of FastCGI"; it's actually wrong to ask such a question because the whole point of the Rack API specification is that you explicitly avoid thinking about the actual implementation of the services provided through that API. It could well be that some implementations are using FastCGI, but your application should work equally well with one that's not, and you really don't want to care about what's going on underneath the hood.

这篇关于基于机架的Web服务器代表FastCGI协议吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！