Tomcat 处理 HTTP 请求源码分析（上）

<Connector port=”8080” protocol=”org.apache.coyote.http11.Http11AprProtocol”

maxThreads=”150” connectionTimeout=”20000” redirectPort=”8443”

org.apache.coyote.http11.Http11AprProtocol init

 
## 2 Connector 在 Tomcat 中所处的位置
 
### 2.1 Tomcat 架构
 
![](https://static001.infoq.cn/resource/image/59/05/59a324e70eab7cf85ca1ea7173a6e005.jpg)
 
** 图 2-1 Tomcat 架构 **
 
- Server(服务器) 是 Tomcat 构成的顶级构成元素，所有一切均包含在 Server 中，Server 的实现类 StandardServer 可以包含一个到多个 Services;
- 次顶级元素 Service 的实现类为 StandardService 调用了容器 (Container) 接口，其实是调用了 Servlet Engine(引擎)，而且 StandardService 类中也指明了该 Service 归属的 Server；
- 接下来次级的构成元素就是容器 (Container)，主机 (Host)、上下文 (Context) 和引擎 (Engine) 均继承自 Container 接口，所以它们都是容器。但是，它们是有父子关系的，在主机 (Host)、上下文 (Context) 和引擎 (Engine) 这三类容器中，引擎是顶级容器，直接包含是主机容器，而主机容器又包含上下文容器，所以引擎、主机和上下文从大小上来说又构成父子关系，虽然它们都继承自 Container 接口。
- 连接器 (Connector) 将 Service 和 Container 连接起来，首先它需要注册到一个 Service，它的作用就是把来自客户端的请求转发到 Container(容器)，这就是它为什么称作连接器的原因。
 
故我们从功能的角度将 Tomcat 源代码分成 5 个子模块，它们分别是：
 
1. Jsper 子模块：这个子模块负责 jsp 页面的解析、jsp 属性的验证，同时也负责将 jsp 页面动态转换为 java 代码并编译成 class 文件。在 Tomcat 源代码中，凡是属于 org.apache.jasper 包及其子包中的源代码都属于这个子模块；
2. Servlet 和 Jsp 规范的实现模块：这个子模块的源代码属于 javax.servlet 包及其子包，如我们非常熟悉的 javax.servlet.Servlet 接口、javax.servet.http.HttpServlet 类及 javax.servlet.jsp.HttpJspPage 就位于这个子模块中；
3. Catalina 子模块：这个子模块包含了所有以 org.apache.catalina 开头的 java 源代码。该子模块的任务是规范了 Tomcat 的总体架构，定义了 Server、Service、Host、Connector、Context、Session 及 Cluster 等关键组件及这些组件的实现，这个子模块大量运用了 Composite 设计模式。同时也规范了 Catalina 的启动及停止等事件的执行流程。从代码阅读的角度看，这个子模块应该是我们阅读和学习的重点。
4. Connectors 子模块：如果说上面三个子模块实现了 Tomcat 应用服务器的话，那么这个子模块就是 Web 服务器的实现。所谓连接器 (Connector) 就是一个连接客户和应用服务器的桥梁，它接收用户的请求，并把用户请求包装成标准的 Http 请求 (包含协议名称，请求头 Head，请求方法是 Get 还是 Post 等等)。同时，这个子模块还按照标准的 Http 协议，负责给客户端发送响应页面，比如在请求页面未发现时，connector 就会给客户端浏览器发送标准的 Http 404 错误响应页面。
5. Resource 子模块：这个子模块包含一些资源文件，如 Server.xml 及 Web.xml 配置文件。严格说来，这个子模块不包含 java 源代码，但是它还是 Tomcat 编译运行所必需的。
 
### 2.2 Tomcat 运行流程
 
![](https://static001.infoq.cn/resource/image/f1/d4/f1aa8a781479109792f43efbc6793fd4.jpg)
 
** 图 2-2 tomcat 运行流程 **
 
假设来自客户的请求为：<http://localhost:8080/test/index.jsp>
 
1. 请求被发送到本机端口 8080，被在那里侦听的 Coyote HTTP/1.1 Connector 获得
2. Connector 把该请求交给它所在的 Service 的 Engine 来处理，并等待 Engine 的回应
3. Engine 获得请求 localhost:8080/test/index.jsp，匹配它所有虚拟主机 Host
4. Engine 匹配到名为 localhost 的 Host（即使匹配不到也把请求交给该 Host 处理，因为该 Host 被定义为该 Engine 的默认主机）
5. localhost Host 获得请求 /test/index.jsp，匹配它所拥有的所有 Context
6. Host 匹配到路径为 /test 的 Context（如果匹配不到就把该请求交给路径名为 "" 的 Context 去处理）
7. path="/test" 的 Context 获得请求 /index.jsp，在它的 mapping table 中寻找对应的 servlet
8. Context 匹配到 URL PATTERN 为\*.jsp 的 servlet，对应于 JspServlet 类
9. 构造 HttpServletRequest 对象和 HttpServletResponse 对象，作为参数调用 JspServlet 的 doGet 或 doPost 方法
10. Context 把执行完了之后的 HttpServletResponse 对象返回给 Host
11. Host 把 HttpServletResponse 对象返回给 Engine
12. Engine 把 HttpServletResponse 对象返回给 Connector
13. Connector 把 HttpServletResponse 对象返回给客户 browser
 
## 3 Connector 源码分析
 
### 3.1 Tomcat 的启动分析与集成设想
 
我们知道，启动 tomcat 有两种方式：
 
- 双击 bin/startup.bat
- 运行 bin/catalina.bat run
 
它们对应于 Bootstrap 与 Catalina 两个类，我们现在只关心 Catalina 这个类，这个类使用 Apache Digester 解析 conf/server.xml 文件生成 tomcat 组件，然后再调用 Embedded 类的 start 方法启动 tomcat。
 
所以，集成 Tomcat 的方式就有以下两种了：
 
- 沿用 tomcat 自身的 server.xml
- 自己定义一个 xml 格式来配置 tocmat 的各参数，自己再写解析这段 xml，然后使用 tomcat 提供的 API 根据这些 xml 来生成 Tomcat 组件，最后调用 Embedded 类的 start 方法启动 tomcat
 
个人觉得第一种方式要优越，给开发者比较好的用户体验，如果使用这种，直接模仿 Catalina 类的方法即可实现集成。
 
目前，JOnAS 就使用了这种集成方式，JBoss、GlassFish 使用的第二种自定义 XML 的方式。
 
### 3.2 Connector 类图与顺序图
 
![](https://static001.infoq.cn/resource/image/96/6e/96a9a2835ef2e2ad0d7ed0bda9643b6e.jpg)
 
** 图 3-1 Connector 相关类图 **
 
![](https://static001.infoq.cn/resource/image/e0/46/e0ae1bbf830029d7987ec352097aa746.jpg)
 
** 图 3-2 Connector 工作流程顺序图 **
 
从上面二图中我们可以得到如下信息：
 
1. Tomcat 中有四种容器 (Context、Engine、Host、Wrapper)，前三者常见，第四个不常见但它也是实现了 Container 接口的容器
2. 如果要 ** 自定义一个 Connector 的话，只需要实现 ProtocolHander 接口 **, 该接口定义如下：
 
![](https://static001.infoq.cn/resource/image/d6/41/d68e087d447f8aa1430fb43d80733b41.jpg)
 
** 图 3-3 自定义 connector 时需实现的 ProtocolHandler 接口 **
 
Tomcat 以 HTTP（包括 BIO 与 NIO）、AJP、APR、内存四种协议实现了该接口（它们分别是：AjpAprProtocol、AjpProtocol、Http11AprProtocol、Http11NioProtocol、Http11Protocal、JkCoyoteHandler、MemoryProtocolHandler），要使用哪种 Connector 就在 conf/server.xml 中配置，在 Connector 的构造函数中会通过反射实例化所配置的实现类：
 

 
### 3.3 Connector 的工作流程
 
下面我们以 Http11AprProtocol 为例说明 Connector 的工作流程。
 
1. 它将工作委托给 NioEndpoint 类。在 NioEndpoint 类的 init 方法中构建一个 SocketServer(当然，不同的实现类会有一些微小的变化，例如如果是 NIO，它构建的就是 SocketServerChannel)
2. 在 NioEndpoint.Acceptor 类中会接收一个客户端新的连接请求，如下图： ![](https://static001.infoq.cn/resource/image/60/c2/60d40698ebc98c35b716482674940dc2.jpg)
3. 在 NioEndpoint 类中，有一个内部接口 Handle，该接口定义如下： ![](https://static001.infoq.cn/resource/image/f1/86/f146a6241cd6ba3891202b856f3c8186.jpg)
4. 在 Http11NioProtocol 类中实现了 Handle 这个内部接口，并调用 Http11NioProcessor 类 (该类实现了 ActionHook 回调接口)。在 Response 类中会调用 ActionHook 实现类的相关方法的，Response 类的 action 方法如下： ![](https://static001.infoq.cn/resource/image/2a/12/2a01ddee8e5102e131b20890f706c012.jpg)
5. Http11NioProcessor 的 process 实现方法中，会通过 Adapter 来调用 Servler 容器生成响应结果。
 
## 关于作者
 
张华，长期从事 Java 方面的开发工作，有搜索引擎、中间件应用服务器、互联网、云计算等领域的行业经验，目前正在从事基于 Power 的虚拟化技术研发。博客地址：<http://blog.csdn.net/quqi99>
 
- - - - - -
 
感谢 [张凯峰](http://www.infoq.com/cn/bycategory.action?authorName=%E5%BC%A0%E5%87%AF%E5%B3%B0) 对本文的审校。
 
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 [editors@cn.infoq.com](mailto:editors@cn.infoq.com)。也欢迎大家加入到 [InfoQ 中文站用户讨论组](http://groups.google.com/group/InfoQChina) 中与我们的编辑和其他读者朋友交流。