web application server工作原理

Web 服务器插件基础

WAS 前端支持很多不同厂商的 Web 服务器，常见的 Web 服务器包括 IBM HTTP Server、Apache HTTP Server 和微软的 IIS 等。我们这里主要以 IBM HTTP Server ( 简称 IHS) 为例。如下图所示，一个从浏览器发送的 HTTP 请求经过 Web 服务器之后会被重新定向给应用服务器 ( 这里指的应用服务器都是 WAS)。这个重定向的操作就是由 Web 服务器插件来完成的，我们可以把它想成是一个 Web 服务器和应用服务器之间的“代理”。

图 1. Web 服务器插件
 

这个重定向是基于一系列插件配置的规则，Web 服务器会优先让插件去处理每一个请求，只有当插件没有配置相关的 URL 才会让 Web 服务器去处理。我们可以这样去理解，如果 Web 服务器插件把 HTTP 请求发送给 WAS，那么插件就可以看成是一个 HTTP 客户端，WAS 接收这些请求，那 WAS 就可以看成是一个 HTTP 服务器。HttpTransport 组件就是在 WAS 内部充当 HTTP 服务器来接收 HTTP 请求的，我们可以设置多个 HttpTransport 组件配合多个端口使用。

那么肯定有人要问为什么要使用 Web 服务器插件而不直接将 HTTP 请求从 Web 服务器转给 HttpTransport 组件呢？使用插件来完成这个工作有很多优点：

• 插件可以提供负载管理和故障转移的能力帮助我们将请求分发给多个 WAS 或者将请求转发给合适的 WAS。
• 静态页面由 Web 服务器处理就够了，不需要转给 WAS 从而提高处理性能。
• 插件相当于在客户端和 WAS 之间多加了一层结构，从而也提高了 WAS 的安全性。

Web 服务器插件架构

接下来就让我们看看插件工作的细节，帮助我们更好地理解插件的原理：

图 2. Web 服务器插件请求转发流程
 

1. Web Server Process – native code：从浏览器过来的请求第一步会经过默认的 80 端口进入 Web 服务器。
2. httpd.conf：之后 IHS 会通过默认的 httpd.conf 找到插件的配置文件 plugin-cfg.xml 从而将 HTTP 请求转给插件。
3. 插件会在 Web 服务器启动时加载 plugin-cfg.xml 配置文件。我们需要把插件同 IHS 安装在同一台机器上。
4. plugin-cfg.xml：这是插件的核心配置文件。它包含了哪些 URL 将转发给 WAS。我们可以通过 WAS 的管理控制台修改和生成这个配置文件。但修改和生成配置文件后我们还需要同 Web 服务器同步配置信息。
5. HttpTransport：这个组件实际上可以理解为一个 WAS 内部的基于 Java 的 HTTP 服务器。它主要的职责就是接收从插件转过来的请求并将请求再转给 WAS 的 Web 容器处理。
6. Web Container：Web 容器最后就是利用 Java EE 的 servlet 规范解析并处理请求，再将处理的结果返回给 Web 服务器插件。