How rails applications actually work? Let's say we have nginx + passenger + Ubuntu, so my questions are:
Please dont give me answers like "nginx processes the requests"; I need something more, or may be you know the source where I can read about this.
It will help to understand the story this way:
Long time ago, when the web was new, there were only static pages - just .html pages. So a webserver software would efficiently read a file and send the contents of the file to the requester (a browser).
Then came the dynamic web. Here the contents of the page had to be dynamically generated on the fly, in response to the request. This meant, there had to be some program running on the server, which understood what is being requested and what should go as response. That resulted in the birth of CGI (Common Gateway Interface). Instead of reading a .html file and sending its contents to the client, now you execute a CGI program on the server which will spew out the html that can be sent to the requestor. These CGI scripts could be written in various programming languages.
With growing complexity of the CGI scripts, there was a need to have specialized helper applications which abstract out all the common (and mechanical) logic. This would simplify writing business logic. These specialized helpers are generally called application servers or containers.
These containers also help in keeping the web server simple and lean, since the complexity of executing a cgi script (no matter which programing language it was written in) is now delegated out of the web server. All the web server needs to know is, if the request url ends in a .php, then it should delegate the request to FASTCGI, or if the URI begins with /javaapp/ then delegate it to tomcat etc. Let us call these helper applications as APP SERVERS or Container
Passenger, is one such container, which is designed to run a RACK application.
What is Rack: You can say, Rack is a standardized interface for the container to load an application (such as a Rails application), just like CGI is a standardized interface for the web server to execute an external program,
Rack defines a standard interface for the application frameworks (rails, merb, sinatra etc.). If an application framework complies with rack interface, the container knows how to load and execute it.
Note:
I have tried to super simplify the concepts for you. This is no way closer to being a complete explanation. Hope this is good enough to get you started on self study.
Phusion Passenger author here. I think these two documents explain most of your questions in detail.
As for Rack: it is a standardized interface. Different web servers tend to have different APIs for dynamic applications. In order to avoid needing every Ruby framework to write an adapter for every single server, all Ruby frameworks all implement the Rack interface. All servers, in turn, speak Rack as well. This allows you to switch between different servers without needing the framework to have special support for that server, and allows you to switch between different frameworks without needing the server to have special support for that framework.
How does WEBRick serve Rails? When you start WEBrick, it opens a TCP socket on some port and listens for connections on it. When a new connection comes in, it parses the data as HTTP, creates internal data structures, and passes these data structures to Rails by calling the Rails Rack object. The Rails Rack object is the main entry point into Rails, and is created during program startup. When the Rack object returns, WEBrick converts the returned data structures to HTTP data and writes them over the socket.
This high-level describes describes pretty much how every Ruby server works. Phusion Passenger also works like this at a high level, but there are more steps involved with regard to, for example, process management, load balancing, security checking, etc. Phusion Passenger handles most stuff out-of-process while WEBrick is an entirely in-process library. The Phusion Passenger architectural overview document explains it.
