web请求：servlet处理请求

https://www.cnblogs.com/jerrice/p/6724060.html

 

1 WEB服务器

|- Web Server
        |- Http Server
        |- Application Server
            |- Servlet Container
            |- CGI Server
            |- ......

1.1 Http Server

运行在服务器之上，绑定服务器的IP地址并监听某一个tcp端口来接收并处理HTTP请求，浏览器就能够通过HTTP协议来获取服务器上的网页（HTML格式）、文档（PDF格式）、音频（MP4格式）、视频（MOV格式）等等资源。一个HTTP Server关心的是HTTP协议层面的传输和访问控制。

1. 客户端通过HTTP Server访问服务器上存储的静态资源（HTML文件、图片文件等等）。
2. 通过CGI/Servlet技术，也可以将处理过的动态内容通过HTTP Server分发，但是一个HTTP Server始终只是把服务器上的文件如实的通过HTTP协议传输给客户端。

HTTP Server中经常使用的是Apache、Nginx两种，HTTP Server主要用来做静态内容服务、代理服务器、负载均衡等。直面外来请求转发给后面的应用服务（Tomcat，django什么的）。

|- Http Server
    |- Apache
    |- Nginx

1.1.1 Apache HTTP服务器

Apache支持模块多，性能稳定，Apache本身是静态解析，适合静态HTML、图片等，但可以通过扩展脚本、模块等支持动态页面等。

对Java，需要Tomcat在Apache后台支撑，将Java请求由Apache转发给Tomcat处理。

1.1.2 Nginx HTTP服务器

Nginx是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP代理服务器。

其特点是占有内存少，并发能力强。Nginx代码完全用C语言从头写成。

具有很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速连接时，也很可能会导致服务器物理内存耗尽频繁交换，失去响应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显非常缓慢了。

而Nginx采取了分阶段资源分配技术，使得它的CPU与内存占用率非常低。Nginx官方表示保持10000个没有活动的连接，它只占2.5M内存，所以类似DOS这样的攻击对nginx来说基本上是毫无用处的。就稳定性而言，Nginx比Lighthttpd更胜一筹。

1.1.3 Nginx与Apache比较

Nginx相对于Apache的优点：

1. 轻量级，同样启动WEB服务，比Apache占用更少的内存以及资源；
2. 抗并发性能高，核心区别在于Apache是同步多进程模型，一个连接对应一个进程。Nginx是异步的，多个连接（万级别）可以对应一个进程；
3. Nginx模块较少，配置简单，所以Nginx可以将资源用在数据处理以及进程上面，Apache模块较多比较全，相对稳定，但在内存资源上消耗比较大；
4. Nginx可以在不间断的情况下进行软件版本的升级；
5. Nginx处理静态页面性能比apache高3倍多；

选择高并发高性能就选择Nginx，如果要稳定，选择Apache，主要根据服务器要面临的需求而定。

当然，两者也可以组合使用：

1. Nginx放前端+apache放后端+MYSQL+PHP：可以提高服务器负载能力
2. Nginx处理静态页面请求如MP3，GIF.JPG.JS，apache处理动态页面请求，充分结合了二者的优势；

1.2 Application Server

与HTTP Server相比，Application Server能够动态的生成资源并返回到客户端。

|- Application Server
    |- Tomcat
    |- Jetty

Servlet Container:为了支持Servlet。Web服务器软件处理一般请求，并把Servlet调用传递给“容器”来处理。

HTTP Server 与 Application Server

Tomcat运行在JVM之上，它和HTTP服务器一样，绑定IP地址并监听TCP端口，同时还包含以下指责：

1. 管理Servlet程序的生命周期；
2. 将URL映射到指定的Servlet进行处理；
3. 与Servlet程序合作处理HTTP请求——根据HTTP请求生成HttpServletRequest/Response对象并传递给Servlet进行处理，将Servlet中的HttpServletResponse对象生成的内容返回给浏览器

1.2.1 Servlet容器工作模式

按照工作模式的不同，Servlet容器可以分为以下3类：

1. 独立运行的Servlet容器

   在这种模式下，Servlet容器作为构成Web服务器的一部分而存在。当使用基于Java的Web服务器时，就属于这种情况。这种方式是Tomcat的默认模式，然而大多数Web服务器并不是基于Java的，所以就产生了下面的两种其他类型。

