Tomcat

4.1  Tomcat服务器

4.1.1Tomcat结构

从图中可以很清楚的发现，Tomcat其实很模块化的。由于Tomcat更新很快，所以这里不深入到源码去研究了。简单的了解下各个组件的作用。

1、Server

这个Server就代表一个服务器，也就是Servlet容器。

2、Service

Service由一个Engine和多个Connector组成，负责处理所有Connector所获得的客户请求。

3、Connector

Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得回应并返回客户。它的主要任务是负责接收浏览器的发过来的 tcp 连接请求，创建一个 Request 和 Response 对象分别用于和请求端交换数据，然后会产生一个线程来处理这个请求并把产生的 Request 和 Response 对象传给处理这个请求的线程熟悉Tomcat的人应该知道Tomcat一般监听2个端口，这是为什么？因为Tomcat有两个典型的Connector，一个直接侦听来自browser的http请求，一个侦听来自其它WebServer的请求。

4、Engine

当Engine获得一个请求时，它把该请求匹配到某个Host上，然后把该请求交给该Host来处理Engine有一个默认虚拟主机，当请求无法匹配到任何一个Host上的时候，将交给该默认Host来处理。

5、Host

代表一个虚拟主机当Host获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理。

6、Context

一个Context对应于一个Web Application，一个Web Application由一个或者多个Servlet组成。Context在创建的时候将根据配置文件$CATALINA_HOME/conf/web.xml和$WEBAPP_HOME/WEB-INF/web.xml载入Servlet类，当Context获得请求时，将在自己的web.xml中寻找相匹配的Servlet类。执行，获得请求的回应，并返回。

4.1.1配置文件web.xml简述

当一个Web Application被初始化的时候，它将用自己的ClassLoader对象载入“部署配置文件web.xml”中定义的每个servlet类。

它首先载入在$CATALINA_HOME/conf/web.xml中部署的servlet类，然后载入在自己的Web Application根目录下的WEB-INF/web.xml中部署的servlet类。
    配置文件web.xml文件有两部分：servlet类定义和servlet映射定义，每个被载入的servlet类都有一个名字，且被填入该Context的映射表中，和某种URL PATTERN对应。当该Context获得请求时，将查询映射表，找到被请求的servlet，并执行以获得请求回应。

4.1.1Tomcat处理http请求的过程

1、请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得

2、Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应

3、Engine获得请求localhost/neuq_index.jsp，匹配它所拥有的所有虚拟主机Host

4、Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）

5、localhost Host获得请求/neuq _index.jsp，匹配它所拥有的所有Context

6、Host匹配到路径为/neuq的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）

7、path="/neuq"的Context获得请求/neuq _index.jsp，在它的映射表中寻找对应的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对象返回给客户浏览器

4.2  Servlet

Servlet也是依附在Servlet容器从能运行的，这个Servlet容器也就是上文所说的Context容器。

4.3  Filter

Filter类除了提供request和response对象外，还提供一个FilterChain对象，这个对象可以让我们更加灵活地控制请求的流转。核心就是传递FilterChain对象，这个对象保存了到最终Servlet对象的所有Filter对象，这些对象都保存在ApplicationFilterChain对象的filters数组中。FilterChain链上每执行一个Filter对象，数组当前的计数就加，直到计数等于数组的长度，最终就会执行servlet。

 

4.4  Session与Cookie

Session 与 Cookie 的作用都是为了保持访问用户与后端服务器的交互状态。它们有各自的优点，也有各自的缺陷。Cookie是占的带宽太大，因为它是存在浏览器端需要发送给服务器。而Session是不容易在多台服务器之间共享，所以这也限制了 Session 的使用。

4.4.1Cookie

Cookie就是当一个用户通过 HTTP 协议访问一个服务器的时候，这个服务器会将一些 Key/Value 键值对返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时这个用户下次访问这个服务器的时候，数据又被完整地带回。

由于 HTTP 协议是一种无状态协议，当用户的一次访问请求结束后，后端服务器就无法知道下一次来访问的还是不是上次访问的用户，在设计应用程序时，我们很容易想到两次访问是同一人访问与不同的两个人访问对程序设计和性能来说有很大的不同。例如，在一个很短的时间内，如果与用户相关的数据被频繁访问，可以针对这个数据做缓存，这样可以大大提高数据的访问性能。Cookie 的作用正是在此，由于是同一个客户端发出的请求，每次发出的请求都会带有第一次访问时服务端设置的信息，这样服务端就可以根据 Cookie 值来划分访问的用户了。对于占带宽这个缺点可以使用Cookie压缩来解决。

4.4.2Session

每次客户端的访问都必须传回这些 Cookie，如果 Cookie 很多，这无形地增加了客户端与服务端的数据传输量，而 Session 的出现正是为了解决这个问题。

同一个客户端每次和服务端交互时，不需要每次都传回所有的 Cookie 值，而是只要传回一个 ID，这个 ID 是客户端第一次访问服务器的时候生成的，而且每个客户端是唯一的。这样每个客户端就有了一个唯一的 ID，客户端只要传回这个 ID 就行了，这个 ID 通常是的名字是JSESIONID 的一个 Cookie。对于Session无法在多台服务器共享可以使用分布式Session框架，如Zookeeper来管理。

4.5  WebService

WebService就是以 HTTP 协议为基础，通过 XML 进行客户端和服务器端通信的协议，它有两个关键点:

1.服务端提供的功能 , 通过 xml 描述

2.第一步中的描述的功能 , 嵌入到 HTTP 协议中,使得能通过 HTTP 协议进行通信，还有两个重要概念:

SOAP: SOAP协议是基于HTTP协议的，SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式

WSDL: 就是这样一个基于XML的语言，用于描述Web Service及其函数、参数和返回值。它是WebService客户端和服务器端都 能理解的标准格式。

这里通信机制就类似于，RMI、RPC等等。无非就是资源不在本地，要去其他服务器获取所需资源，那么就要通信机制找到对应的服务器，IP、TCP等等的基本协议。找到后又该如何通信呢？对方的资源本机又是如何表示呢？通过什么传输机制来传输数据呢？其实无非这几个问题罢了。