tomcat 源码部分分析

前言

最近想分析一下网络请求的一些东东，okhttp大概核心部分的那个连接池看着实在让人肝颤。就想着读一个网络后台的程序，本来准备读nginx。主要网络请求部分基本分析清楚，但是http的URL处理以及解析读着就比较蛋疼了，特别是为了一些长的URL和body等等，包括socket数据的拼接等。读着那c语言，最终还是放弃了。所以就转头读一读tomcat，毕竟tomcat不那么在意性能嘛！大概看了下，设计确实吊炸天。

正文

关于如何ide调试，这里可以自行百度，比较简单。
首先最基本的套路，一个BootStrap，这里不再详细介绍，主要是一些自定义类加载器，暂时猜测主要是为了安全性而出现的。根本目的是用来加载一个叫做Catalina的东东（叫什么觉得都不适合，他就类似于操作系统的硬件，都没什么意义，又比较多的hardcode，用来加载优雅的tomcat的组件）。
不过我们还是需要了解一下catalina的主要流程。

Catalina主要是控制生命周期主要是用load，加载一个Digester来解析server.xml(其他是用来初始化一些目录啥的,懒得关注),来初始化整个tomcat。随后调用start来开启整个tamcat。
这个Digester，是个很奇葩的设计。他是解析xml文件的，解析文件是编程界的最大的痛，没什么人知道该如何优雅的解析，目前我了解的三种方法。

1. hardcode，看到什么就解析成成什么
2. 通过反射。
3. 通过DSL类语言，把配置文件作为方法调用（类似gradle）

目前毫无怀疑第三种最优雅，第二种其实类似于第一种，都需要大量的hardcode的编码，不过第三种性能比较低，并且需要编程语言的支持。java目前不支持这种特性。
第二种在tomcat开发的时候，java还不存在反射，所以我们tomcat只能用第一种方案。不过为了在非常不优雅的代码中相对优雅的工作，我们搞出了一个职责链的解析初始化Tomcat的方法，每个标签，搞一个rules，用来做出一系列先关操作，比如

        digester.addObjectCreate("Server",
                                "org.apache.catalina.core.StandardServer",
                                "className");
       digester.addSetProperties("Server");
       digester.addSetNext("Server",
                           "setServer",
                           "org.apache.catalina.Server");

我们遇到Server标签，就会出现这三个rule，然后分别在start和end做出相关动作，根据名字，因为职责链分先后，第一个新建，第二个配置，第三个像父标签配置先关参数。
我们只用配置四个东东，就可以启动一个基本的tomcat具体如下

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
    <Service name="Catalina">
        <Connector port="8080" protocol="HTTP/1.1"
                   connectionTimeout="20000"
                   redirectPort="8443"/>
        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" appBase="webapps"
                  unpackWARs="true" autoDeploy="true">
            </Host>
        </Engine>
    </Service>
</Server>

很清楚的看到这里只有一个server，一个service，这俩都是只能有一个，这些都是概念性的东西，用于清晰代码的逻辑。
下面东西就是真的也许逻辑了，
Connector（连接器） 主要是用来监听特定端口生成request然后交给Adapter来处理
Engine （）主要里面有个pipline，用来执行刚才生产的request（代码没读）
Host（）也是处理request，但是各自职责不同，（代码还没读）

emmm忽然就发觉事情搞定了，不过以后会把这三个在一一分析一下。

后记

我们貌似忽略了真正的解析jar包的部分，不过我们暂时主要盯着请求，以后有空再分析吧。