2. 内置的Servlet容器

   Servlet容器由Web服务器插件和Java容器两部分组成。采用这种方式时，Web服务器插件需要在某个Web服务器内部地址空间中打开一个JVM（Java虚拟机），在此JVM上加载Java容器并运行Servlet。如果客户端调用Servlet，Web服务器插件首先获得此请求的控制并将它传递（使用JNI技术）给Java容器，然后Java容器把此请求交给Servlet来处理。这种方式运行速度较快，并且能够提供良好的性能，适用于单进程、多线程服务器，但是在伸缩性方面存在不足。

3. 外置的Servlet容器

   采用这种方式时，Servlet容器运行在Web服务器外部地址空间。先由Web服务器插件在某个Web服务器外部地址空间打开一个JVM（Java虚拟机），然后加载Java容器来运行Servlet。Web服务器插件和JVM之间使用IPC（进程间通信）机制（通常是TCP/IPSockets）。如果客户端调用Servlet，Web服务器插件首先获得此请求的控制并将它传递（使用IPC技术）给Java容器，然后Java容器把此请求交给Servlet来处理。这种方式对客户端请求的处理速度不如内置Servlet那样快，但是在其他方面（如可伸缩性、稳定性等）具有优势。

Tomcat属于Servlet容器，其工作模式也分为上述3种，所以Tomcat既可被用作独立运行的Servlet引擎（便于开发和调试），又可作为一个需要增强功能的Web服务器（如当前的Apache、IIS和Netscape服务器）插件。在配置Tomcat之前，就需要确定采用哪种工作模式，工作模式（1）比较简单，直接安装Tomcat即可，工作模式（2）和（3）有些复杂，除了安装Tomcat、Web服务器之外，还需要安装连接两者的中间连接件。

1.2.2 Apache与Tomcat整合使用

虽然Tomcat也可以认为是HTTP服务器，但通常它仍然会和Apache/Nginx配合在一起使用：

1. 动静态资源分离——运用Nginx的反向代理功能分发请求：所有动态资源的请求交给Tomcat，而静态资源的请求（例如图片、视频、CSS、JavaScript文件等）则直接由Nginx返回到浏览器，这样能大大减轻Tomcat的压力；

2. 负载均衡——当业务压力增大时，可能一个Tomcat的实例不足以处理，那么这时可以启动多个Tomcat实例进行水平扩展，而Nginx的负载均衡功能可以把请求通过算法分发到各个不同的实例进行处理；

整合的好处：

1. 1. 如果客户端请求的是静态页面，则只需要Apache服务器响应请求。
   2. 如果客户端请求动态页面，则是Tomcat服务器响应请求。
   3. 因为JSP是服务器端解释代码的，这样整合就可以减少Tomcat的服务开销。

 

 

7 什么是Servlet

Servlet对每个请求都是单独启动一个线程，而不是进程。降低系统里的进程数量，提高系统的并发处理能力。另外因为Java Servlet是运行在虚拟机之上的，也就解决了跨平台问题。

7.1 Servlet生命周期

作为一名专业编程人员，您碰到的大多数 Java servlet 都是为响应 Web 应用程序上下文中的 HTTP 请求而设计的。因此，javax.servlet 和 javax.servlet.http 包中特定于 HTTP 的类是您应该关心的。对于Servlet容器(Tomcat)与HttpServlet是怎样进行交互的呢，看下类图：

Java Servlet 类图

Servlet的框架是由两个Java包组成的：javax.servlet与javax.servlet.http。在javax.servlet包中定义了所有的Servlet类都必须实现或者扩展的通用接口和类。在javax.servlet.http包中定义了采用Http协议通信的HttpServlet类。Servlet的框架的核心是javax.servlet.Servlet接口，所有的Servlet都必须实现这个接口。在Servlet接口中定义了5个方法，其中3个方法代表了Servlet的生命周期：

1. init(ServletConfig)方法：负责初始化Servlet对象，在Servlet的生命周期中，该方法执行一次；该方法执行在单线程的环境下，因此开发者不用考虑线程安全的问题；
2. service(ServletRequest req,ServletResponse res)方法：负责响应客户的请求；为了提高效率，Servlet规范要求一个Servlet实例必须能够同时服务于多个客户端请求，即service()方法运行在多线程的环境下，Servlet开发者必须保证该方法的线程安全性；
3. destroy()方法：当Servlet对象退出生命周期时，负责释放占用的资源；

编程注意事项说明：

