tomcat梳理

tomcat梳理

Tomcat的缺省端口是多少，怎么修改？

• 默认接口是8080
• 修改
  1）找到Tomcat目录下的conf文件夹
  2）进入conf文件夹里面找到server.xml文件
  3）打开server.xml文件
  4）在server.xml文件里面找到下列信息

Tomcat有几种部署方式

• 第一种
  • 编写并编译好的web项目(注意要是编译好的，如果是 eclipse，可以将项目打成 war 包放入)，放入到 webapps 中
• 第二种
  • 打开tomcat下conf/server.xml，在<Host> </Host>标签之间输入项目配置信息
• 第三种：
  • 进入到 apache-tomcat-7.0.52confCatalinalocalhost 目录，新建一个 项目名.xml 文件
  • 
  • 在 那个新建的 xml 文件中，增加下面配置语句<Context docBase="D:/WebProject" reloadable="true" />
  • 在浏览器输入路径：localhost:8080/xml文件名/访问的文件名
  • 
• 总结
  • ①、第一种方法比较普通，但是我们需要将编译好的项目重新 copy 到 webapps 目录下，多出了两步操作
  • ②、第二种方法直接在 server.xml 文件中配置，但是从 tomcat5.0版本开始后，server.xml 文件作为 tomcat 启动的主要配置文件，一旦 tomcat 启动后，便不会再读取这个文件，因此无法再 tomcat 服务启动后发布 web 项目
  • ③、第三种方法是最好的，每个项目分开配置，tomcat 将以confCatalinalocalhost 目录下的 xml 文件的文件名作为 web 应用的上下文路径，而不再理会 中配置的 path 路径，因此在配置的时候，可以不写 path。
  • 通常我们使用第三种方法

tomcat 目录

　　|---bin：存放启动和关闭tomcat脚本

　　|---conf：存放不同的配置文件（server.xml和web.xml）；
　　|---doc：存放Tomcat文档；
　　|---lib/japser/common：存放Tomcat运行需要的库文件（JARS）；
　　|---logs：存放Tomcat执行时的LOG文件；
　　|---src：存放Tomcat的源代码；
　　|---webapps：Tomcat的主要Web发布目录（包括应用程序示例）；
　　|---work：存放jsp编译后产生的class文件；

• 　　

Tomcat配置文件：

• 我们打开con文件夹可以看到Tomcat的配置文件：
  • server.xml: Tomcat的主配置文件，包含Service, Connector, Engine, Realm, Valve, Hosts主组件的相关配置信息；
  • web.xml：遵循Servlet规范标准的配置文件，用于配置servlet，并为所有的Web应用程序提供包括MIME映射等默认配置信息；
  • tomcat-user.xml：Realm认证时用到的相关角色、用户和密码等信息；Tomcat自带的manager默认情况下会用到此文件；在Tomcat中添加/删除用户，为用户　　指定角色等将通过编辑此文件实现；
  • catalina.policy：Java相关的安全策略配置文件，在系统资源级别上提供访问控制的能力；
  • catalina.properties：Tomcat内部package的定义及访问相关控制，也包括对通过类装载器装载的内容的控制；Tomcat在启动时会事先读取此文件的相关设置；
  • logging.properties: Tomcat6通过自己内部实现的JAVA日志记录器来记录操作相关的日志，此文件即为日志记录器相关的配置信息，可以用来定义日志记录的组　　件级别以及日志文件的存在位置等；
  • context.xml：所有host的默认配置信息；

tomcat架构图

• 
• Tomcat中最顶层的容器是Server，代表着整个服务器，从上图中可以看出，一个Server可以包含至少一个Service，用于具体提供服务。
• Service主要包含两个部分：Connector和Container。从上图中可以看出 Tomcat 的心脏就是这两个组件
  • Connector用于处理连接相关的事情，并提供Socket与Request和Response相关的转化;
  • Container用于封装和管理Servlet，以及具体处理Request请求；

tomcat请求

