Jetty介绍

Jetty是一个100%由Java实现的、开源的HTTP服务器和javax.servlet容器，它不仅仅作为一个独立服务软件(如Tomcat) 被使用，而且其 优良的组件（Componet）设计、高内聚低耦合、高扩展性等特性使得Jetty非常易于作为嵌入式工具使用，在这一领域已经成功应用于多个产品当中。
   
    Web2.0时代的来临使得Web服务器不得不去处理更多的请求，而花费更多的时间去处理请求，服务器压力和稳定性必将 受到极大的挑战。Jetty率先为解决这类问题从服务器底层提供了一个名为 Continuations的 机制(?)，来实现异步Servlet功能， 帮助开发者轻松实现Ajax Push功能(?)。另外Jetty提供IO多路复用的连接器(?)实现，使得服务器可以花费较少的资源来并发服务多个请求，也提高Web应用程序在高负载情况下的稳 定性和健壮性，所以Jetty完全胜任企业级应用。如上这些特性都是为在web2.0时代下Web应用程序量身打造，并且Jetty开发团队一直关注这一 方向的进展。

    Jetty不只在作为独立服务器使用时表现优秀，在嵌入式使用或者作为独立工具使用领域也取得了非常优秀成绩。目前已被广泛应用在多个项目和产品中。由 于Jetty构架优秀、实现优雅，所以 它被广泛嵌入的到移动设备、工具、框架(frameworks)、应用程序服务器(Application Server)等等领域。使用jetty服务的各领域代表如下：