1. 当Server Thread线程执行Servlet实例的init()方法时，所有的Client Service Thread线程都不能执行该实例的service()方法，更没有线程能够执行该实例的destroy()方法，因此Servlet的init()方法是工作在单线程的环境下，开发者不必考虑任何线程安全的问题。
2. 当服务器接收到来自客户端的多个请求时，服务器会在单独的Client Service Thread线程中执行Servlet实例的service()方法服务于每个客户端。此时会有多个线程同时执行同一个Servlet实例的service()方法，因此必须考虑线程安全的问题。
3. 请大家注意，虽然service()方法运行在多线程的环境下，并不一定要同步该方法。而是要看这个方法在执行过程中访问的资源类型及对资源的访问方式。分析如下：

   如果service()方法没有访问Servlet的成员变量也没有访问全局的资源比如静态变量、文件、数据库连接等，而是只使用了当前线程自己的资源，比如非指向全局资源的临时变量、request和response对象等。该方法本身就是线程安全的，不必进行任何的同步控制。

   如果service()方法访问了Servlet的成员变量，但是对该变量的操作是只读操作，该方法本身就是线程安全的，不必进行任何的同步控制。

   如果service()方法访问了Servlet的成员变量，并且对该变量的操作既有读又有写，通常需要加上同步控制语句。

   如果service()方法访问了全局的静态变量，如果同一时刻系统中也可能有其它线程访问该静态变量，如果既有读也有写的操作，通常需要加上同步控制语句。

   如果service()方法访问了全局的资源，比如文件、数据库连接等，通常需要加上同步控制语句。

在创建一个 Java servlet 时，一般需要子类 HttpServlet。该类中的方法允许您访问请求和响应包装器（wrapper），您可以用这个包装器来处理请求和创建响应。大多数程序员都知道Servlet的生命周期，简单的概括这就分为四步：

Servlet类加载--->实例化--->服务--->销毁；

Servlet生命周期

创建Servlet对象的时机：

1. 默认情况下，在Servlet容器启动后：客户首次向Servlet发出请求，Servlet容器会判断内存中是否存在指定的Servlet对象，如果没有则创建它，然后根据客户的请求创建HttpRequest、HttpResponse对象，从而调用Servlet对象的service方法；
2. Servlet容器启动时：当web.xml文件中如果<servlet>元素中指定了<load-on-startup>子元素时，Servlet容器在启动web服务器时，将按照顺序创建并初始化Servlet对象；
3. Servlet的类文件被更新后，重新创建Servlet。Servlet容器在启动时自动创建Servlet，这是由在web.xml文件中为Servlet设置的<load-on-startup>属性决定的。从中我们也能看到同一个类型的Servlet对象在Servlet容器中以单例的形式存在；

注意：在web.xml文件中，某些Servlet只有<serlvet>元素，没有<servlet-mapping>元素，这样我们无法通过url的方式访问这些Servlet，这种Servlet通常会在<servlet>元素中配置一个<load-on-startup>子元素，让容器在启动的时候自动加载这些Servlet并调用init(ServletConfig config)方法来初始化该Servlet。其中方法参数config中包含了Servlet的配置信息，比如初始化参数，该对象由服务器创建。

销毁Servlet对象的时机：

Servlet容器停止或者重新启动：Servlet容器调用Servlet对象的destroy方法来释放资源。以上所讲的就是Servlet对象的生命周期。那么Servlet容器如何知道创建哪一个Servlet对象？Servlet对象如何配置？实际上这些信息是通过读取web.xml配置文件来实现的。

<servlet>
    <!-- Servlet对象的名称 -->
    <servlet-name>action<servlet-name>
    <!-- 创建Servlet对象所要调用的类 -->
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
        <!-- 参数名称 -->
        <param-name>config</param-name>
        <!-- 参数值 -->
        <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <init-param>
        <param-name>detail</param-name>
        <param-value>2</param-value>
    </init-param>
    <init-param>
        <param-name>debug</param-name>
        <param-value>2</param-value>
    </init-param>
    <!-- Servlet容器启动时加载Servlet对象的顺序 -->
    <load-on-startup>2</load-on-startup>
</servlet>
<!-- 要与servlet中的servlet-name配置节内容对应 -->
<servlet-mapping>
    <servlet-name>action</servlet-name>
    <!-- 客户访问的Servlet的相对URL路径 -->
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