• 一个Tomcat中只有一个Server，一个Server可以包含多个Service，一个Service只有一个Container，但是可以有多个Connectors，这是因为一个服务可以有多个连接，如同时提供Http和Https链接，也可以提供向相同协议不同端口的连接
• 

tomcat容器是如何创建servlet类实例？用到了什么原理？

• 当容器启动时，会读取在webapps目录下所有的web应用中的web.xml文件，然后对xml文件进行解析，并读取servlet注册信息。然后，将每个应用中注册的servlet类都进行加载，并通过反射的方式实例化
• （有时候也是在第一次请求时实例化）在servlet注册时加上如果为正数，则在一开始就实例化，
  如果不写或为负数，则第一次请求实例化

Connector和Container的关系

• 一个请求发送到Tomcat之后，首先经过Service然后会交给我们的Connector，Connector用于接收请求并将接收的请求封装为Request和Response来具体处理，Request和Response封装完之后再交由Container进行处理，Container处理完请求之后再返回给Connector，最后在由Connector通过Socket将处理的结果返回给客户端，这样整个请求的就处理完了！
• Connector最底层使用的是Socket来进行连接的，Request和Response是按照HTTP协议来封装的，所以Connector同时需要实现TCP/IP协议和HTTP协议！

Connector架构分析

• 我们可以把Connector分为四个方面进行理解：
  （1）Connector如何接受请求的？
  （2）如何将请求封装成Request和Response的？
  （3）封装完之后的Request和Response如何交给Container进行处理的？
  （4）Container处理完之后如何交给Connector并返回给客户端的？
• 
• Connector就是使用ProtocolHandler来处理请求的，不同的ProtocolHandler代表不同的连接类型，比如：Http11Protocol使用的是普通Socket来连接的，Http11NioProtocol使用的是NioSocket来连接的。
  • （1）Endpoint用来处理底层Socket的网络连接，Processor用于将Endpoint接收到的Socket封装成Request，Adapter用于将Request交给Container进行具体的处理。
  • （2）Endpoint由于是处理底层的Socket网络连接，因此Endpoint是用来实现TCP/IP协议的，而Processor用来实现HTTP协议的，Adapter将请求适配到Servlet容器进行具体的处理。
  • Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和AsyncTimeout两个内部类和一个Handler接口。Acceptor用于监听请求，AsyncTimeout用于检查异步Request的超时，Handler用于处理接收到的Socket，在内部调用Processor进行处理。
• 启动模型
  • BIO
    • 阻塞式IO，采用传统的java IO进行操作，该模式下每个请求都会创建一个线程，适用于并发量小的场景
    • Tomcat7或以下，在Linux系统中默认使用这种方式。
  • NIO
    • 同步非阻塞，比传统BIO能更好的支持大并发，tomcat 8.0 后默认采用该模式
    • Tomcat7必须修改Connector配置来启动：
      
  • APR
    • tomcat 以JNI形式调用http服务器的核心动态链接库来处理文件读取或网络传输操作，需要编译安装APR库
    • 即Apache Portable Runtime，从操作系统层面解决io阻塞问题。
  • AIO 异步非阻塞，tomcat8.0后支持
  • Tomcat启动的时候，可以通过log看到Connector使用的是哪一种运行模式：
    Starting ProtocolHandler ["http-bio-8080"]
    Starting ProtocolHandler ["http-nio-8080"]
    Starting ProtocolHandler ["http-apr-8080"]

Container架构分析

• 在Connector内部包含了4个子容器，结构图如下

  • 

• Engine：引擎，用来管理多个站点，一个Service最多只能有一个Engine

• Host：代表一个站点，也可以叫虚拟主机，通过配置Host就可以添加站点

  • Host，代表一个站点，也可以叫虚拟主机，一个Host可以配置多个Context，在server.xml文件中的默认配置为, 其中appBase=webapps， 也就是<CATALINA_HOME>webapps目录，unpackingWARS=true 属性指定在appBase指定的目录中的war包都自动的解压，autoDeploy=true 属性指定对加入到appBase目录的war包进行自动的部署

