主页:
http://jetty.codehaus.org/jetty/
参考自:
http://www.cnblogs.com/lexus/archive/2011/08/23/2150191.html
http://www.cnblogs.com/yangchao/archive/2011/03/26/2044393.html
http://www.ibm.com/developerworks/cn/web/wa-lo-jetty/
一 Jetty是什么?
Jetty是一个用Java实现的开源的Http和Web服务器,包括HTTP server, HTTP client和javax.servlet container。类似于tomcat,websphere,glassfish,jboss等。
二 Jetty用在何处?
Jetty的应用非常广泛,包括:
大型集群系统,如Yahoo Hadoop Cluster( http://developer.yahoo.net/hadoop/)
云计算服务,如Google AppEngine ( http://code.google.com/appengine/)
SaaS(Software-as-a-service)系统,如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/)
三 Jetty的特性是什么?
Jetty的广泛应用得益于其诸多优秀的特性:
轻量级:Jetty体积小巧,占用系统资源较少。
易嵌入性:Jetty既可以像tomcat一样独立运行,也可以很方便的嵌入到工具、框架或其他应用服务器中运行。Jetty在设计之 初就是作为一个可以嵌入到其他的Java代码中的servlet容器而设计的,因此开发小组将Jetty作为一组Jar文件提供出来,可以非常方便的在自己的容器中将Jetty实例化成一个对象并操纵该容器对象。
灵活性:Jetty的体系架构及其面向接口的设计实现了功能模块高度可插拔和可扩展的特性,可以非常方便的根据需要来配置Jetty启用的功能。
稳定性:Jetty运行速度较快,即使有大量服务请求并发的情况下,系统性能也能保持在一个可以接受的状态。
四 Jetty的体系架构
![](https://i-blog.csdnimg.cn/blog_migrate/22e3e32ce8433dbb1ce7c43107521a46.gif)
下面分别对上图中的几个部分作简要介绍:
Connector负责解析服务器请求并产生应答,不同的Connector用于处理不同协议的请求。
Handler用于处理经过Connector解析的请求并产生应答内容,同样可以通过配置不同的Handler来负责处理不同的请求。
TheadPool:管理和调度多个线程,用于服务于多个连接请求。
Server代表一个Jetty服务器对象,主要作用是协同Connector、Handler和TheadPool的工作。
其中,!TheadPool可以根据配置选择是否使用,Connector和Handler也可以通过配置非常方便的实现替换。
五 Continuation机制
Continuation机制是Jetty用于更好的支持异步Servlet的机制。
首先简要介绍一下技术应用的背景。异步请求是指当客户端发送一个请求到服务器的时候,客户端不必一直等待服务器的响应,例如Web 2.0中的Ajax(Asynchronous JavaScript and XML)技术、JDBC连接池等,当服务器端响应返回时,客户端利用一个 Javascript 函数对返回值进行处理,以更新页面上的部分元素的值而不必刷新整个页面,从而带来更好的客户体验。但很多时候这种异步事件只是在很小一部分的情况下才会发 生,那么怎么保证一旦服务器端有了响应之后客户端马上就知道呢,我们有两种方法来解决这个问题,一是让浏览器每隔几秒请求服务器来获得更改,称之为轮询。 二是服务器维持与浏览器的长时间的连接来传递数据,长连接的技术称之为Comet。轮询的主要缺点是产生了大量的传输浪费;而如果使用Comet技术的话,客户端和服务器端之间必须保持一个长连接,一般来讲,服务器端的一个Servlet会独占一个线程,如果有大量客户端维持长连接,会给服务器端的处理 能力带来很大的挑战。
针对上述情况,Jetty利用Java语言的非堵塞I/O技术来处理并发的大量连接。具体说来,Jetty实现了一个基于java.nio API 的SelectChannelConnector,允许它维持每个连接开放而不用消耗一个线程。当连接挂起时,Connector将请求维持在未决 Continuations队列里,用来服务请求的线程返回给TheadPool,这样,该线程又可以服务于其他请求。暂停的请求停留在未决 Continuations 队列里直到指定的过期时间,或者在它的Continuation上调用resume()方法。
六 Jetty Vs Tomcat
Tomcat作为第一款成功的web容器,具有广大的用户群体。从表面功能上Jetty和Tomcat都是差不多的,都提供Http Server和Servlet容器功能,下面我们从几个方面比较两者的差异:
从构架方面
Tomcat主要是作为JSP/Servlet最新规范的参考实现而设计,属于学院派,但是显得庞大而杂乱。最常见的Tomcat使用方式是将其作为一个服务器软件安装到操作系统上,然后在里面部署web应用,如果嵌入到其他JEE服务器中以提供Web容器功能或者作为组件嵌入到其他应用中,操作起来比较麻烦。
Jetty是由多个可以独立运行的构件通过彼此之间可插拔的接口组装在一起,其使用可以非常灵活。目前,Jetty在Geronimo、JBoss、Sybase EAServer、JOnAS和Glassfish等JEE应用服务器中提供Web容器功能。
从性能方面
Tomcat在耗时请求连接数量不多时,也就是大多数请求能非常短的时间处理完毕的情况下,具有较好的执行效率。
Jetty 在存在大量并发连接,大多数连接又需要更多的处理时间(业务逻辑计算占用的时间)的情况下(这种情况是目前大多数web应用具有的特点),具有更好的性能 和伸缩性。Jetty的这个优势得益于Continuation机制,这样可以把有限的内存资源更多的留给应用程序使用。在静态文件服务方面,Jetty 也具有更好的性能。这是由于Jetty使用了文件内存映射机制和NIO来对静态内容进行输入输出,这种方式将占用更少的系统内存和更快发送速度。
从标准规范方面
Tomcat曾是sevlet2.4规范的参考实现,从Servlet2.5之后,Tomcat不再是参考实现了,Sun公司自己创建了Glassfish,并作为Servlet2.5、Servlet3.0、Jsp2.1的参考实现。
Jetty在执行规范方面做的非常好,是Servlet2.5规范的一个优秀实现。在Servlet3.0中,Jetty自有的continuation机制也成为规范备选方案之一。
完!