当Servlet容器启动的时候读取<servlet>配置节信息，根据<servlet-class>配置节信息创建Servlet对象，同时根据<init-param>配置节信息创建HttpServletConfig对象，然后执行Servlet对象的init方法，并且根据<load-on-startup>配置节信息来决定创建Servlet对象的顺序，如果此配置节信息为负数或者没有配置，那么在Servlet容器启动时，将不加载此Servlet对象。当客户访问Servlet容器时，Servlet容器根据客户访问的URL地址，通过<servlet-mapping>配置节中的<url-pattern>配置节信息找到指定的Servlet对象，并调用此Servlet对象的service方法。

在整个Servlet的生命周期过程中，创建Servlet实例、调用实例的init()和destroy()方法都只进行一次，当初始化完成后，Servlet容器会将该实例保存在内存中，通过调用它的service()方法，为接收到的请求服务。下面给出Servlet整个生命周期过程的UML序列图，如图所示：

Servlet生命周期UML序列图

如果需要让Servlet容器在启动时即加载Servlet，可以在web.xml文件中配置<load-on-startup>元素。

7.2 Servlet工作原理

上面描述了Servlet的生命周期，接着我们描述一下Tomcat与Servlet是如何工作的，首先看下面的时序图：

Servlet工作原理时序图

1. Web Client 向Servlet容器（Tomcat）发出Http请求；
2. Servlet容器接收Web Client的请求；
3. Servlet容器创建一个HttpRequest对象，将Web Client请求的信息封装到这个对象中；
4. Servlet容器创建一个HttpResponse对象；
5. Servlet容器调用HttpServlet对象的service方法，把HttpRequest对象与HttpResponse对象作为参数传给 HttpServlet对象；
6. HttpServlet调用HttpRequest对象的有关方法，获取Http请求信息；
7. HttpServlet调用HttpResponse对象的有关方法，生成响应数据；
8. Servlet容器把HttpServlet的响应结果传给Web Client；

8 Tomcat工作原理

Tomcat 的结构很复杂，但是 Tomcat 也非常的模块化，找到了 Tomcat 最核心的模块，您就抓住了 Tomcat 的“七寸”。下面是 Tomcat 的总体结构图：

Tomcat的总体结构图

从上图可以看出Tomcat的核心是两个组件：连接器（Connector）和容器（Container）。Connector组件是负责生成请求对象和响应对象的，Tomcat默认的是HttpConnector，负责根据收到的Http请求报文生成Request对象和Response对象，并把这两个对象传递给Container，然后根据Response中的内容生成相应的HTTP报文。

Container是容器的父接口，所有子容器都必须实现这个接口，简单来说就是服务器部署的项目是运行在Container中的。Container里面的项目获取到Connector传递过来对应的的Request对象和Response对象进行相应的操作。

Connector可以根据不同的设计和应用场景进行替换。一个Container可以选择对应多个Connector。多个Connector和一个Container就形成了一个Service，有了Service就可以对外提供服务了。

Tomcat要为一个Servlet的请求提供服务，需要做三件事：

1. 创建一个request对象并填充那些有可能被所引用的Servlet使用的信息，如参数，头部、cookies、查询字符串等。一个request对象就是javax.servlet.ServletRequest或javax.servlet.http.ServletRequest接口的一个实例。
2. 创建一个response对象，所引用的servlet使用它来给客户端发送响应。一个response对象是javax.servlet.ServletResponse或javax.servlet.http.ServletResponse接口的一个实例。
3. 调用servlet的service方法，并传入request和response对象。这里servlet会从request对象取值，给response写值。
4. 根据servlet返回的response生成相应的HTTP响应报文。

既然我们已经抓到Tomcat的“七寸”，两个核心组件：连接器（Connector）和容器（Container），那这样从连接器（Connector）入手，来看下Tomcat处理HTTP请求的流程。

很多开源应用服务器都是集成tomcat作为web container的，而且对于tomcat的servlet container这部分代码很少改动。这样，这些应用服务器的性能基本上就取决于Tomcat处理HTTP请求的connector模块的性能。

8.1 Connector种类

Tomcat源码中与connector相关的类位于org.apache.coyote包中，Connector分为以下几类：

Http Connector，基于HTTP协议，负责建立HTTP连接。它又分为BIO Http Connector与NIO Http Connector两种，后者提供非阻塞IO与长连接Comet支持。