• 大型集群系统，如Yahoo Hadoop Cluster（http://developer.yahoo.net/hadoop/）
• 云计算服务，如Google AppEngine （http://code.google.com/appengine/）
• SaaS系统，如Yahoo! Zimbra（http://www.zimbra.com/）
• 应用程序服务器，如Apache Geronimo(http://geronimo.apache.org/)
• 应用框架，如GWT(http://code.google.com/webtoolkit/)
• 工具，如 Eclipse IDE(http://www.eclipse.org/) ， 
• 移动设备，i-jetty(http://code.google.com/p/i-jetty/)在手机设备运行web应用
• 其他请访问http://docs.codehaus.org/display/JETTY/Jetty+Powered查看

    Jetty可是标准化的拥护者，它支持HTTP1.1，很好的实现了Servlet2.4/2.5、Jsp2.0/2.1规范和JEE部分规范。就是说 服务JEE web容器标准的应该程序在Jetty下会被很好地执行。另外在Servlet 3.0规范的定制过程当中Jetty也起着积极的作用和贡献，将来在Servlet3.0的实现上也会成为佼佼者之一。

    Jetty的构架非常优秀，高组件化设计，Jetty给我们提供各种可用的零件和组装这些零件的工具，使得Jetty在服务器配置时积极灵活，而且在我 们把Jetty作为工具使用时也非常便捷。打个比方，Jetty就是真实版本变形金刚，不仅性能强劲可以打败敌人 完成保卫地球的任务 ，而且你可以重新组装各个零部件把它变成一个部高级跑车，如果你还觉得它不够酷的话还可以自己打造部分零件定制自己特有的版本。呵呵，很酷吧，对！ 这些都将不是梦想，你的很多想法Jetty都可以为你实现。    
   
    如上所描写的强大功能，那么Jetty的开源协议是什么 ？会不会有商业限制呢 ？这些都不必担心。 要知道Jetty是基于Apache Licence 2.0  和 Eclipse Public License 1.0 开源协议发布的，因此你可以在任意地方使用它，并可以免费地 用于商业行为。
   
    目前稳定版是jetty6系列，本书的使用的版本是Jetty6.1.22。

名词注解：
1 Continuations的 机制
利用 Continuation 机制，Jetty 可以使得一个线程能够用来同时处理多个从客户端发送过来的异步请求 http://blog.csdn.net/kobejayandy/article/details/17885505
讨论 Jetty 的 Continuation 机制，首先需要提到 Ajax 技术，Ajax 技术是当前开发 Web 应用的非常热门的技术，也是 Web 2.0 的一个重要的组成部分。Ajax 技术中的一个核心对象是 XMLHttpRequest 对象，这个对象支持异步请求，所谓异步请求即是指当客户端发送一个请求到服务器的时候，客户端不必一直等待服务器的响应。这样就不会造成整个页面的刷新，给用户带来更好的体验。而当服务器端响应返回时，客户端利用一个 Javascript 函数对返回值进行处理，以更新页面上的部分元素的值。但很多时候这种异步事件只是在很小一部分的情况下才会发生，那么怎么保证一旦服务器端有了响应之后客户端马上就知道呢，我们有两种方法来解决这个问题，一是让浏览器每隔几秒请求服务器来获得更改，我们称之为轮询。二是服务器维持与浏览器的长时间的连接来传递数据，长连接的技术称之为Comet。

大家很容易就能发现轮询方式的主要缺点是产生了大量的传输浪费。因为可能大部分向服务器的请求是无效的，也就是说客户端等待发生的事件没有发生，如果有大量的客户端的话，那么这种网络传输的浪费是非常厉害的。特别是对于服务器端很久才更新的应用程序来讲，比如邮件程序，这种浪费就更是巨大了。并且对 Server 端处理请求的能力也相应提高了要求。如果很长时间才向 Server 端发送一次请求的话，那么客户端就不能的得到及时的响应。

如果使用 Comet 技术的话，客户端和服务器端必须保持一个长连接，一般情况下，服务器端每一个 Servlet 都会独占一个线程，这样就会使得服务器端有很多线程同时存在，这在客户端非常多的情况下也会对服务器端的处理能力带来很大的挑战。

Jetty 利用 Java 语言的非堵塞 I/O 技术来处理并发的大量连接。 Jetty 有一个处理长连接的机制：一个被称为 Continuations 的特性。利用 Continuation 机制，Jetty 可以使得一个线程能够用来同时处理多个从客户端发送过来的异步请求，下面我们通过一个简化的聊天程序的服务器端的代码来演示不使用 Continuation 机制和使用 Continuation 的差别。
public class ChatContinuation extends HttpServlet{
   
    public void doPost(HttpServletRequest request, HttpServletResponse response){
        postMessage(request, response);
    }
   
    private void postMessage(HttpServletRequest request, HttpServletResponse response)
    {
        HttpSession session = request.getSession(true);
        People people = (People)session.getAttribute(session.getId());
        if (!people.hasEvent())
        {
            Continuation continuation =
                ContinuationSupport.getContinuation(request, this);
            people.setContinuation(continuation);
            continuation.suspend(1000);
        }
        people.setContinuation(null);
        people.sendEvent(response);
    }
}
大家注意到，首先获取一个 Continuation 对象，然后把它挂起 1 秒钟，直到超时或者中间被 resume 函数唤醒位置，这里需要解释的是，在调用完suspend 函数之后，这个线程就可处理其他的请求了，这也就大大提高了程序的并发性，使得长连接能够获得非常好的扩展性。

如果我们不使用 Continuation 机制，那么程序就如 清单 3 所示：
public class Chat extends HttpServlet{
    public void doPost(HttpServletRequest request, HttpServletResponse response){
        postMessage(request, response);
    }
   
    private void postMessage(HttpServletRequest request, HttpServletResponse response)
    {
        HttpSession session = request.getSession(true);

        People people = (People)session.getAttribute(session.getId());

        while (!people.hasEvent())
        {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        people.setContinuation(null);
        people.sendEvent(response);   
    }
}
大家注意到在等待事件发生的时间里，线程被挂起，直到所等待的事件发生为止，但在等待过程中，这个线程不能处理其他请求，这也就造成了在客户端非常多的情况下服务器的处理能力跟不上的情况。下面我们解释一下 Jetty 的 Continuation 的机制是如何工作的。

为了使用 Continuatins，Jetty 必须配置为使用它的 SelectChannelConnector 处理请求。这个 connector 构建在 java.nio API 之上，允许它维持每个连接开放而不用消耗一个线程。当使用SelectChannelConnector 时，ContinuationSupport.getContinuation() 提供一个SelectChannelConnector.RetryContinuation 实例（但是，您必须针对 Continuation 接口编程）。当在RetryContinuation 上调用suspend() 时，它抛出一个特殊的运行时异常 -- RetryRequest，该异常传播到 servlet 外并且回溯到 filter 链，最后被SelectChannelConnector 捕获。但是不会发送一个异常响应给客户端，而是将请求维持在未决 Continuations 队列里，则 HTTP 连接保持开放。这样，用来服务请求的线程返回给 ThreadPool，然后又可以用来服务其他请求。暂停的请求停留在未决 Continuations 队列里直到指定的过期时间，或者在它的 Continuation 上调用resume() 方法。当任何一个条件触发时，请求会重新提交给 servlet（通过 filter 链）。这样，整个请求被"重播"直到 RetryRequest 异常不再抛出，然后继续按正常情况执行。
2、Ajax Push功能：被动的拉式通知技术又称Pull方式，主动的推式通知技术又称push方式
拉方式需要客户机不定时的检查服务器已获知是否发生新的事件或数据是否有变化，这种方式并不实时，但在web上比较容易实现。推式客户机与服务只需建立好连接之后，每当服务器有特殊事件发生时才通知客户机，该方式实时性非常强，但目前在Web上实现较为复杂。
这两种方式后者有非常显著的优点，而Ajax push就是需要在web上实现的后者的通信技术，如果Ajax push能被的完美实现，那么基于web的IM软件、基于Web的关键业务报警系统、基于web的实时监控系统、更智能人性的Web信息系统、甚至是基于web的远程控制系统、等等都将可以实现，同时彻底摆脱客户端部署与安装，避免服务端的高负载。而webMsn、GMAIL这些系统中的很多被我们认为是不可思议的特性也能被任何一个web程序员轻松的开发出来。这是多么美好的时刻，更加值得我们去期待。
http://blog.csdn.net/caichunmao/article/details/1764912
I/O多路复用：
I/O复用的典型应用场合：
1、当客户处理多个描述字（通常是交互式输入和网络套接口）时，必须使用I/O复用。
2、如果一个服务器要处理多个服务或者多个协议（例如既要处理TCP，又要处理UDP），一般就要使用I/O复用。http://blog.csdn.net/segments/article/details/6894189

五种I/O模型

1、阻塞I/O模型

     最流行的I/O模型是阻塞I/O模型，缺省情形下，所有套接口都是阻塞的。我们以数据报套接口为例来讲解此模型（我们使用UDP而不是TCP作为例子的原因在于就UDP而言，数据准备好读取的概念比较简单：要么整个数据报已经收到，要么还没有。然而对于TCP来说，诸如套接口低潮标记等额外变量开始活动，导致这个概念变得复杂）。

     进程调用recvfrom，其系统调用直到数据报到达且被拷贝到应用进程的缓冲区中或者发生错误才返回，期间一直在等待。我们就说进程在从调用recvfrom开始到它返回的整段时间内是被阻塞的。

2、非阻塞I/O模型

      进程把一个套接口设置成非阻塞是在通知内核：当所请求的I/O操作非得把本进程投入睡眠才能完成时，不要把本进程投入睡眠，而是返回一个错误。也就是说当数据没有到达时并不等待，而是以一个错误返回。

3、I/O复用模型

     调用select或poll，在这两个系统调用中的某一个上阻塞，而不是阻塞于真正I/O系统调用。 阻塞于select调用，等待数据报套接口可读。当select返回套接口可读条件时，调用recevfrom将数据报拷贝到应用缓冲区中。

4、信号驱动I/O模型

     首先开启套接口信号驱动I/O功能,并通过系统调用sigaction安装一个信号处理函数（此系统调用立即返回，进程继续工作，它是非阻塞的）。当数据报准备好被读时，就为该进程生成一个SIGIO信号。随即可以在信号处理程序中调用recvfrom来读数据报，井通知主循环数据已准备好被处理中。也可以通知主循环，让它来读数据报。

5、异步I/O模型

     告知内核启动某个操作，并让内核在整个操作完成后(包括将数据从内核拷贝到用户自己的缓冲区)通知我们。这种模型与信号驱动模型的主要区别是：
           信号驱动I/O：由内核通知我们何时可以启动一个I/O操作，
           异步I/O模型：由内核通知我们I/O操作何时完成。