Tomcat / JVM / Servlet / Cgi 的关系？

http 服务器负责接收客户端请求，找资源，返回资源给客户端，比如 apache / nginx ，如果请求的是静态资源，比如 html / image ， http 服务器就直接找到并返回给客户端了。

这个时候如果客户端请求比如 php ， http 服务器自己无法解析 php 的文件，如果没有配置解释器那它就会直接把这个 php 的源码给展示了出来（当成了文本文件），如果 http 服务器配置了解释器，因此它知道 php 这种后缀的文件应该去请求 php-cgi ，于是它就去让 php-cgi 执行 php ， php 完成处理后把结果给 http 服务器， http 服务器把结果再给客户端。另外为了解决非编译型语言每次都初始化应用基础环境的重复工作，于是出现了 fast-cgi 的标准（ master 执行初始化后就变成常驻进程，开启 worker 来处理单个请求）， php-fpm 就是这个标准的具体实现。

那 tomcat 跟上面对比，是不是也是类似于 php-cgi 实现的一种存在？是不是这样： jsp 请求过来了， http 服务器不知道怎么解析，一看配置，需要去找 tomcat ，于是转给 tomcat ，但是 java 程序是需要 JVM 环境的，所以 tomcat 建立在 JVM 之上执行，而 tomcat 本身是个容器，需要实际的 worker 来解析 jsp ，于是就去实例化一个 servlet 来解析，最后再一层层回归到客户端。

是不是这样理解的？

求指点。。。

其实主要是在研究 ApplicationContext 发现它可以引用装载自己的 ServletContext ，因为是个 phper （世界上最好的语言，你懂的~），对这个 Servlet 有点理解不能。。。

lml12377

2016-09-03 10:48:18 +08:00

@SoloCompany 是不是像 WSGI /servlet 这种都是各自的语言自己来实现的？比如 tomcat 是 servlet 容器，那静态请求来了， tomcat 创建默认的 servlet 来处理静态请求，动态页面请求比如 .jsp 就实例化一个内含 ApplicationContext 的 servlet 去处理？因为它们都是 java 编写的，所以它们之间嵌套，并最终在 JVM 这个环境上执行。

而不是像 apache + fpm ， apache 只负责静态资源，动态资源每次申请创建新的解释器进程，通过 cgi 标准来通信。

是不是可以这样理解~

lml12377

2016-09-03 11:01:23 +08:00

@guoziyan 是不是常驻型的可以自己实现容器，容器内自己处理静态请求的同时处理动态请求，相当于它自己既充当了 http 服务器的角色，又充当了 application server 的角色（每次这么打比方都有点怕。。。）

假设我用 c 写了一个程序，本身可以处理静态请求比如 html / image ，而当用户请求 blog-list-p1.c 的时候，我还能用这个程序去连接数据库，编写可复用的组件，是不是这个就相当于 tomcat / servlet 或者 WSGI 实现的一种存在？并且还不需要 jvm 这种解释器。。。（好先进啊，你懂的。。。）

lml12377

2016-09-03 19:46:02 +08:00

@guoziyan 假设做个 php 的解释器，常驻内存，去掉比如 nginx / apache 的 http 静态资源服务器， master 负责格式化 http 请求，分发给 worker ， defaultWorker 处理静态资源，其余的处理动态 .php 请求，而现在 php 是有中间码 opcode ，是不是这样，我将来直接运行这个“高级”的解释器，它就可以处理所有的 http 请求了，甚至连 apache 和 jvm 都不需要，因为这个“高级”的解释器都是内含的？