AJP Connector，基于AJP协议，AJP是专门设计用来为tomcat与http服务器之间通信专门定制的协议，能提供较高的通信速度和效率。如与Apache服务器集成时，采用这个协议。

APR HTTP Connector，用C实现，通过JNI调用的。主要提升对静态资源（如HTML、图片、CSS、JS等）的访问性能。现在这个库已独立出来可用在任何项目中。Tomcat在配置APR之后性能非常强劲。

8.2 Connector配置

对Connector的配置位于conf/server.xml文件中。

8.2.1 BIO HTTP/1.1 Connector配置

<Connector port=”8080” protocol=”HTTP/1.1” maxThreads=”150” 
    connectionTimeout=”20000” redirectPort=”8443” />

其它一些重要属性如下：

acceptCount : 接受连接request的最大连接数目，默认值是10；

address : 绑定IP地址，如果不绑定，默认将绑定任何IP地址；

allowTrace : 如果是true,将允许TRACE HTTP方法；

compressibleMimeTypes : 各个mimeType, 以逗号分隔，如text/html,text/xml；

compression : 如果带宽有限的话，可以用GZIP压缩；

connectionTimeout : 超时时间，默认为60000ms (60s)；

maxKeepAliveRequest : 默认值是100；

maxThreads : 处理请求的Connector的线程数目，默认值为200；

如果是SSL配置，如下：

<Connector port="8181" protocol="HTTP/1.1" SSLEnabled="true" 
    maxThreads="150" scheme="https" secure="true" 
    clientAuth="false" sslProtocol = "TLS" 
    address="0.0.0.0" 
    keystoreFile="E:/java/jonas-full-5.1.0-RC3/conf/keystore.jks" 
    keystorePass="changeit" />

其中，keystoreFile为证书位置，keystorePass为证书密码。

8.2.2 NIO HTTP/1.1 Connector配置

<Connector port=”8080” protocol=”org.apache.coyote.http11.Http11NioProtocol” 
    maxThreads=”150” connectionTimeout=”20000” redirectPort=”8443” />

8.2.3 Native APR Connector配置

1. ARP是用C/C++写的，对静态资源（HTML，图片等）进行了优化。所以要下载本地库tcnative-1.dll与openssl.exe，将其放在%tomcat%\bin目录下。

   下载地址是：http://tomcat.heanet.ie/native/1.1.10/binaries/win32/

2. 在server.xml中要配置一个Listener,如下图。这个配置tomcat是默认配好的。

   <!--APR library loader. Documentation at /docs/apr.html --> 
   <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />

3. 配置使用APR connector

   <Connector port=”8080” protocol=”org.apache.coyote.http11.Http11AprProtocol” 
     maxThreads=”150” connectionTimeout=”20000” redirectPort=”8443” />

4. 如果配置成功，启动tomcat,会看到如下信息：

   org.apache.coyote.http11.Http11AprProtocol init

8.3 Tomcat架构模块

Tomcat架构模块

1. Server(服务器)是Tomcat构成的*构成元素，所有一切均包含在Server中，Server的实现类StandardServer可以包含一个到多个Services;
2. 次*元素Service的实现类为StandardService调用了容器(Container)接口，其实是调用了Servlet Engine(引擎)，而且StandardService类中也指明了该Service归属的Server；
3. 接下来次级的构成元素就是容器(Container)：主机(Host)、上下文(Context)和引擎(Engine)均继承自Container接口，所以它们都是容器。但是，它们是有父子关系的，在主机(Host)、上下文(Context)和引擎(Engine)这三类容器中，引擎是*容器，直接包含是主机容器，而主机容器又包含上下文容器，所以引擎、主机和上下文从大小上来说又构成父子关系，虽然它们都继承自Container接口。
4. 连接器(Connector)将Service和Container连接起来，首先它需要注册到一个Service，它的作用就是把来自客户端的请求转发到Container(容器)，这就是它为什么称作连接器的原因。

8.4 Tomcat运行流程

Tomcat运行流程

假设来自客户的请求为：http://localhost:8080/test/index.jsp

1. 1. 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得；
   2. Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应；
   3. Engine获得请求localhost:8080/test/index.jsp，匹配它所有虚拟主机Host；
   4. Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）；
   5. localhost Host获得请求/test/index.jsp，匹配它所拥有的所有Context；
   6. Host匹配到路径为/test的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）；
   7. path="/test"的Context获得请求/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；