第3章 Jetty构架
讲解构架是为了了解如何配置。讲解为什么要懂得构架?为什么不直接讲配置?不理解构架就没办法更好地懂得如何使用,如何去配置。
3.1 构架概述
用Jetty官方文档的话来讲“从2万尺的高空看Jetty”，如图2.1：
Connector（连接器）集合负责接收HTTP连接。handler（处理器）集合负责处理连接请求并给予响应。而Jetty Server（服务器）则是前两者的管道连接器。负责创建并初始化connector、handler、ThreadPool组件，然后调用start方法启动他们。ThreadPool（线程池）为他们完成工作提供线程。
Jetty Server和3大类型的组件相关联：
- Connector： 连接器，负责连接客户端发起的HTTP connections。
- Handler：处理器，接受处理来自HTTP connections的请求，并对其进行内容响应。
- ThreadPool：线程池，管理和调度多个线程，用来服务与HTTP connections和Handler的运行。
提示：本书中术语使用英文单词，避免读者误解。
其实Connector、Handler、ThreadPool分别对应3个非常简单的接口，并各自拥有多个不同的实现类。
在不同应用场合下，你可以使用选择不同Connector实现类以满足你的需求；如果你不得不使用低版本J2SE，那么你可以指定不同ThreadPool实现类，甚至可以自己实现一个线程池；你可以组合多个不同用途的Handler实现来灵活配置Jetty服务器的功能，比如决定是否支持Servlet，是否启用Servlet的Session功能或者配置Session集群实现，更甚至自己实现Hanlder以满足特定的需求，从而不去理会所谓的Servlet规范，离开Servlet规范利用Jetty我们一样可以实现动态内容的javaWeb服务器，当然这虽然不一定是明智的选择。
由此我们足以看出Jetty的构架是多么的精简，却不妨碍它发挥强大的功能。下面让我们一起逐个看看这3大组件的类关系图。
3.2 Connector
Connector代表什么呢？具体作用是什么？为什么会有不同的实现？等等问题会浮现在你的脑中。目前为止我们只知道从字面意义上它表示“连接器”，负责处理建立和客户端的连接。接下来我们深入了解Jetty中重要的Connector。
首先我们先来看下关于Connector的类图，如图2.2，来大致了解下Connector结构。
在介绍Connector之前我们先探讨下客户端-服务端模型。需要澄清的是这里讨论的模型不仅仅局限在B/S模型（浏览器/服务器），浏览器也只是一个支持HTTP协议的客户端而已。Jetty作为服务器，它的客户端不仅仅是用户的浏览器软件(FireFox、IE等)，还包括服务器反向代理软件(Apache、nginx)等一切和Jetty通信的软件。
不同的软件之间直接通信必然涉及两个问题：一、如何把数据发送给对方？二、数据的格式是什么？
回答第一个问题，需要了解一些基本的网络知识，不过不是本书的重点便不展开说明，请参考其他资料。我们使用TCP/IP协议栈来发送和接受数据。TCP/IP可以保证数据会被正确地在网络上传送到指定的服务器，就好比在客户端和服务器之间建立一个稳定的通道，可以按顺序稳定可靠地传输数据。而我们不必关心数据是如何被转换成电信号，以及如何在不同的路由器之间转发、网络错误等等一系列棘手的问题。在Java里面我们通过Socket编程接口来进行TCP/IP协议。
j2SE 1.4之后引进了NIO模型，之前我们只能使用BIO模型。由于存在这两种截然不同的编程模型，所以在图2.2中我们可以看到Connector基本分为两大类别：以AbstractNIOConnector代表的NIO类和以SocketConnector为代表的BIO类。
目前我们可以得知Connector的实现和数据传输层有关，及建立在Socket编程接口之上。又由于Socket编程接口存在两种不同的编程模型从而分为两大类别。
解决第一个问题还不够，虽然不同的软件之间可以通话了，但是使用的却不是同一种语言，完全是鸡同鸭讲。显然我们还需要指定一种语言，计算机软件管这种语言叫
协议。Jetty作为Web服务器，便实现了HTTP协议，目前实现的版本是
HTTP/1.1。
当Connector接收到一个请求（一般是来自Socket）后，产生一个新的HttpConnection对象，然后由
Server对象调用
Handler来处理HttpConnection对象。HttpConnection类就是解析Http协议的地方，它还提供了附属的Request对象和Response对象，我们在后续章节就可以知道Handler就是通过这两个对象处理输入和输出的。
Connector和Connectioin是紧密相关的，如果一个Connector要识别特定的协议，那么就必须对应一个Connection实现。例如：Ajp13SocketConnector是用来与支持AJP协议的服务器（如apache http）做反向代理连接时使用的，Ajp13Connection是集成自HttpConnectioin类，因为AJP协议是一种对HTTP协议的扩展。
顺便提一下ThreadPool在这里的作用，自Connector接收到一个请求的时刻起，Connector就需要从ThreadPool提取一个线程来处理这个连接，这样才能实现服务器同时处理多个请求。
综上说述，Connector具有众多实现类的原因，主要是由于socket编程模型和不同的协议来决定的。Connector在Jetty中扮演重要的角色，职责是接收来自客户端的请求，根据HTTP协议解析请求的内容，指派一个线程去处理请求并响应结果。
3.3 Handler
在上一节中我们已经提及到了Handler的作用就是处理请求和输出响应。Handler在Jetty里面对应着一个接口，我们来看看这个接口的核心方法：
public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch) throws IOException, ServletException;
参数target是指客户端请求的地址，也就是URI；这里我们发现request和response的类型分别是来自Servlet规范里面的HttpServletRequest和HttpServletResponse接口，那么我们可以得知
HttpConnection引用的Request和Response类分别就是这两个接口的实现了。
handle方法的参数列表和Servlet的service方法非常相似，但是必须澄清的是，虽然handle方法列表中采用了Servlet规范中的HttpServletRequest和HttpServletResponse接口，但是不意味着完全实现了Servlet规范所有的特性。例如：如果没有为Jetty配置ContextHandler处理器，那么request的 getContextPath方法会返回null。所以handle方法只是借用了Servlet规范中这两个接口而已，估计这也是为了更方便的实现Servlet规范做好准备吧。
我们先来预览下Handler的UML类图：
相信初次接触Jetty的朋友看到这么多Handler子类肯定会晕，一下子展出这么多类不是为难大家，掌握好它们也不是难事，只有理清它们才能真正玩转Jetty服务配置和理解Jetty精髓。
Jetty正是利用这些种类繁多的Handler来实现其强大的功能的，你可以任意组合、搭配它们来定制各种强大的功能。
这么多Handler也就分为三类：
1. 内容输出Handler
该类Handler根据target输出内容。如：ResourceHandler、ServletHandler、DefaultHandler等。这些类都是直接对Handler接口进行实现。
2. 装饰模式Handler
该类Handler可以选择在交给另外一个Handler对象调用前或后来处理Request和Response。这些类都继承自HandlerWrapper类，如图2.4中展示的。大家会注意到Server类也是一个装饰模式Handler,其实在Server代理了所有其他的Handler，是所有Handler的入口。HandlerWrapper中的setHandler方法便是用来设定被代理Handler对象的，这个方法在以后大家会经常用到。另外装饰器模式还运行将多个Handler串联起来使用。
3.集合类Handler
该类Handler的作用是讲请求分发给其他Handler处理，分发策略由各自实现类决定。常用集合类Handler有 HandlerCollection、HandlerList、ContextHandlerCollection。
关于各种类型的Handler的作用暂时不做过多深入，后续章节会进行讲解。
3.4 Server 和 ThreadPool
Server代表一个Jerry服务器对象，它的作用就好象一个插线板，把Connector、Handler和ThreadPool集成在一起让它们协同起来工作。
要让Jetty服务器工作起来，我们首先初始化一个Server对象实例，然后给它注册一个或多个Connector对象实例、注册一个ThreadPool对象、注册多个Handler对象并让这些Handler组合起来。OK，这样一个Jetty服务器便组装完成。
让我们重温一个Jetty的一个处理请求的过程吧，首先Connector收到一个请求，Connector根据HTTP/1.1协议将请求包装成为Handler所认识的Request和Response对象，然后用Server提供的ThreadPool对象来分配一个线程去执行Handler调用，注意Server对象算是一个Handler对象，所以从Server开始去交给其他Handler对象处理。
整个过程清晰、简单。而且你还可以任意控制它组装各个环节。之前说过，Jetty为我们提供一堆功能零件，然后简单地组装它们即可。恩，这真是很酷的，Jetty为我们带来的不仅仅是一个服务器软件，而且可以把零件卸载下来重新组装。还记得小时候我们玩变形金刚玩具的那种感觉吧，发挥你的想象力，来自由的玩转Jetty吧。另外，千万别以为Jetty只是个玩具而已哦，它工作起来可是性能强劲，是个真正的擎天柱。
关于ThreadPool，Jetty为我们提供了两个实现版本：org.mortbay.thread.concurrent.ThreadPool和org.mortbay.thread.QueuedThreadPool。当j2se是1.5以上版本是我们选择ThreadPool的实现。ThreadPool存在的目的是因为线程的创建是非常昂贵的操作，所以使用Pool技术以便重复使用以创建的线程。
ThreadPool的大致工作方式是：如果存在一个空闲线程，则让它去执行请求处理。如果不存在且没有达到设定的最大线程数，那么就新建一个Thread去执行请求处理。如果已经达到最大线程数，那么就将工作任务放到队列里面排队，等到有空闲线程时再执行任务。
3.5 目录结构
本节让我们了接下Jetty作为服务器时的目录结构。
目录如下：
jetty-6.1.22
-- bin 存放Windows和linux等系统中使用的Jetty启动脚本和相关文件
-- contexts 存放应用程序发布描述文件，里面有Jetty自带的示例文件
-- distribution 关于发行构建的代码，正式环境可删除
-- etc Jetty配置文件，后续章节会详细介绍
-- examples Jetty示例程序源代码，正式环境可删除
-- extras Jetty相关程序源代码，正式环境可删除
-- javadoc Jetty 核心代码的API文档，正式环境可删除
-- jxr Jetty 其他相关程序API文档，正式环境可删除
-- LICENSES 发行协议说明
-- logs 日志目录
-- modules Jetty相关模块程序源代码，正式环境可删除
-- patches jdk5的补丁文件描述，正式环境可删除
-- project-website maven产生的项目站点文档目录
-- resources 如果存在该目录，jetty启动时会将该目录加入类路径，默认存放log4j配置文件
-- webapps 存放web应用程序，默认情况下该目录下面的文件夹或者war文件将在jetty启动的时候被运行
-- start.jar 启动Jetty引导java程序，可以在各个操作系统中使用它启动jetty服务，后续章节将详细介绍该组件