• Context：代表一个应用程序，对应着平时开发的一套程序，或者一个WEB-INF目录以及下面的web.xml文件

  • 在<CATALINA_HOME>webapps 目录中创建一个目录dirname，此时将自动创建一个context，默认context的访问url为http://host:port/dirname
  • 也可以通过在ContextRootMETA-INF 中创建一个context.xml文件，其中包含如下内容来指定应用的访问路径：在server.xml文件中增加context 元素，如下：

• Wrapper：每一Wrapper封装着一个Servlet

  • 在tomcat中Servlet被称为wrapper

• 

Tomcat Server处理一个http请求的过程

1. 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得
   （1-1）Connector的主要任务是负责接收浏览器的发过来的 tcp 连接请求，创建一个 Request 和 Response 对象分别用于和请求端交换数据，然后会产生一个线程来处理这个请求并把产生的 Request 和 Response 对象传给处理这个请求的线程
2. Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应
3. Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host
4. Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）
5. localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context
6. Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为”"的Context去处理）
7. path=”/wsota”的Context获得请求/wsota_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

Tomcat 生命周期

• Tomcat中有四种不同的容器

  • ngine:代表整个Catalina servlet引擎
  • Host:代表虚拟主机
  • Context:代表某个web应用
  • Wrapper:代表某个应用中的servlet
  • 这些容器都扩展了Container接口，更重要的是，这些容器都是父子的关系，Engine位于最顶层，一个Engine包含多个Host，一个Host(虚拟主机)包含多个Context(web应用)，一个Context（web 应用）包含多个Wrapper（servlet），Wrapper位于最底层，没有孩子。当父容器启动时，相应的子容器也应该启动，子容器的子容器也启动。如此，只需要启动最顶层的容器，就会启动所有的子容器。

• Tomcat的容器中有很多组件

  • Logger:负责记录各种事件
  • Loader:负责加载类文件，如加载应用程序中的Servlet
  • Manager:负责管理session
  • Realm: 负责用户验证与授权
  • Pipeline：负责完成容器invoke方法的调用，对请求进行处理（责任链模式的经典应用）
  • 当tomcat容器启动时，这些组件也要启动，进行初始化。当容器停止时，这些组件也应该停止，进行相应的清理工作。比如管理用户session的Manager组件，在tomcat停止时,会将这些session序列化到sessions.ser文件中（位于%tomcat_home%/work/web appcation/sessions.ser）。下一次启动tomcat时，manager会将这个文件中的session反序列化到内存，将删除sessions.ser文件。这也是为什么重启tomcat时，正在访问网站的用户不用重新登录的原因。

• 另外，还有一些类，它们并不像容器的基本组件（如Logger, Loader, Manager）一样，为容器的整个生命周期所调用，而仅仅对容器的某几个特定事件感兴趣。

  • ContextConfig: Context的收听者，在Context（web 应用）启动时，ContextConfig对web应用程序的配置文件web.xml进行分析，为Context生成Wrapper等对象，并与Context关联
  • HostConfig: Host的收听者，在Host(虚拟主机)启动时，HostConfig会自动的为Host部署放置在webapps中的web应用程序
  • EngineConfig:Engine的收听者，这个对比较简单，仅仅是在Engine启动与停止时做一些简单的记录。

• Tomcat的生命周期管理机制设计的非常优雅，在Tomcat启动时，只需要启动一个Server组件，就会启动所有的容器及对应的组件，并且触发这些容器的监听者，完成启动过程的设置。可以说是“一键式”启动的。停止过程也是一样。因为Tomcat的生命周期管理应用了观察者模式

• Tomcat生命周期管理相关类

  • Lifecycle:相当于抽象主题角色，所有的容器类与组件实现类都实现了这个接口。如StandardContext
  • LifecycleListener:相当于抽象观察者角色,具体的实现类有ContextConfig, HostConfig,
  • EngineConfig类，它们在容器启动时与停止时触发。
  • LifecycleEvent:生命周期事件，对主题与发生的事件进行封装。
  • LifecycleSupport:生命周期管理的实用类，提供对观察者的添加，删除及通知观察者的方法。
  • LifecycleException:生命周期异常类。