Rails的部署方案中，有一种是Apache作为Reverse Proxy，把请求转发给应用服务器（比如说Phusion Passenger）。Apache作为反向代理服务器，是如何与后面的应用服务器交互的？
比如我的Apache监听1080端口，查了一下进程信息：
> ps aux | grep /MyWebsite/bin/httpd
googly 8353 0.0 0.0 73856 3280 ? Ss Aug26 0:00 /MyWebsite/bin/httpd -d /MyWebsite -f var/state/apache-1080/httpd.conf
googly 8391 0.0 0.0 73856 1828 ? S Aug26 0:00 /MyWebsite/bin/httpd -d /MyWebsite -f var/state/apache-1080/httpd.conf
... # 起了10个进程，并且我知道8353是父进程，其余的是子进程
当一个请求到来，首先会到Apache，Apache会从这些进程中分配一个进程来处理这个请求（比如分配了8391这个进程），那么8391这个进程会做什么呢？他是会把这个请求转发给后面的应用服务器（Phusion Passenger）吗？如果是这样，那么应用服务器是不是也有自己独立的进程？还是说8391这个进程就已经可以当成是应用服务器的进程了，他自己就能处理这个请求？
Apache是如何与挂在他后面的应用服务器交互的呢？
看到这个问题很久了当时没有回答，现在来回答一下。
Rails是自带web服务器的，负责监听特定端口提供服务。
ruby语言是有http相关api的，你甚至可以自己写一个简略的静态文件服务器。而且有许多强大的gem提供类似服务。
Apache是专业的http服务器，原则上只能够响应最基础的静态文件。
PHP语言在Apache下的最普遍运行方式是作为它的插件，换句话说就是把Apache变的可以响应php文件请求了。
用Apache搭配Phusion Passenger来部署Rails应用主要是为了有更加优雅的错误提示和自动化的错误处理（主要是重启），还有更加完善的日志系统以及高级功能如负载均衡等。
而用rails s或者thin等web服务器来启动服务也是完全可以的，只是不管是对浏览者还是对开发者而言，都没有那么好用而已。
如果你不需要自动错误处理其实用nginx反向代理rails s或者thin的端口是最好的选择。
你起了apache之后它就会有十几二十个进程起来（这要看你的配置了）
然后在apache收到request之后有一个进程会处理它，如果它符合反向代理的条件，就会把request发送到你的应用服务器
其实应用服务器应该也是能够直接访问的（除非有什么防火墙啊之类的）
反正就是应用服务器收到了request，然后传回一个response给apache
apache再把response传回给浏览器
不过在这过程中可能还需要配置下对于response中间的html里面的url的改写
如果你配置的是反向代理的话，那么 Apache 接下来会充当一个 HTTP 客户端，以把同样的请求发给应用服务器，得到结果之后再发给真正的客户端。