精华内容
下载资源
问答
  • tomcat架构解析

    2018-10-10 17:16:27
    tomcat架构解析
  • tomcat 架构解析

    2019-01-23 17:28:02
    tomcat 架构解析 pdf 版 高清有目录,适合各个阶段的人学习使用
  • Tomcat架构解析

    2018-11-27 19:17:50
    网站 ...gt;> CiCi岛 ...基于Tomcat新版本全面解析应用服务器架构 涵盖Tomcat所有组件的详细配置、使用与优化 知识讲解广度与深度结合,系统性与完整性兼备 Tomcat作为一款开源的轻量级Web应用服...

    网站

    更多书籍点击进入>> CiCi岛

    下载

    电子版仅供预览及学习交流使用,下载后请24小时内删除,支持正版,喜欢的请购买正版书籍

    封页

    封页

    编辑推荐

    基于Tomcat新版本全面解析应用服务器架构 涵盖Tomcat所有组件的详细配置、使用与优化 知识讲解广度与深度结合,系统性与完整性兼备 Tomcat作为一款开源的轻量级Web应用服务器,技术先进,性能稳定,深受Java爱好者的喜爱,也得到了广大软件开发商的高度认可,目前已成为流行的Java Web应用服务器,广泛应用于企业应用系统及云服务平台,是开发和调试JSP/Servlet应用的。系统学习Tomcat架构将会令你受益匪浅。 本书从功能组件、协议、规范,到详细配置等各个方面,系统性介绍了Tomcat架构的实现方案及使用方式,有助于读者详细了解应用服务器的架构及工作原理。主要内容包括: ★ Tomcat的基础组件架构及工作原理; ★ Tomcat各组件的设计、实现方案、使用方式及详细配置; ★ Tomcat与Web服务器集成及性能优化; ★ Tomcat部分扩展特性介绍:嵌入式、Comet、WebSocket等。 学习本书,读者可以详细了解应用服务器的架构以及工作原理,不仅可以系统掌握Tomcat的使用,而且对于应用系统基础架构也有很大的借鉴意义。

    内容简介

    Tomcat架构解析 基于Tomcat 8.5.x全面介绍了Tomcat的架构、各组件的实现方案以及使用方式,主要包括Tomcat的基础组件架构以及工作原理,Tomcat各组件的实现方案、使用方式以及详细配置说明,Tomcat与Web服务器集成以及性能优化,Tomcat部分扩展特性介绍等。读者可以了解应用服务器的架构以及工作原理,学习Tomcat的使用、优化以及详细配置。

    作者简介

    刘光瑞,北京窝客研发总监,负责窝客产品研发管理及总体架构设计。拥有十几年的企业级大型业务系统研发架构经验,成功带领团队设计并研发基于Tomcat的组件化微服务架构。2007年在四达软件担任高级架构师,主导了数个省份的广播电视省网业务运营支撑系统的架构设计及优化工作。2012年在电讯盈科担任高级技术顾问,参与了中国移动供应链系统的架构及研发。在应用系统架构及性能优化方面积累了丰富的经验。

    目 录

    第1章 Tomcat介绍  1

    1.1 简介 1

    1.1.1 Tomcat历史 1

    1.1.2 Tomcat许可 2

    1.2 安装和启动 3

    1.2.1 Tomcat下载与安装 3

    1.2.2 Tomcat启动 4

    1.2.3 IDE启动 5

    1.2.4 嵌入式启动 10

    1.2.5 Debug启动 11

    1.3 Tomcat目录结构 12

    1.4 Tomcat 8.5之后的新特性 12

    1.5 小结 13

    第2章 Tomcat总体架构 14

    2.1 总体设计 14

    2.1.1 Server 14

    2.1.2 Connector和Container 15

    2.1.3 Container设计 17

    2.1.4 Lifecycle 20

    2.1.5 Pipeline和Valve 23

    2.1.6 Connector设计 24

    2.1.7 Executor 26

    2.1.8 Bootstrap和Catalina 28

    2.2 Tomcat启动 30

    2.3 请求处理 31

    2.4 类加载器 33

    2.4.1 J2SE标准类加载器 33

    2.4.2 Tomcat加载器 34

    2.4.3 Web应用类加载器 36

    2.5 小结 37

    第3章 Catalina 38

    3.1 什么是Catalina 38

    3.2 Digester 39

    3.2.1 对象栈 40

    3.2.2 匹配模式 41

    3.2.3 处理规则 41

    3.2.4 示例程序 42

    3.3 创建Server 44

    3.3.1 Server的解析 45

    3.3.2 Engine的解析 48

    3.3.3 Host的解析 49

    3.3.4 Context的解析 50

    3.4 Web应用加载 53

    3.4.1 StandardHost 54

    3.4.2 HostConfig 56

    3.4.3 StandardContext 60

    3.4.4 ContextConfig 64

    3.4.5 StandardWrapper 69

    3.4.6 Context命名规则 69

    3.5 Web请求处理 71

    3.5.1 总体过程 71

    3.5.2 请求映射 72

    3.5.3 Catalina请求处理 80

    3.6 DefaultServlet和JspServlet 81

    3.6.1 DefaultServlet 82

    3.6.2 JspServlet 84

    3.7 小结 85

    第4章 Coyote 86

    4.1 什么是Coyote 86

    4.2 Web请求处理 88

    4.2.1 主要概念 88

    4.2.2 请求处理 90

    4.2.3 协议升级 92

    4.3 HTTP 94

    4.3.1 基础知识 94

    4.3.2 配置方式 95

    4.4 AJP 97

    4.4.1 基础知识 97

    4.4.2 Web服务器组件 103

    4.4.3 配置方式 106

    4.5 HTTP 2.0 106

    4.5.1 基础知识 106

    4.5.2 配置方式 110

    4.6 I O 111

    4.6.1 BIO 112

    4.6.2 NIO 115

    4.6.3 NIO2 121

    4.6.4 APR 130

    4.7 小结 134

    第5章 Jasper 136

    5.1 Jasper简介 136

    5.2 JSP编译方式 137

    5.2.1 运行时编译 137

    5.2.2 预编译 141

    5.3 JSP编译原理 144

    5.4 小结 151

    第6章 Tomcat配置管理 152

    6.1 JVM配置 152

    6.1.1 JVM配置选项 152

    6.1.2 系统属性 153

    6.2 服务器配置 158

    6.2.1 catalina.properties 158

    6.2.2 server.xml 159

    6.2.3 context.xml 172

    6.3 Web应用配置 172

    6.3.1 ServletContext初始化参数 173

    6.3.2 会话配置 174

    6.3.3 Servlet声明及映射 175

    6.3.4 应用生命周期监听器 177

    6.3.5 Filter定义及映射 177

    6.3.6 MIME类型映射 178

    6.3.7 欢迎文件列表 178

    6.3.8 错误页面 179

    6.3.9 本地化及编码映射 179

    6.3.10 安全配置 179

    6.3.11 JNDI配置 180

    6.3.12 其他 183

    6.4 Web应用过滤器 185

    6.4.1 CorsFilter 186

    6.4.2 CsrfPreventionFilter 188

    6.4.3 ExpiresFilter 188

    6.4.4 FailedRequestFilter 190

    6.4.5 RemoteAddrFilter 191

    6.4.6 RemoteHostFilter 191

    6.4.7 RemoteIpFilter 192

    6.4.8 RequestDumperFilter 195

    6.4.9 SetCharacterEncodingFilter 195

    6.4.10 WebdavFixFilter 196

    6.5 Tomcat管理 196

    6.5.1 host-manager 196

    6.5.2 manager 197

    6.5.3 管理命令行 199

    6.5.4 Ant任务 200

    6.5.5 JMX 201

    6.6 小结 201

    第7章 Web服务器集成 202

    7.1 Web服务器与应用服务器的区别 202

    7.2 集成应用场景 205

    7.3 与Apache HTTP Server集成 206

    7.3.1 Windows环境安装 206

    7.3.2 Linux环境安装 207

    7.3.3 mod_jk 209

    7.3.4 mod_proxy_ajp 229

    7.4 与Ngnix集成 235

    7.4.1 Ngnix简介 235

    7.4.2 Windows环境安装 237

    7.4.3 Linux环境安装 237

    7.4.4 Tomcat集成 241

    7.5 与IIS集成 243

    7.6 小结 243

    第8章 Tomcat集群 244

    8.1 Tomcat集群介绍 244

    8.1.1 Tomcat集群基础 246

    8.1.2 Apache Tribes 247

    8.1.3 Tomcat集群组件实现 253

    8.2 集群配置 254

    8.3 会话同步 255

    8.3.1 DeltaManager 256

    8.3.2 BackupManager 257

    8.3.3 替代方案 257

    8.4 集群部署 258

    8.4.1 实现原理 258

    8.4.2 配置方式 259

    8.5 小结 259

    第9章 Tomcat安全 260

    9.1 配置安全 260

    9.1.1 安装部署问题 260

    9.1.2 server.xml配置 261

    9.2 应用安全 263

    9.2.1 Realm 264

    9.2.2 HttpServletRequest 265

    9.2.3 Authenticator 266

    9.3 传输安全(SSL) 267

    9.4 Java安全策略 273

    9.4.1 简介 273

    9.4.2 catalina.policy 275

    9.5 小结 279

    第10章 Tomcat性能调优 280

    10.1 Tomcat性能测试及诊断 281

    10.1.1 常见测试方式 281

    10.1.2 性能测试工具 282

    10.1.3 数据采集及分析 290

    10.2 Tomcat性能优化 303

    10.2.1 JVM优化 304

    10.2.2 Tomcat配置 308

    10.3 应用性能优化建议 311

    10.4 小结 312

    第11章 Tomcat附加功能 313

    11.1 Tomcat的嵌入式启动 313

    11.1.1 为什么需要嵌入式启动 313

    11.1.2 嵌入式启动Tomcat 314

    11.1.3 嵌入式启动服务器 316

    11.2 Tomcat中的JNDI 317

    11.2.1 什么是JNDI 317

    11.2.2 Tomcat中的JNDI 318

    11.3 Comet和WebSocket 320

    11.3.1 什么是Comet 321

    11.3.2 Tomcat的Comet实现 322

    11.3.3 什么是WebSocket 326

    11.3.4 Tomcat的WebSocket实现 328

    11.4 小结 335

    附录 server.xml配置 336

    结束语 370






    展开全文
  • tomcat 架构解析和优化。pdf tomcat 架构解析和优化。pdftomcat 架构解析和优化。pdf
  • tomcat架构解析_PDF电子书下载 高清
  • Tomcat 架构解析精简版

    2020-12-09 15:31:24
    Tomcat 架构解析这本书详细地介绍了 Tomcat 的总体架构, 主要组件以及配置文件的使用, 书中掺杂了大量的源码来介绍业务流程, 这边都做了删减, 有兴趣的可以阅读原版.另外 Tomcat 官网也有相关文档, 只是比较混乱. ...

    Tomcat 汤姆猫,哈哈, 基本属于那种大家天天用, 反而很容易忽视的角色. Tomcat 架构解析这本书详细地介绍了 Tomcat 的总体架构, 主要组件以及配置文件的使用, 书中掺杂了大量的源码来介绍业务流程, 这边都做了删减, 有兴趣的可以阅读原版.另外 Tomcat 官网也有相关文档, 只是比较混乱.
    如有侵权,请联系删除.

    第 1 章 Tomcat 介绍

    Tomcat 是全世界最著名的基于 Java 语言的轻量级应用服务器, 是一款完全开源免费的 Servlet 容器实现. 同时, 它支持 HTML, JS 等静态资源的处理, 因此又可以作为轻量级 Web 服务器使用.

    1.1 简介

    1.1.1 Tomcat 历史

    Tomcat 最初由 Sun 公司的软件架构师 James Duncan Davidson 开发, 该项目于 1999 年与 Apache 软件基金会旗下的 JServ 项目合并, 即为现在的 Tomcat.

    1.3 Tomcat 目录结构

    在这里插入图片描述

    第 2 章 Tomcat 总体架构

    本章主要包含如下几个部分.

    • Tomcat 总体架构设计及 Tomcat 各组件的概念
    • Tomcat 启动及请求处理过程
    • Tomcat 的类加载器

    2.1 总体设计

    为了使读者能更深刻地理解 Tomcat 的相关组件概念, 我们将采用一种启发式的讲解方式来介绍 Tomcat 的总体设计.

    2.1.1 Server

    服务器最基本的描述:它接收客户端发来的请求数据并进行解析,完成相关业务处理,然后把处理结果作为响应返回给客户端.

    通常情况下, 我们通过使用 Socket 监听服务器指定端口来实现该功能.
    一个最简单的服务器设计如下图所示
    在这里插入图片描述

    • 我们通过 start() 方法启动服务器, 打开 Socket 链接, 监听服务器端口, 并负责在接收到客户端请求时进行处理并返回响应.
    • 同时提供一个 stop() 方法来停止服务器并释放网络资源.

    2.1.2 Connector 和 Container

    将请求监听与请求处理放在一起扩展性很差, 比如我们想适配多种网络协议(AJP 协议, HTTP 协议等), 但是请求处理过程却相同的时候.

    于是, 我们将网络协议与请求处理从概念上分离.
    在这里插入图片描述

    • 一个 Server 可以包含多个 Connector 和 Container。
    • 其中 Connector 负责开启 Socket 并监听客户端请求、返回响应数据;
    • Container 负责具体的请求处理。
    • Connector 和 Container 分别拥有自己的 start() 和 stop() 方法来加载和释放自己维护的资源。

    但是, 这个设计有个明显的缺陷, 即如何知晓来自某个 Connector 的请求由哪个 Container 处理呢?

    更合理的方式如下图所示.
    在这里插入图片描述

    • 一个 Server 包含多个 Service (它们互相独立, 只是共享一个 JVM 以及系统类库).
    • 一个 Service 负责维护多个 Connector 和一个 Container.
    • 这样来自 Connector 的请求只能有它所属 Service 维护的 Container 处理.

    在 Tomcat 中,Container 是一个更加通用的概念。
    为了与 Tomcat 中的组件命名一致,我们将 Container 重新命名为 Engine,用以表示整个 Servlet 引擎。

    修改后的设计如图2-4所示。
    在这里插入图片描述
    注意:

    • 需要注意此处的描述,Engine 表示整个 Servlet 引擎,而非 Servlet 容器。
    • 表示整个 Servlet 容器的是 Server。
    • 引擎只负责请求的处理,并不需要考虑请求链接、协议等的处理。

    2.1.3 Container 设计

    我们需要在 Engine 容器中支持管理应用,当接收到 Connector 的处理请求时,Engine 容器能够找到一个合适的 Web 应用来处理。
    在这里插入图片描述

    我们使用 Context 来表示一个 Web 应用,并且一个 Engine 可以包含多个 Context。

    如果我们希望只运行一个服务器实例, 但提供多个域名的服务, 可以将每个域名视为一个虚拟的主机, 在每个虚拟主机下包含多个 Web 应用.
    在这里插入图片描述
    我们用 Host 表示虚拟主机的概念, 一个 Host 可以包含多个 Context.

    另外, 在一个 Web 应用中, 可包含多个 Servlet 实例以处理来自不同链接的请求.

    在 Tomcat 中, Servlet 定义被称为 Wrapper, 基于此修改后的设计如图 2-7 所示.
    在这里插入图片描述
    补一张更形象的总体架构图
    在这里插入图片描述

    2.1.4 Lifecycle

    • 我们很容易发现,所有组件均存在启动、停止等生命周期方法,拥有生命周期管理的特性.
    • 因此,我们可以基于生命周期管理进行一次接口抽象.
    • 我们针对所有拥有生命周期管理特性的组件抽象了一个生命周期通用接口.
    • 该接口定义了生命周期管理的核心方法.
      • Init(): 初始化组件
      • start(): 启动组件
      • stop(): 停止组件
      • destory(): 销毁组件

    在这里插入图片描述

    2.1.5 Pipeline 和 Valve

    • 在 Tomcat 中每个 Container(容器组件包括 Engine, Host, Context, Wrapper) 组件通过执行一个职责链来完成具体的请求处理.
    • Tomcat 定义了 Pipeline(管道) 和 Valve(阀) 两个接口.
    • 前者用于构造职责链, 后者代表职责链上的每个处理器.
    • 我们可以从字面意思来理解–来自客户端的请求就像是流经管道的水一般, 经过每个阀进行处理.
      在这里插入图片描述

    2.1.6 Connector 设计

    Connector 需要包含如下几项功能:

    • 监听服务器端口,读取来自客户端的请求。
    • 将请求数据按照指定协议进行解析。
    • 根据请求地址匹配正确的容器进行处理。
    • 将响应返回客户端。

    只有这样才能保证将接收到的客户端请求交由与请求地址匹配的容器处理.

    我们知道,Tomcat 支持多协议,默认支持 HTTP 和 AJP。
    同时,Tomcat 还支持多种 IO 方式,包括 BIO(8.5版本之后移除)、NIO、APR.
    而且在 Tomcat 8 之后新增了对 NIO2 和 HTTP/2 协议的支持。
    因此,对协议和 IO 进行抽象和建模是需要重点关注的.
    在这里插入图片描述

    • 在 Tomcat 中,ProtocolHandler 表示一个协议处理器,针对不同协议和 IO 方式,提供了不同的实现,如 Http11NioProtocol 表示基于 NIO 的 HTTP 协议处理器。
    • ProtocolHandler 包含一个 Endpoint 用于启动 Socket 监听,该接口按照 IO 方式进行分类实现,如 Nio2Endpoint 表示非阻塞式 Socket I/O。
    • 还包含一个 Processor 用于按照指定协议读取数据,并将请求交由容器处理,如 Http11NioProcessor 表示在 NIO 的方式下 HTTP 请求的处理类。
    • 在 Connector 启动时,Endpoint 会启动线程来监听服务器端口,并在接收到请求后调用 Processor 进行数据读取。
    • 当 Processor 读取客户端请求后,需要按照请求地址映射到具体的容器进行处理,这个过程即为请求映射.
    • Tomcat 通过 Mapper 和 MapperListener 两个类实现该功能。
    • 前者用于维护容器映射信息,同时按照映射规则(Servlet规范定义)查找容器。
    • 后者实现了 ContainerListener 和 LifecycleListener, 用于在容器组件状态发生变更时, 注册或取消对应的容器映射信息.

    2.1.7 Executor

    Tomcat 提供了 Executor 接口来表示一个可以在组件间共享的线程池(默认使用了JDK5提供的线程池技术),该接口同样继承自 Lifecycle,可按照通用的组件进行管理。

    线程池的共享范围如何确定?
    在 Tomcat 中 Executor 由 Service 维护,因此同一个 Service 中的组件可以共享一个线程池。

    2.1.8 Bootstrap 和 Catalina

    • Tomcat 通过类 Catalina 提供了一个 Shell 程序,用于解析 server.xml 创建各个组件,同时负责启动、停止应用服务器(只需要启动 Tomcat 顶层组件 Server 即可).
    • Tomcat 使用 Digester 解析 XML 文件,包括 server.xml 以及 web.xml 等。
    • 最后,Tomcat 提供了 Bootstrap 作为应用服务器启动人口。
    • Bootstrap 负责创建 Catalina 实例,根据执行参数调用 Catalina 相关方法完成针对应用服务器的操作(启动、停止)。
    • 也许你会有疑问,为什么 Tomcat 不直接通过 Catalina 启动,而是又提供了 Bootstrap 呢?
    • 你可以查看一下 Tomcat 的发布包目录,Bootstrap 并不位于 Tomcat 的依赖库目录下($CATALINA_HOME/lib ),而是直接在 SCATALINA_HOME/bin 目录下。
    • Bootstrap 与 Tomcat 应用服务器完全松耦合(通过反射调用 Catalina 实例),它可以直接依赖 JRE 运行并为 Tomcat 应用服务器创建共享类加载器,用于构造 Catalina 实例以及整个 Tomcat 服务器。

    2.2 Tomcat 启动

    • Tomcat 的启动过程非常标准化,统一按照生命周期管理接口 Lifecycle 的定义进行启动。
    • 首先,调用 init() 方法进行组件的逐级初始化,然后再调用 start() 方法进行启动。
    • 当然,每次调用均伴随着生命周期状态变更事件的触发。
    • 每一级组件除完成自身的处理外,还要负责调用子组件相应的生命周期管理方法,
    • 组件与组件之间是松耦合的设计,因此我们很容易通过配置进行修改和替换。

    2.3 请求处理

    • 从本质上讲,应用服务器的请求处理开始于监听的 Socket 端口接收到数据,结束于将服务器处理结果写入 Socket 输出流。
    • 在这个处理过程中,应用服务器需要将请求按照既定协议进行读取,并封装为与具体通信方案无关的请求对象。
    • 然后根据请求映射规则定位到具体的处理单元(在Java应用服务器中,多数是某个Web应用下的一个Servlet )进行处理。
    • 当然,如果我们的应用不是基于简单的 Servlet API, 而是基于当前成熟的 MVC 框架((如Apache Struts、Spring MVC),那么在多数情况下请求将进一步匹配到 Servlet 下的一个控制器——这部分已经不属于应用服务器的处理范畴,而是由具体的 MVC 框架进行匹配。
    • 当 Servlet 或者控制器的业务处理结束后,处理结果将被写入一个与通信方案无关的响应对象。
    • 最后,该响应对象将按照既定协议写入输出流。

    2.4 类加载器

    本节将主要介绍 Tomcat 的类加载机制,包括 Tomcat 的类加载器层级设计以及 Web 应用的类加载过程。

    2.4.1 J2SE 标准类加载器

    我们都知道 JVM 默认提供了 3 个类加载器,它们以一种父子树的方式创建,同时使用委派模式确保应用程序可通过自身的类加载器(System)加载所有可见的Java类。结构如图2-19所示。
    在这里插入图片描述

    2.4.2 Tomcat 加载器

    Tomcat 提供了 3 个基础的类加载器和 Web 应用类加载器, 而且这 3 个类加载器指向的路径和包列表均可以由 catalina.properties 配置.

    • Common: 以 System 为父类加载器,是位于 Tomcat 应用服务器顶层的公用类加载器。其路径为 common.loader,默认指向 $CATALINA_HOME/lib下的包。
    • Catalina: 以 Common 为父加载器,是用于加载 Tomcat 应用服务器的类加载器,其路径为 server.loader,默认为空。此时 Tomcat 使用 Common 类加载器加载应用服务器。
    • Shared: 以 Common 为父加载器,是所有Web应用的父加载器,其路径为 shared.loader,默认为空。此时 Tomcat 使用 Common 类加载器作为 Web 应用的父加载器。
    • Web应用: 以 Shared 为父加载器,加载 /WEB-INF/classes 目录下的未压缩的 Class 和资源文件以及 /WEB-INF/lib 目录下的 Jar 包。如前所述,该类加载器只对当前Web应用可见,对其他Web应用均不可见。
      在这里插入图片描述

    2.5 小结

    本章从多个方面讲述了 Tomcat 的总体架构。

    • 首先,以一种逐渐演进的方式讲解了 Tomcat 核心组件的设计以及如此设计的原因,便于读者更好地理解相关概念。
    • 其次,讲解了主要组件概念及 Tomcat 的启动和请求处理过程,动态地描述了组件如何相互协作以实现服务器的基本功能。
    • 最后讲述了 Tomcat 的类加载机制,包括 JVM 和 Tomcat 为我们提供的类加载特性,以及这些特性在架构层面的意义。

    第 3 章 Catalina

    本章主要介绍 Tomcat 的 Servlet 容器实现 Catalina.

    3.1 什么是 Catalina

    • 2001年,Tomcat 发布了重要的具有里程碑意义的版本 4.0。
    • 在该版本中, Tomcat 完全重新设计了其 Servlet 容器的架构。
    • 该部分工作由 Craig McClanahan 完成,他将这个新版本的 Servlet 容器实现命名为 Catalina。
      在这里插入图片描述
    • Tomcat 本质上是一款 Servlet 容器,因此 Catalina 是 Tomcat 的核心,其他模块均为 Catalina 提供支撑。
    • 通过 Coyote 模块提供链接通信,Jasper 模块提供 JSP 引擎,Naming 提供 JNDI 服务,Juli 提供日志服务。

    3.2 Digester

    • Digester 是一款用于将 XML 转换为 Java 对象的事件驱动型工具,是对 SAX (同样为事件驱动型XML处理工具,已包含到 J2SE 基础类库当中)的高层次封装。
    • Digester 针对 SAX 事件提供了更加友好的接口,隐藏了 XML 节点具体的层次细节,使开发者可以更加专注于处理过程。
    • Digester 及 SAX 的事件驱动,简而言之,就是通过流读取 XML 文件,当识别出特定 XML 节点后便会执行特定的动作,或者创建 Java 对象,或者执行对象的某个方法。
    • 因此 Digester 的核心是匹配模式和处理规则。

    3.2.1 对象栈

    • Digester 提供了一套对象栈( Digester 同名类)机制用于构造 Java 对象.
    • Digester 的设计模式是指,在文件读取过程中,如果遇到一个 XML 节点的开始部分,则会触发处理规则事件创建 Java 对象,并将其放入栈。
    • 当处理该节点的子节点时,该对象都将维护在栈中。
    • 当遇到该节点的结束部分时,该对象将会从栈中取出并清除。

    3.3 创建 Server

    Catalina 通过解析 server.xml 创建 Server.

    3.4 Web 应用加载

    Servlet 容器的核心功能主要有两个: 部署 Web 应用将请求映射到具体的 Servlet 进行处理.

    3.5 Web 请求处理

    3.5.1 总体过程

    Tomcat 通过 org.apache.tomcat.util.http.mapper.Mapper 维护请求链接与 Host 、Context、Wrappe r 等Container 的映射。
    同时,通过 org.apache.catalina.connector.MapperListener 监听器监听所有的 Host 、Context、Wrapper 组件,在相关组件启动、停止时注册或者移除相关映射。
    此外,通过 org.apache.catalina.connector.CoyoteAdapter将Connector 与 Mapper、Container 联系起来。当 Connector 接收到请求后,首先读取请求数据,然后调用 CoyoteAdapter.service() 方法完成请求处理。

    CoyoteAdapter.service 的具体处理过程如下(只列出主要步骤)。

    • 根据 Connector 的请求( org.apache.coyote.Request)和响应( org.apache.coyote.Response)对象创建 Servlet 请求( org.apache.catalina.connector.Request )和响应( org.apache.catalina.connector.Response )。
    • 转换请求参数并完成请求映射。
      • 请求 URI 解码,初始化请求的路径参数。
      • 检测 URI 是否合法,如果非法,则返回响应码 400。
      • 请求映射,映射结果保存到 org.apache.catalina.connector.Request.mappingData,类型为org.apache.tomcat.util.http.mapper.MappingData,请求映射处理最终会根据 URI 定位到一个有效的 Wrapper。
      • 如果映射结果 MappingData 的 redirectPath 属性不为空(即为重定向请求),则调用 org.apache.catalina.connector.Response.sendRedirect 发送重定向并结束。
      • 如果当前 Connector 不允许追踪( allowTrace为false )且当前请求的 Method 为TRACE,则返回响应码 405。
      • 执行连接器的认证及授权。
    • 得到当前 Engine 的第一个 Valve 并执行( invoke ),以完成客户端请求处理。
    • 如果为异步请求:
      • 获得请求读取事件监听器(ReadListener );
      • 如果请求读取已经结束,触发 ReadListener.onAllDataRead。
    • 如果为同步请求:
      • Flush并关闭请求输入流;
      • Flush并关闭响应输出流。

    第 4 章 Coyote

    链接器接收来自客户端的请求,并按照既定协议(如 HTTP)进行解析,然后交由 Servlet 容器处理。

    4.1 什么是 Coyote

    • Coyote 是 Tomcat链接器框架的名称,是 Tomcat 服务器提供的供客户端访问的外部接口。
    • 客户端通过 Coyote 与服务器建立链接、发送请求并接收响应。
    • Coyote 封装了底层的网络通信(Socket 请求及响应处理),为 Catalina 容器提供了统一的接口,使 Catalina 容器与具体的请求协议及 IO 方式解耦。
    • Coyote 将 Socket 输人转换为 Request 对象,交由 Catalina 容器进行处理.
    • 处理请求完成后,Catalina 通过 Coyote 提供的 Response 对象将结果写入输出流。

    4.3 HTTP

    • HTTP 协议可以说是互联网应用最广泛的网络协议,也是所有服务器均支持的基本的协议。
    • 它是一种基于请求与响应模式的、无状态的应用层协议。

    4.4 AJP

    • AJP ( Apache JServ Protocol )是 Alexei Kosut 创建的定向包( packet-oriented)通信协议,采用二进制格式传输可读文本。
    • 从该协议的命名不难看出,其最初的目标便是用于Apache HTTP Server ( Web服务器)与 Apache JServ 之间的通信,以提升 We b服务器与应用服务器集成时的通信性能。

    4.5 HTTP/2.0

    与 HTTP/1.1 相比,HTTP/2.0 在传输方面进行了如下重要改进。

    • 采用二进制格式传输数据而非 HTTP/1.1 的文本格式。
    • HTTP/2.0 对消息头采用了 HPACK 压缩,提升了传输效率。
    • 基于帧和流的多路复用,真正实现了基于一个链接的多请求并发处理。
    • 支持服务器推送。

    4.6 I/O

    在 8.5 版本之前(8.0版本之后), Tomcat 同时支持 BIO、NIO、NIO2、APR 这 4 种 I/O 方式,其中 NIO2 为 8.0 版本新增。
    自 8.5 版本开始,Tomcat 移除了对 BIO 的支持。

    4.6.1 BIO

    BIO 即阻塞式 IO,是 Java 提供的最基本的 I/O 方式。

    在网络通信(此处主要讨论 TCP/IP 协议)中,需要通过 Socket 在客户端与服务端建立双向链接以实现通信,其主要步骤如下。

    • 服务端监听某个端口是否有链接请求。
    • 客户端向服务端发出链接请求。
    • 服务端向客户端返回Accept(接受)消息,此时链接成功。
    • 客户端和服务端通过Send()、write()等方法与对方通信。
    • 关闭链接。

    4.6.2 NIO

    • 传统的 BIO 方式是基于流进行读写的,而且是阻塞的,整体性能比较差。
    • 为了提高 I/O 性能,JDK 于 1.4 版本引入 NIO,它弥补了原来 BIO 方式的不足,在标准 Java 代码中提供了高速、面向块的 I/O。
    • 通过定义包含数据的类以及以块的形式处理数据, NIO 可以在不编写本地代码的情况下利用底层优化,这是 BIO 所无法做到的。

    4.6.3 NIO2

    NIO2 是 JDK7 新增的文件及网络 IO 特性,它继承自 NIO,同时添加了众多特性及功能改进,其中最重要的即是对异步 IO (AIO)的支持。

    4.6.4 APR

    APR ( Apache Portable Runtime ),即 Apache 可移植运行库。正如官网所言,APR 的使命是创建和维护一套软件库,以便在不同操作系统(Windows、Linux等)底层实现的基础上提供统一的 API。

    4.7 小结

    • 本章我们介绍了 Tomcat 链接器框架 Coyote 以及目前支持的协议、I/O 方式。
    • 通过本章可以了解到客户端请求从接收到交由 Servlet 容器处理的整个过程。

    第 6 章 Tomcat 配置管理

    6.1 JVM 配置

    set JAVA_OPTS=-server -Xms1024m -Xmx2048m -XX: PermSize=256m -XX:MaxPermSize=512m
    需要添加到启动文件( catalina.bat/catalina.sh)的首行。

    参数说明

    • Xms:堆内存的初始大小。
    • Xmx:堆内存上限。
    • XX:PermSize:非堆内存初始大小,在 JDK 8 中已经由 -XX:MetaspaceSize 替代。
    • XX:MaxPermSize:非堆内存上限,在 JDK 8 中已经由 -XX:MaxMetaspaceSize 替代。

    6.2 服务器配置

    Tomcat 服务器的配置主要集中于 $CATALINA_HOME/conf 下的 catalina.policy , catalina.properties、context.xml、 server.xml、tomcat-users.xml、web.xml 文件。

    6.2.1 catalina.properties

    该文件主要用于 Catalina 容器启动阶段的配置,如服务器类加载器路径等.

    6.2.2 server.xml

    server.xml 是 Tomcat 应用服务器的核心配置文件,它包括 Tomcat Servlet 容器(Catalina)的所有组件的配置,用于创建 Tomcat Servlet 容器。

    • Server

      • server.xml的根元素为 Server,用于创建一个 Server 实例,默认使用的实现类为org.apache.catalina.core.StandardServer。
      • Server 可以内嵌的子元素为: Service、GlobalNamingResources 和 Listener.
      • 其中,GlobalNamingResources 定义了全局的命名服务。
        Listener 用于为 Server 添加生命周期监听器.
    • Service

      • 该元素用于创建 Service 实例,默认使用 org.apache.catalina.core.StandardService.
      • 默认情况下,Tomcat 仅指定了 Service 的名称,值为“Catalina”。
      • Service 可以内嵌的元素为:Listener、Executor 、Connector、Engine。
    • Executor

      • 默认情况下, Service 并未添加共享线程池配置。
      • 如果我们想添加一个线程池,可以在 < Service > 下添加如下配置:
      • < Executor name= “tomcatThreadPool” namePrefix=“catalina-exec -” maxThreads=“150” minSpareThreads= “4” />
      • maxThreads: 线程池中活动线程的最大数目,默认为200。
      • minSpareThreads: 备用线程的最小数量,默认为25。
    • Connector

      • Connector 用于创建链接器实例。默认情况下,server.xml配置了两个链接器,一个支持HTTP协议,一个支持AJP协议。因此大多数情况下,我们并不需要新增链接器配置,但是需要针对已有链接器进行优化。

      • 一个简单的链接器配置如下:
        < Connector port=""808o"protocol=“HTTP/1.1” connectionTimeout=“200oo” redirectPort="8443”/>

      • redirectPort: 如果当前Connector支持non-SSL请求,并且接收到一个请求,符合< security-constraint >约束,需要SSL传输,Catalina自动将请求重定向到此处指定的端口。

    • Engine

      • Engine 作为 Servlet 引擎的顶级元素,它支持以下嵌入元素:Cluster、Listener、Realm、Valve 和 Host。
      • 其中,Cluster 用于集群配置。
      • Listener 用于添加 Engine 一级的生命周期监听器, 默认情况下未配置任何监听器。
      • Valve 用于添加一个 org.apache.catalina.Valve 实现,拦截 Engine 一级的请求处理(除非需要跨 Host、跨 Web 应用进行拦截处理,否则不要轻易在 Engine 元素下配置 Valve )。
      • Host用于配置Tomcat虚拟主机组件。
    • Host配置

      • Host元素用于配置一个虚拟主机,它支持以下嵌入元素: Alias、Cluster、Listener、Valve ,Realm和Context。
      • 其中 Cluster、Listener、Valve、Realm 与Engine 相同,不同的是作用域为 Host。
      • Alias 用于为 Host 配置别名,这样我们除了通过 Host 名称访问当前主机外,还可以通过别名访问。
      • Context 用于配置 Host 下运行的 Web 应用。
    • Context配置

      • Context 用于配置一个 Web 应用,它支持的内嵌元素为:CookieProcessor、Loader、Manager、Realm、Resources、WatchedResource、JarScanner、Valve.

      • CookieProcessor 用于将 HTTP 请求中的 Cookie 头信息转换为 javax.servlet.http.Cookie 对象,或者将 Cookie 对象转换为 HTTP 响应中的 Cookie 头信息。如不指定,将默认使用 org.apache.tomcat.util.http.Rfc6265CookieProcessor。

      • Loader 用于配置当前 Context 对应的 Web 应用的类加载器。如不指定,将默认为 org.apache.catalina.loader. WebappLoader。

      • Manager 用于配置当前 Web 应用的会话管理器。如不指定,将默认为 org.apache.catalina.session.StandardManager。会话管理器存在独立启动和集群两种方式。

      • Resources 用于配置Web应用的有效资源(类文件、JAR 文件、HTML 等静态文件、JSP 等)。除非 Web 应用部分文件位于 Web 根目录之外,或存储于其他文件系统、数据库或者版本控制库,一般不需要额外添加资源,此时 Tomcat 会自动创建一个默认的文件系统,可以满足绝大多数的需要。

      • WatchedResource 用于配置自动加载文件检测。当指定文件发生更新时,Web 应用将会自动重新加载。对于每个 Web 应用, Tomcat 默认检测的文件是 WEB-INF/web.xml、SCATALINA_BASE/conf/web.xml。

      • JarScanner 用于配置 Web 应用 JAR 包以及目录扫描器, 扫描 Web 应用的 TLD 及 web-fragment.xml 文件. 如不配置,默认使用 org.apache.tomcat.util.scan.StandardJarScanner.

    • CookieProcessor

      • Tomcat提供了两个CookieProcessor实现: org.apache.tomcat.util.http.LegacyCookieProcessor 和 org.apache.tomcat.util.http.Rfc6265CookieProcessor,默认值为 Rfc6265CookieProcessor,
    • Loader

      • Loader 并不是一个 Java 类加载器,而是一个 Tomcat 组件,用于创建、加载以及销毁 Web 应用类加载器。它的生命周期管理与其他 Tomcat 组件一致。正因为如此,Web应用类加载器才会随着Web应用的状态而改变。

      • Tomcat 提供的默认实现为 org.apache.catalina.loader. webappLoader。大多数情况下,我们并不需要配置 Loader。但是在特殊情况下,Loader 配置可以使我们能够灵活控制 Java 类加载方式和顺序。

    • Manager配置

      • Tomcat提供了两种独立会话管理器方案: org.apache.catalina.session.StandardManager 和 org.apache.catalina.session.PersistentNanager。
        StandardManager 是 Tomcat 的标准实现,它提供了一种简单的会话存储方案,在 Tomcat 停止时(正常停止,而非强行关闭)会将所有会话串行化到一个文件中(默认为 SESSIONS.ser ),而在 Tomcat 启动时,将从该文件加载有效会话。
    • Resources
      在 8.0 之前的版本中,Tomcat 通过< Resources >配置 Web 应用的静态资源,以实现类加载以及提供 HTML、JSP 或其他静态文件的访问服务。

    6.2.3 context.xml

    • 此处的 context.xml 文件既指 SCATALINA_BASE/conf/context.xml,又指 Web 应用中的 META-INF/context.xml 文件。
    • 前者配置所有 Web 应用的公共信息,后者配置每个 Web 应用的定制化信息。

    6.3 Web应用配置

    • web.xml 是 Web 应用的部署描述文件,它支持的元素及属性来自于 Servlet 规范定义。
    • 在 Tomcat 中,Web 应用的部署描述信息包括 SCATALINA_BASE/conf/web.xml 中的默认配置以及 Web 应用 WEB-INF/web.xml 下的定制配置.

    Web部署描述文件的配置主要分为如下几类:

    • ServletContext初始化参数
    • 会话配置
    • Servlet声明及映射
    • 应用生命周期监听器
    • Filter定义及映射
    • MIME类型映射
    • 欢迎文件列表
    • 错误页面
    • 本地化及编码映射
    • 安全配置
    • JNDI配置

    6.3.1 ServletContext 初始化参数

    我们可以通过< context-param>添加 ServletContext 初始化参数,它配置了一个键值对.
    我们可以使用它配置加载文件路径、应用运行状态(开发、测试、生产)以及日志等。其配置方式如下,可以同时配置多个初始化参数。
    < context-param>
    < description>The servletContext parameter</ description>
    < param-name>name</ param-name>
    < param-value>The parameter value</ param-value>
    </ context-param>

    6.3.2 会话配置

    < session-config>用于配置 Web 应用会话,包括超时时间、Cookie 配置以及会话追踪模式。
    它将覆盖 server.xml 和 context.xml 中的配置。
    < session-config>
    < session-timeout>30</ session-timeout>
    < cookie-config>
    < name>JSESSIONID</ name>
    < domain>sample.myApp.com< / domain>
    < path>/</ path>
    < comment>The session cookie< / comment>
    < http-only>true</ http-only>
    < secure>true</ secure>
    < max-age>3600</ max-age>
    </ cookie-config>
    < tracking-mode>COOKIE</ tracking-mode>
    </ session-config>

    < session-timeout>用于配置会话超时时间,单位为分钟。

    • < cookie-config>用于配置会话追踪 Cookie, 需要关注的是 http-only 和 secure,这两个属性主要用来控制 Cookie 的安全性。
    • 只有当会话追踪模式是 Cookie 时,该配置才会生效(Tomcat默认支持通过 Cookie 追踪会话)。
    • 此外,< domain>用于配置当前 Cookie 所处的域, path 用于配置 Cookie 所处的相对路径。

    6.3.3 Servlet 声明及映射

    • load-on-startup: 用于控制在 Web 应用启动时,Servlet 的加载顺序。
    • 如果值小于0,在 Web 应用启动时,将不加载该 Servlet。

    6.3.4 应用生命周期监听器

    • < listener>用于添加Web应用生命周期监听器,可以同时配置多个。
    • 监听器必须实现 javax.servlet.ServletContextListener 接口。
    • Web 应用启动时会调用监听器的 contextInitialized() 方法,停止时调用其contextDestroyed() 方法。
    • 启动时,ServletContextListener 的执行顺序与 web.xml 中的配置顺序一致,停止时执行顺序恰好相反。

    6.3.5 Filter 定义及映射

    • < filter>用于配置 Web 应用过滤器,用来过滤资源请求及响应。
    • 经常用于认证、日志、加密、数据转换等。

    6.3.6 MIME 类型映射

    • MIME (Multipurpose Internet Mail Extensions )即多用途互联网邮件扩展类型,用于设定某类型的扩展名文件将采用何种应用程序打开。
    • 当我们通过请求访问该扩展名的资源文件时,浏览器将自动使用指定的应用程序打开返回的资源文件。
    • 多用于客户端自定义的文件名,如 Word 、Excel 等。

    6.3.9 本地化及编码映射

    < locale-encoding-mapping-list>用于指定本地化与响应编码的映射关系, 如果未显式地指明响应编码, 服务器将按照当前本地化信息确定响应编码。
    < locale-encoding-mapping-list>
    < locale-encoding-mapping>
    < locale>zh</ locale>
    < encoding>GBK</ encoding>
    </ locale-encoding-mapping>
    </ locale-encoding-mapping-list>

    6.3.10 安全配置

    通过 web.xml 中的安全配置, 可以为 Web 应用增加页面访问权限。

    6.6 小结

    • 本章从多个方面介绍了Tomcat的配置。
    • 首先是 JVM 和服务器配置文件,如果希望深度定制及优化应用服务器,这是必须要详细了解的。
    • 其次是 Web 应用配置,这部分虽然属于 Servlet 规范的内容,但是与 Web 应用的运行部署密切相关,因此也纳入了本章进行讲解。
    • 同时,还介绍了 Tomcat 提供的几个过滤器实现,它们可以用于 Web 应用安全或者负载环境。
    • 最后,简单介绍了 Tomcat 应用管理,包括 Web 界面、URL 命令行、Ant 任务及JMX。

    第 7 章 Web服务器集成

    7.1 Web 服务器与应用服务器的区别

    • Web 服务器

      • Apache HTTP Server、Nginx、Lighttpd、IIS 等
    • 应用服务器

      • Tomcat、JBoss、Weblogic、WebSphere 等
    • Web服务器拥有性能优势,可以支持负载均衡,

    • 应用服务器可以提供各种技术组件用于系统开发构建,可以支持应用集群。

    • 应用服务器对于静态资源的处理普遍性能相对较差,
      而 Web 服务器则可以充分利用操作系统本地 IO 的优势。

    • 同时,对于静态资源,Web 服务器可以通过缓存等各种方式来提高其访问性能。

    • Web 服务器普遍支持作为前置的请求调度器以支持负载均衡.
      在这里插入图片描述

    7.4 与 Ngnix 集成

    7.4.4 Tomcat 集成

    Nginx 集成多个应用
    在这里插入图片描述
    Nginx 负载均衡配置
    在这里插入图片描述

    7.6 小结

    本章首先简单介绍了一下 Web 服务器与应用服务器的区别,并列举了常见的几个需要 Web 服务器与应用服务器集成的场景。

    第 8 章 Tomcat 集群

    可以使用 spring-session 来将会话缓存在 redis 中.
    参考 https://blog.csdn.net/jsbylibo/article/details/106544932

    第 9 章 Tomcat 安全

    9.1 配置安全

    9.1.1 安装部署问题

    • 移除 Tomcat 自带的几个 Web 应用, docs, examples, ROOT.

    • 如果我们已经使用第三方工具来管理 Tomcat, 那么 host-manager 和 manager 可以直接移除.

    • 如果我们希望使用这两个包,那么可以为它们增加IP访问限制(Remote-AddrValve,可以查看这两个应用下 META-INF/context.xml 文件中的内容。8.5 版本之前,需要手动开启,而 8.5 版本之后,则默认开启并只有本机可以访问)。

    • 我们应当避免使用 root 用户权限启动 Tomcat (在 Linux 环境下),而应该单独为 Tomcat 服务器建立一个用户,并且授予运行应用服务器所需的最小系统权限,例如 Tomcat 用户不能远程访问 Linux 服务器.

    9.1.2 server.xml 配置

    • 移除不必要的组件
      删除 AJP 链接器(8009).

    • 如果我们不需要使用 host-manager 和 manager 管理 Tomcat, 可以将< Engine>下的< Realm>以及名为 “UserDatabase” 的 Resource 删除。

    • 修改关键配置
      修改 server.xml 中的 shutdown 监听端口和 SHUTDOWN 指令字符串.
      如果不使用该功能,可以直接将其禁用(将 port 属性设置为-1 );

    • 如果部署的 Web 应用仅允许有限的客户端访问(如一些管理型应用),此时可以通过 Remote-AddrValve 控制访问客户端 IP。

    第 10 章 Tomcat 性能调优

    10.1 Tomcat 性能测试及诊断

    10.1.2 性能测试工具

    • ApacheBench
      • ApacheBench ( ab)是一款 Apache Server 基准测试工具
    • Apache JMeter
      • JMeter 是一款采用 Java 开发的负载测试工具,它既可以用于测试静态资源访问,又可以用于测试动态请求,如 Web ( HTTPHTTPS)、FTP、JDBC、SOAP、LDAP、JMS、Java、JUnit,等等。
      • JMeter 可以用于模拟服务器、网络、对象使用等不同类型的高负载,以综合分析应用系统性能。

    10.1.3 数据采集及分析

    • 网络

      • Linux平台有许多可以查看网络使用情况的工具,查看总体带宽的如 nload、bmon、slurm 等,查看每个套接字的如 iftop、iptraf、tcptrack、pktstat 、netwatch 等。
    • 内存/CPU

      • 首先,可以通过 Windows 的任务管理器或者 Linux 的 top 命令查看服务器整体的资源使用情况。

      • 如果我们仅仅希望查看服务器总体的 CPU、内存以及 I/O 读写情况,还可以使用 vmstat 命令.

      • 幸运的是,对于基于 Java 的应用,JDK 在发布包中提供了内存及垃圾回收监控工具(位于$JAVA_HOME/bin)用于分析JVM的运行状况。

      • 这些工具中,最常用的是 jstat 命令,它的命令格式如下:
        jstat [ general0ption | outputoptions vmid [ interval[s|ms] [ count ] ]

      • 除了 jstat,Java 还提供了 jmap 命令用于打印进程的堆内存详情、产生对象数量以及内存使用情况.

      • VisualVM 是一款 Java 应用监控以及故障排除的工具,它利用诸如 jvmstat、JMX、SA、AttachAPI 等技术获取运行数据,采用最快、最轻量级的技术以使被监控应用的开销降至最低。

    • 数据库访问

      • 首先,我们可以通过数据库自带的功能来查看 SQL 语句的执行情况,对于 Oracle 来说,可以通过 VSSQLAREA、VSSQLTEXT 两个视图来查看 SQL 语句的执行,如执行时间、读写情况等.

      • 对于MySQL来说,它可以支持以日志的形式记录执行缓慢的SQL

      • 其次,我们还可以通过一些工具,以非侵入的形式在应用级记录 SQL 日志,如 p6spy,下载地址为: https:/lgithub.com/p6spy/p6spy。

    第 11 章 Tomcat 附加功能

    11.1 Tomcat 的嵌入式启动

    • 除了 Tomcat 之外,在嵌入式方面使用较多的便是 Jetty ( http://www.eclipse.org/jetty/ )和 Undertow ( http://undertow.io/ )。
    • 这两个项目分别由 Eclipse 和 Redhat 维护。
    • 因此,从一定程度上讲, Tomcat 更适合企业级应用嵌入式,而 Jetty 和 Undertow 更适合轻量级、分布式的云计算环境。

    SpringBoot 项目中使用 Jetty servlet 容器替换 Tomcat 容器

    <!-- SpringBoot 项目中使用 Jetty servlet 容器替换 Tomcat 容器 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-tomcat</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jetty</artifactId>
    </dependency>
    

    11.2 Tomcat 中的 JNDI

    • JNDI ( Java Naming and Directory Interface,Java 命名目录接口)是一套用于Java 目录服务的 API。
    • Java 应用可以通过 JNDI API 按照命名查找数据和对象。
    • 与大多数主机系统使用的 Java API 一样,JNDI 独立于其底层的实现,指定了一个服务提供者接口(SPIR),便于以松耦合的形式插人入框架。
    • 根据供应商的不同,JNDI 可以用于服务器、文件、数据库等。
    • JNDI 在 J2EE 中使用非常广泛,很多技术都需要 JNDI 作为支持,诸如 LDAP、CORBA、RMI、EJB、JDBC 和 JMS 等。
    • JNDI 典型的应用场景包括以下两种。
    • 将应用连接到一个外部服务,如数据库、LDAP;
    • Servlet 通过 JNDI 查找 Web 容器提供的配置信息。
    展开全文
  • Tomcat源码解析 提示:这里可以添加系列文章的所有文章的目录,目录需要自己手动添加 例如:第一章 Python 机器学习入门之pandas的使用 提示:写完文章后,目录可以自动生成,如何生成可参考右边的帮助文档 文章...

    Tomcat源码解析


    《Tomcat源码》系列文章集合:
    Tomcat结构设计
    Tomcat启动过程
    Tomcat类加载器
    Tomcat的Web请求和处理过程


    前言

    Tomcat做为后端开发的必备知识储备,深入了解一下源码对于后端工程师的个人发展是很有帮助的,本章介绍一个如果使用Idea来调试Tomcat以及Tomcat的架构设计。
    本作者的Tomcat源码仓库上线了,仓库地址
    本作者的Tomcat源码仓库上线了,仓库地址
    本作者的Tomcat源码仓库上线了,仓库地址
    本作者的Tomcat源码仓库上线了,仓库地址
    本作者的Tomcat源码仓库上线了,仓库地址


    一、如何获得Tomcat源码

    不重复造轮子,这个博主写的 轻松构建Tomcat源码很不错,只要根据步骤来操作,即可实现在idea上调试tomcat的源码。

    二、Tomcat总体架构

    虽然不想抄书,但是书写的是真好。

    2.1 Server

    首先我们写一个服务器程序,肯定是需要一个Server,它j通过监听端口,接受用户的请求,并做处理,然后返回结果,所以,Server是肯定需要的。所以我们设计了Server,如下图,我们使用start启动服务器,打开socket链接,监听服务器端口,并在接受到客户端的请求时进行处理并返回响应,stop关闭服务器,并释放网络资源。
    在这里插入图片描述
    我们这样设计,在简单处理,并且访问量不大的时候是够用的。

    2.2 Connector和Container

    很快我们发现,将请求监听与请求处理放在一起扩展性太差了。比如我们想支持多种网络协议(tomcat支持http和AJP两种协议),这些协议的处理,是不是就得写多个Server呢?所以我们应该把请求和处理操作分开。
    在这里插入图片描述
    至此,一个Server包含多个Connector(链接器)和Container(容器)
    Connector:开启Socket并监听客户端请求,返回响应数据;
    Container:负责具体的请求处理
    但是这时候又发现了其他的问题:Connector接受的请求由那个Container处理呢?,这是我们需要建立映射规则。
    在这里插入图片描述
    Tomcat使用Service来维护映射规则,一个Server可以包含多个Service,每一个Service都是独立的,他们共享一个JVM以及系统类库。
    一个Service负责维护多个Connector和一个Container,这样来自Connector的请求只能有它所属的Service维护的Container处理。
    在这里Container是一个通用的概念,为了明确功能,并与Tomcat中的组件名称相同,可以将Container命名为Engine,Engine相当于是Servlet引擎。
    在这里插入图片描述

    2.3 Container设计

    上面解决了接受请求和请求处理之间的耦合关系,但是Engine在对请求进行处理的时候,要根据请求找到合适的Web应用,所以我们加入Context,来表示Web应用。并且一个Engine包含多个Context
    在这里插入图片描述
    Context也拥有start和stop方法,用以启动Web应用时加载资源以及停止时释放资源。采用这种方式设计,将加载和加载资源的过程分解到每个组件中,该组件充分解耦,提高服务器的可扩展性和可维护性。
    通过查看tomcat的配置文件我们发现,我们可以让tomcat处理多个域名的服务,比如下面我们在tomcat中配置了映射路径,以及www.jzyai,com的域名,此时tomcat不仅可以处理localhost的域名,还可以处理www.jztai.com的域名:
    啊大大伟大哇

    既然我们要提供多个域名的服务,那么就可以将每个域名视为一个虚拟的主机,在每个虚拟主机下包含多个Web应用。因为对于客户端用户来说,他们并不了解服务端使用几台主机来为他提供服务,只知道每个域名提供哪些服务,因为应用服务器将每个域名抽象成一个虚拟主机从概念上是合理的。根据这个想法修改后的设计如下图所示:
    在这里插入图片描述
    用Host表示虚拟主机的概念,一个Host可以包含多个Context。
    Servelt规范规定,一个Web应用可以包含多个Servelt实例以处理来自不同链接的请求。因此,我们还需要一个组件用来标识Servelt,在Tomcat中,Servelt定义被称为Wrapper。至此修改之后的设计图如下:
    在这里插入图片描述
    因为Engine、Host、Context还有Wrapper都属于容器,并且都可以启动、关闭、添加子容器,所以我们抽象出一个Container父类,让Engine、Host、Context还有Wrapper继承它。此时Service持有的是Engine接口,是依赖关系,其他组件是父子继承关系。
    在这里插入图片描述
    此外,Tomcat的Container需要经常执行一些异步处理,而且是定期执行,比如每隔30s执行一次,Tomcat对于WebApp文件夹下面war包的扫描就是隔一段时间一次,所以我们在部署到webapp下的应用会及时的加载。因此我们在Container类中定义了backgroundProcess函数,每个容器组件仅需要实现Container的backgroundProcess方法即可,不必考虑再创建异步线程。

    2.4 LifeCycle

    我们通过上边的设计图很容易就发现,几乎所有的组件都存在 启动、停止等生命周期方法,用于生命周期管理的特性。所以我们再抽象出一个生命周期的通用接口LifeCycle。

    在这里插入图片描述
    同时,该接口支持组件状态以及状态之间的转换,支持添加事件监听器(LifecycleListener),用于监听组件的状态变化。我们可以采用一致的机制来初始化、启动、停止、以及销毁各个组件,如Tomcat核心组件的默认实现均继承LifeCycleMBeanBase抽象类,该类不但负责组件各个状态的转换和事件处理,还将组件自身注册为MBean,以便通过Tomcat的管理工具进行动态维护。
    在这里插入图片描述
    首先,每个生命周期方法可能对应数个状态切换,以start为例,即分为启动前、启动中、已启动,这三个状态之间自动转换。其次,并不是每个状态都会触发生命周期事件,也不是所有的生命周期事件均存在对应的状态。状态与应用生命周期时间的对应如下图所示:
    在这里插入图片描述

    2.5 Pipeline和Value

    从架构设计的角度来考虑,至此的应用服务器设计主要完成了我们对核心概念的分解,确保了整体架构的可伸缩性和可扩展性,除此之外,我们还要考虑灵活性,使其同样易于扩展。
    Tomcat使用职责链模式来实现客户端请求的处理—请求处理也是职责链模式典型的应用场景之一,Netty中在入站和出站时使用双向链表来实现指责链模式,使应用具有很好的扩展性。
    Tomcat定义了Pipeline(管道)和Value(阀)两个接口。前者用于构造职责链,后者代表职责链上的每个处理器。器设计图如下
    在这里插入图片描述
    PipleLine中维护了一个基础的Value,始终位于Pipeline的末端,即最后执行,封装了具体的请求处理和输出相应的过程,然后通过addValue()方法,我们可以为PipeLine添加其他的Value。后添加的Value位于基础Value之前,并按照添加顺序执行。Pipeline通过获得首个Value来启动整个链条的执行。Tomcat的每个层次的容器(Engine、Host、Context、Wrapper)均有相应的基础Value实现,同时维护一个PipeLine实例,也就是说,我们可以在任何层次的容器上针对请求处理做扩展。
    由于Tomcat每个层次的容器均通过Pipeline和Value进行请求处理。所以我们将职责链交由Container进行维护。修改之后的设计图如下:
    在这里插入图片描述

    2.6 Connector设计

    Connector应该具有的功能如下:
    (1)监听服务器端口,读取来自客户端的请求
    (2)将请求数据按照指定协议进行解析
    (3)根据请求地址匹配正确的容器进行处理
    (4)将相应返回给客户端。
    Tomcat是支持多协议,默认支持HTTP和AJP,同时Tomcat支持多种I/O方式,包括BIO(8.5版本之后移除),NIO、APR。而且在tomcat8之后新增了NIO2和HTTP2的协议。因此监听服务器请求与协议解析之间又可以解耦。修改之后的设计如下:
    在这里插入图片描述
    Tomcat中,ProtocolHandler表示一个协议处理器,针对不同协议和I/O方式,提高了不同的实现,比如HttpNioProtocol表示基于NIO的Http1.1协议处理器,ProtocolHandler包含一个EndPoint用于启动Socket监听,该接口按照I/O方式进行分类实现,如Nio2EndPoint表示非阻塞式Socket I/O。还包含一个processor用于按照指定协议读取数据,并将请求交由容器处理,如Http11NioProcessor表示在NIO的方式下HTTP请求的处理类。
    当Processor读取客户端请求后,需要按照请求地址映射到具体的容器进行处理,这个过程即请求映射,由于Tomcat各个组件采用通用的生命周期管理,而且可以通过管理工具进行状态变更,因此请求映射除了考虑映射规则外,还要考虑容器组件的注册与销毁。
    Tomcat通过Mapper和MapperListener两个类实现上述功能。前者用于维护容器映射信息,同时按照映射规则查找容器,后者实现了ContainerListener和LifecycleListener,用于在容器组件状态发生变更时,注册或者取消对应的容器映射信息。为了实现上述功能,MapperListener实现了LifeCycle接口,当其启动时,会自动作为监听器注册到各个容器组件上,同时将以创建的组件注册到Mapper。

    Processor根据请求进行映射到容器的操作,目前没有,Tomcat通过适配器模式实现了Connector与Mapper、Container的解耦。Tomcat默认的Connector实现(Coyote)对应的适配器为CoyoteAdapter。也就是说,如果你希望使用Tomcat的连接器方案,但是又想脱离Servelt容器,此时只需要实现Adapter即可。至此,设计图如下:
    在这里插入图片描述
    至此,我们梳理一下:首先Server就代表一个tomcat实例,tomcat启动之后,Service就启动了,Service的功能分为两个方面(1)连接器(2)容器;连接器负责监听用户的请求,当接受到用户请求时,交给容器去进行处理。EndPoint负责监听端口的请求,当收到请求的时候,交给Processor来接受数据,接受完的数据需要交给容器去处理,此时需要确定该交给哪个容器,此时Mapper会建立映射文件存储着容器的对应关系,从Mapper中找到指定容器之后,就将数据交给对应容器进行处理,如果找不到映射,这时候就出错了。交给容器之后是一个责任链模式,首先经过Engine,然后再经过Host、Context、Wrap进行层层的处理。Mapper是由Service来进行维护的。MapperListener是用来监听Service的,一旦服务发布到Service上了,MapperListener就负责更新Mapper。

    2.7 Executor

    当多个用户同时请求单个资源的时候,就会出现并发问题,比如有N个用户请求服务器,此时用一个线程处理不过来,就会造成客户端的请求串行化,性能很低。所以在Tomcat中,Endpoint会启动一组线程来监听Socket端口,当接受到客户端请求后,会创建请求对象,并交由线程池处理,由此支持并发处理客户端请求。添加线程池之后的设计图如下:
    在这里插入图片描述
    Tomcat中,Excutor由Service进行维护,因此同一个Service中的组件可以共享一个线程池。

    2.8 BootStrap

    前面所述的是应用服务器本身,但是除了应用服务器之外,还得有启动服务器的入口程序,如果使用Tomcat自己启动自己的话,就会造成核心应用与启动器之间存在严重耦合的情况,所以将启动器和应用分开是解耦合的一种操作,这个想法很值得我们学习。
    Tomcat通过类Catalina提供了一个shell程序,用户解析service.xml并创建各个组件(Tomcat使用基于SAX事件处理的Digester来解析XML文件),同时负责启动、停止服务器。
    Tomcat使用Bootstrap作为应用服务器的启动入口,Bootstrap负责创建Catalina实例,根据执行参数调用Catalina相关方法完成针对应用服务器的操作(启动、停止)。
    在这里插入图片描述
    在这里插入图片描述

    总结

    Tomcat的功能是接受用户请求、对请求进行处理,然后返回处理的接口;首先为了实现接受请求与处理请求之间的解耦,分成了连接器和容器两部分,同时为了将业务处理与服务器之间解耦,就抽象出了Service,一个Service包含多个Connector和一个Engine;一个Engine包含多个Host,一个Host包含多个Context,一个Context包含多个Wrapper(Servelt)。在连接器中我们又将连接和处理分开了,EndPoint用来监听用户请求,Processor用来接受请求数据,接收完请求数据之后去Mapper中寻找指定的容器,然后交由对应的容器进行处理。容器的处理采用的是责任链模式进行的层层处理。由于所有的组件都存在生命周期阶段(开始、启动、结束等),所以抽象出生命周期接口LifeCycle。由于容器类Engine、Host、Context还有Wrapper,都可以启动、关闭、添加子容器以及异步实现一些耗时操作,所以基于容器类的相同属性,抽象出了父类Container。为了解决并发问题,Tomcat使用线程池Excutor进行多线程的处理,Endpoint会启动一组线程来监听Socket端口,当接受到客户端请求后,会创建请求对象,并交由线程池处理,由此支持并发处理客户端请求。为了实现启动入口与核心环境之间的解耦,引入Bootstrap作为Tomcat的启动器。

    展开全文
  • tomcat架构解析.pdf

    2019-07-23 09:36:31
    本书从功能组件、协议、规范,到详细配置等各个方面,系统性介绍了Tomcat架构的实现方案及使用方式,有助于读者详细了解应用服务器的架构及工作原理。主要内容包括: ★ Tomcat的基础组件架构及工作原理; ★ ...
  • tomcat架构解析.zip

    2019-09-26 14:14:30
    对于学习了一段时间tomcat的同学很有帮助,帮助解析tomcat架构。方便对tomcat的理解,以及更好的tomcat调优。
  • 1.Tomcat组件架构设计    1)server  服务器可以描述为这样一个应用:接收客户端发来的请求数据并进行解析,完成相关业务处理,然后把处理结果作为相应返回给客户端。  通常我们可以使用serversocket监听...

    1.Tomcat组件架构设计

     

        1)server

            服务器可以描述为这样一个应用:接收客户端发来的请求数据并进行解析,完成相关业务处理,然后把处理结果作为相应返回给客户端。

            通常我们可以使用serversocket监听指定端口来实现该功能

     

        2)Connection和Container(Engine)

            当我们将请求监听和请求处理放在一起的时候扩展性就很差。比如当我们想适配多种网络协议,但是请求处理却相同的时候。

            处理方案就是:将网络协议和请求处理从概念上分开。Connection负责开启socket并监听客户端请求、返回响应数据;Container(Engine)负责具体的请求处理。

     

        3)Service

            上述方案的缺陷就是无法很好的判断Connection由哪个Container(Engine)来处理。

            采用service方案,一个server包含多个service(它们相互独立),一个service包含多个Connection和一个Container,这样,connection的请求只能由该container来处理

            由于Container表示一个更加通用的概念,为了与Tomcat组件命名一致,将Container重新命名为Engine,用于表示整个servlet引擎

     

        4)Context

            上述解决了网络协议和容器的解耦。下面我们需要在Engine中支持管理web应用。当接收到Connection请求时,能够找到一个合适的Web应用来处理。Context就代表一个Web应用

     

        5)Host

            为了提供对多个域名的服务,我们可以将每个域名视为一个虚拟的主机。在每个Host下包含多个Context

           

        6)Wrapper

            在一个Web应用中,可以包含多个servlet实例来处理不同链接的请求。因此,需要一个组件概念来表示Servlet定义,在Tomcat中servlet定义被称为Wrapper

     

        7)Container

            容器代表一类组件,这类组件的作用就是接收客户端请求并返回响应数据,具体操作委派到子组件完成。

            Engine、Host、Context、Wrapper均继承自Container

        8)LifeCycle

            所有的组件均存在启动、停止等生命周期方法,拥有生命周期管理的特性,我们将这个抽取出来作为接口LifeCycle,定义生命周期管理的核心方法。

        9)Executor

            tomcat的并发,提供了Executor接口来表示一个可以在组件间共享的线程池。该接口同样继承LifeCycle接口

            共享范围:Executor由Service维护,因此同一个Service中的组件可以共享一个线程池

            

        10)Bootstrap和Catalina

            Catalina提供一个shell程序,用于解析service.xml创建各个组件。同时负责启动、停止应用服务器

            Bootstrap作为应用服务器启动入口。Bootstrap负责创建Catalina,根据执行参数调用Catalina相关方方法完成对应用服务器的操作

     

        总结:

            * Server 表示整个servlet容器,因此Tomcat容器中只有一个Server实例

            * Service 表示一个或多个Connector的集合。这些Connector共享同一个Container来处理其他请求。在一个Server中可以包含多个Service,这些Service相互独立

            * Connector Tomcat连接器,用于监听并转换为Socket请求,将该请求交由Container处理,支持不同的协议及不同IO方式

            * Container 表示能够接收请求并返回响应的一类对象。在Tomcat中存在不同级别的容器:Engine、Host、Context、Wrapper

            * Engine 表示整个Servlet引擎,Engine为最高级别的容器。尽量Engine不是直接处理请求的容器却是获得目标容器的入口

            * Host 表示Engine中的虚拟机,与一个服务器的网络名有关,如域名等。客户端可以使用这个网络名连接服务器,这个名称必须要在DNS服务器上注册

            * Context 用于表示ServletContext,在Servlet规范中,一个ServletContext表示一个Web应用

            * Wrapper 表示Web应用中定义的Servlet

            * Executor 表示Tomcat组件间可以共享的线程池

     

     

    2.请求处理过程

     

        从本质上讲,应用服务器的处理开始于监听的Socket端口接收到数据,结束于将处理结果写入Socket输出流

        * 应用服务器将请求按照既定协议进行读取,并将其封装为与具体协议无关的请求体

        * 按照请求映射规则将请求定位到具体的处理单元(使用框架的话SpringMVC等则会将请求匹配到Servlet下的一个控制器)

        * 业务处理结束,将结果封装到一个与协议无关的响应对象

     

    3.Tomcat类加载方案

     

        应用服务器通常会创建类加载器以实现更灵活的控制。

        * 隔离性:Web应用类库互相隔离,避免依赖库或应用包相互影响。设想有两个应用,一个采取Spring2.X,一个采取Spring4.X,而应用服务器使用同一个类加载器,那么应用之间会因为jar包覆盖导致无法启动

        * 灵活性:Web应用之间的类加载器相互独立,我们就能只针对一个Web应用重新部署

        * 性能:每个Web应用都有一个类加载器,则Web应用在加载类时,不会搜索其他Web应用包含的jar包,性能自然高

        1)Common 位于Tomcat顶层的公共类加载器,默认指向Tomcat_home/lib下的包

        2)Catalina 用于加载Tomcat应用服务器的类加载器,路径为server.loader,默认为空

        3)Shared 所有web应用的父加载器,路径为shared.loader,默认为空

        4)Web 加载WEB-INF/classes下的未压缩的class、资源文件及WEB-INFO/lib下的jar包,该类加载器只对当前web应用可见

     

        在catalina.jar org.apache.catalina.loader包下可以看到关于ClassLoader的实现

     

     

    4.通过server.xml来查看Tomcat各组件之间的关系

        我们在Eclipse中创建一个web项目,springweb,并在Eclipse中关联Tomcat8.5,并在Tomcat中关联springweb,启动Tomcat,可以看到生成的server.xml如下所示:

    <?xml version="1.0" encoding="UTF-8"?>
    <Server port="8005" shutdown="SHUTDOWN">
      <Listener className="org.apache.catalina.startup.VersionLoggerListener"/>
      <!-- Security listener. Documentation at /docs/config/listeners.html
      <Listener className="org.apache.catalina.security.SecurityListener" />
      -->
      <!--APR library loader. Documentation at /docs/apr.html -->
      <Listener SSLEngine="on" className="org.apache.catalina.core.AprLifecycleListener"/>
      <!-- Prevent memory leaks due to use of particular java/javax APIs-->
      <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
      <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
      <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
    
      
      <GlobalNamingResources>
       
        <Resource auth="Container" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase"/>
      </GlobalNamingResources>
    
      <!-- A "Service" is a collection of one or more "Connectors" that share
           a single "Container" Note:  A "Service" is not itself a "Container",
           so you may not define subcomponents such as "Valves" at this level.
           Documentation at /docs/config/service.html
       -->
      <Service name="Catalina">
        <!-- A "Connector" represents an endpoint by which requests are received
             and responses are returned. Documentation at :
             Java HTTP Connector: /docs/config/http.html
             Java AJP  Connector: /docs/config/ajp.html
             APR (HTTP/AJP) Connector: /docs/apr.html
             Define a non-SSL/TLS HTTP/1.1 Connector on port 8080
        -->
        <Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>
        <!-- Define an AJP 1.3 Connector on port 8009 -->
        <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>
    
    
        <!-- An Engine represents the entry point (within Catalina) that processes
             every request.  The Engine implementation for Tomcat stand alone
             analyzes the HTTP headers included with the request, and passes them
             on to the appropriate Host (virtual host).
             Documentation at /docs/config/engine.html -->
    
        <!-- You should set jvmRoute to support load-balancing via AJP ie :
        <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
        -->
        <Engine defaultHost="localhost" name="Catalina">
          <!-- Use the LockOutRealm to prevent attempts to guess user passwords
               via a brute-force attack -->
          <Realm className="org.apache.catalina.realm.LockOutRealm">
            <!-- This Realm uses the UserDatabase configured in the global JNDI
                 resources under the key "UserDatabase".  Any edits
                 that are performed against this UserDatabase are immediately
                 available for use by the Realm.  -->
            <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
          </Realm>
    
          <Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
    
            <!-- SingleSignOn valve, share authentication between web applications
                 Documentation at: /docs/config/valve.html -->
            <!--
            <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
            -->
    
            <!-- Access log processes all example.
                 Documentation at: /docs/config/valve.html
                 Note: The pattern used is equivalent to using pattern="common" -->
            <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%h %l %u %t &quot;%r&quot; %s %b" prefix="localhost_access_log" suffix=".txt"/>
    
          <Context docBase="springweb" path="/springweb" reloadable="true" source="org.eclipse.jst.jee.server:springweb"/></Host>
        </Engine>
      </Service>
    </Server>

        由上可知,Tomcat结构图可如下所示:

        * Tomcat只要一个Server,一个Server可以有多个Service,一个Service可以有多个Connection和Container

        * Server掌管整个Tomcat的生死大权

        * Service是对外提供服务的

        * Connector用于接收请求并将请求封装成Request和Response来具体处理

        * Container用于管理和封装Servlet,以及处理具体Request请求

     

    参考:Tomcat架构解析(刘光瑞)

     

    展开全文
  • tomcat架构解析_带索引书签目录_刘光瑞(著) .pdf.zip
  • title: Tomcat静态架构date: 2018-10-24 13:46:20...《Tomcat架构解析》读书笔记一 大体设计思路 接收客户端请求(Connector、线程管理Executor)-> 解析请求(ProtocolHandler、Processor)-> 处理请求(Co...
  • tomcat架构解析_PDF电子书下载 高清 带索引书签目录_刘光瑞(著) 人民邮电出版社
  • Tomcat架构解析》一书出版上市

    千次阅读 2017-05-17 09:02:43
    Tomcat架构解析》一书已经正式出版上市,感兴趣的朋友可以通过当当或者京东进行订购。京东购买地址当当购买地址
  • 作为一款知名的轻量级应用服务器,Tomcat架构设设计(如生命周期管理、可扩展的容器组件设计、类加载方式)可以为我们的服务器中间设计,甚至是应用系统组件设计提供非常好的借鉴意义。本章概要的介绍了Tomcat的...
  • tomcat总体架构总体设计ServerConnector和Containertomcat启动请求处理类加载器小结 总体设计 Server 我们可以将服务器描述为一个应用: 它接收其它计算机(客户端)发来的请求数据并进行解析,完成相关业处理,然后...
  • tomcat架构解析_刘光瑞(著) 人民邮电出版社_ 2017-05-01 带目录标签,完整
  • 其次,本书不局限于对Tomcat架构原理的讲解。对于像服务器这种技术方案相对复杂的应用程序,作为技术人员我们天生的就会好奇它是怎么高效的工作的。那么好奇之后呢?无外乎两点:1、借鉴它某些组件的原理,应用到...
  • 基于Tomcat的全面解析应用服务器架构 涵盖Tomcat所有组件的详细配置
  • 为什么我要写《Tomcat架构解析

    千次阅读 2017-06-06 09:21:53
    上个月中旬,写作断断续续近两年的书《Tomcat架构解析》顺利出版,两年来的付出也总算有了回报,让人些许欣慰。图书上架销售将近一个月来,陆陆续续收到一些反馈的意见和建议,读者的鞭策和鼓励是我不断学习进步的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,058
精华内容 423
关键字:

tomcat架构解析