Web容器是什么？
早期的Web应用主要用于浏览新闻等静态页面，HTTP服务器（比如Apache、Nginx）向浏览器返回静态HTML，浏览器负责解析HTML，将结果呈现给用户。
随着互联网的发展，我们已经不满足于仅仅浏览静态页面，还希望通过一些交互操作，来获取动态结果，因此也就需要一些扩展机制能够让HTTP服务器调用服务端程序。于是Sun公司推出了Servlet技术。你可以把Servlet简单理解为运行在服务端的Java小程序，但是Servlet没有main方法，不能独立运行，因此必须把它部署到Servlet容器中，由容器来实例化并调用Servlet。
Java从入门到项目实战淘宝￥49.8￥79.8购买而Tomcat就是一个Servlet容器。为了方便使用，它们也具有HTTP服务器的功能，因此Tomcat就是一个“HTTP服务器+Servlet容器”，我们也叫它们Web容器。
HTTP服务器要解析处理HTTP协议，它底层的通信协议(传输层的协议)是TCP/IP协议。(也能说基于TCP/IP构建了HTTP协议)。
Tomcat和HTTP的关联：
在传输层协议之上，Tomcat拿到请求数据之后进行封装，封装成HTTP协议，这算是Tomcat的一块核心。
Tomcat的HTTP服务器的功能：首先把请求的HTTP协议解析出来，解析完之后，要进行一个业务的处理，所以就将数据交给了Servlet容器来做。这里面就定义了很多Litener,Filter等这些Servlet规范(Servlet接口)，通过这些接口我们将数据传到我们的业务代码中。
从Connector获取到连接，从连接当中获取请求数据，将请求数据解析成我们的HTTP协议。HTTP协议解析完成以后，将数据交给Servlet容器。通过Servlet接口的方法，我们对Serlvet接口方法进行实现，就能进行相关的Servlet业务处理。
从Connector传到Engine中的Host(根据请求带的不同域名，来到不同Host)的Context(就是我们的Web项目),Context的Wrapper(这是Tomcat对Servlet的一个封装，每一个Servlet对应一个Wrapper),这个过程叫管道线模型。
SpringBoot会为每个Web项目引入一个内嵌的Tomcat，即一个Web项目对应一个Tomcat。
一般后端项目都分为两部分：网络层，逻辑业务层
用目前最稳定的协议TCP/IP协议负责网络层的交互(能进行网络互连)，网络层把数据交给业务层。
那么这个逻辑反映到Tomcat的架构中就是网络层直接的数据传输用Connector进行处理，业务就交给Context处理。那么数据要从Connector传到Context才能进行业务处理。包括因为访问路径的域名不同，对应不同的Host组件进行处理，Host中又有不同的Context(工程)来完成不同的任务。
以上只能体现网络层的重要性，那Servlet容器呢？
这是简单的Socket编程，TCP/IP协议的简单实现。这里只能通过TCP/IP协议来接收到请求来的数据，然后呢？我们要把这些数据传给业务层。怎么传这个问题还好说，传到哪才是关键。难道我们要解析请求路径然后不断的if/else来转发到项目的不同业务上吗?这样肯定不行的，太麻烦。
所以Servlet出现了，它定义了接口规范，Servlet就是为了将HTTP服务封装好的数据流向业务层的。其中Servlet为了更好的接收HTTP服务器发来的封装好的数据，它又写了一个HTTPServlet，里面的方法包含了HttpServletRequest，HttpServletResponse参数。
Tomcat的源码：
HTTP的本质
HTTP协议是浏览器与服务器之间的数据传送协议。作为应用层协议，HTTP是基于TCP/IP协议来传递数据的（HTML文件、图片、查询结果等），
HTTP协议不涉及数据包（Packet）传输，主要规定了客户端和服务器之间的通信格式
(HTTP是格式规范，TCP/IP是实现)
假如浏览器需要从远程HTTP服务器获取一个HTML文本，在这个过程中，浏览器实际上要做两件事情。
1.与服务器建立Socket连接。
2.生成请求数据并通过Socket发送出去。
HTTP请求响应实例
用户在登陆页面输入用户名和密码，点击登陆后，浏览器发出了这样的HTTP请求：
HTTP请求数据由三部分组成，分别是请求行、请求报头、请求正文。当这个HTTP请求数据到达Tomcat后，Tomcat会把HTTP请求数据字节流解析成一个Request对象，这个Request对象封装了HTTP所有的请求信息。接着Tomcat把这个Request对象交给Web应用去处理，处理完后得到一个Response对象，Tomcat会把这个Response对象转成HTTP格式的响应数据并发送给浏览器。
Response请求
HTTP的响应也是由三部分组成，分别是状态行、响应报头、报文主体。同样，我还以时间登陆请求的响应为例。
早期Tomcat对BioServer的支持：
拿到客户端的请求数据时，通过线程池来处理客户端连接，处理连接就是解析数据，
Cookie和Session
我们知道，HTTP协议有个特点是无状态，请求与请求之间是没有关系的。这样会出现一个很尴尬的问题：Web应用不知道你是谁，登录一个网页，我退出了，又要再登一次。因为发送的请求不能让服务器识别出你的身份。因此HTTP协议需要一种技术让请求与请求之间建立起联系，并且服务器需要知道这个请求来自哪个用户，于是Cookie技术出现了。
Cookie是HTTP报文的一个请求头，Web应用可以将用户的标识信息或者其他一些信息（用户登录状态，用户名等）存储在Cookie中。用户经过验证之后，每次HTTP请求报文中都包含Cookie，这样服务器读取这个Cookie请求头就知道用户是谁了。Cookie本质上就是一份存储在用户本地的文件，里面包含了每次请求中都需要传递的信息。
由于Cookie以明文的方式存储在本地，而Cookie中往往带有用户信息，这样就造成了非常大的安全隐患。而Session的出现解决了这个问题，**Session可以理解为服务器端开辟的存储空间，里面保存了用户的状态，用户信息以Session的形式存储在服务端。**当用户请求到来时，服务端可以把用户的请求和用户的Session对应起来。那么Session是怎么和请求对应起来的呢？答案是通过Cookie，浏览器在Cookie中填充了一个SessionID之类的字段用来标识请求。
具体工作过程是这样的：服务器在创建Session的同时，会为该Session生成唯一的SessionID，当浏览器再次发送请求的时候，会将这个SessionID带上，服务器接受到请求之后就会依据SessionID找到相应的Session，找到Session后，就可以在Session中获取或者添加内容了。而这些内容只会保存在服务器中，发到客户端的只有SessionID，这样相对安全，也节省了网络流量，因为不需要在Cookie中存储大量用户信息。
那么Session在何时何地创建呢？当然还是在服务器端程序运行的过程中创建的，不同语言实现的应用程序有不同的创建Session的方法。在Java中，是Web应用程序在调用HttpServletRequest的getSession方法时，由Web容器（比如Tomcat）创建的。
Tomcat的Session管理器提供了多种持久化方案来存储Session，通常会采用高性能的存储方式，比如Redis，并且通过集群部署的方式，防止单点故障，从而提升高可用。同时，Session有过期时间，因此Tomcat会开启后台线程定期的轮询，如果Session过期了就将Session失效。
Servlet规范
HTTP服务器怎么知道要调用哪个Java类的哪个方法呢。最直接的做法是在HTTP服务器代码里写一大堆ifelse逻辑判断：如果是A请求就调X类的M1方法，如果是B请求就调Y类的M2方法。但这样做明显有问题，因为HTTP服务器的代码跟业务逻辑耦合在一起了，如果新加一个业务方法还要改HTTP服务器的代码。
那该怎么解决这个问题呢？我们知道，面向接口编程是解决耦合问题的法宝，于是有一伙人就定义了一个接口，各种业务类都必须实现这个接口，这个接口就叫Servlet接口，有时我们也把实现了Servlet接口的业务类叫作Servlet。
但是这里还有一个问题，
对于特定的请求，HTTP服务器如何知道由哪个Servlet来处理呢
？Servlet又是由谁来实例化呢？显然HTTP服务器不适合做这个工作，否则又和业务类耦合了。
于是，还是那伙人又发明了Servlet容器，Servlet容器用来加载和管理业务类。HTTP服务器不直接跟业务类打交道，而是把请求交给Servlet容器去处理，Servlet容器会将请求转发到具体的Servlet，如果这个Servlet还没创建，就加载并实例化这个Servlet，然后调用这个Servlet的接口方法。因此Servlet接口其实是Servlet容器跟具体业务类之间的接口。下面我们通过一张图来加深理解。
Servlet接口和Servlet容器这一整套规范叫作Servlet规范。Tomcat和Jetty都按照Servlet规范的要求实现了Servlet容器，同时它们也具有HTTP服务器的功能。作为Java程序员，如果我们要实现新的业务功能，只需要实现一个Servlet，并把它注册到Tomcat（Servlet容器）中，剩下的事情就由Tomcat帮我们处理了。
Servlet接口定义了下面五个方法：
Tomcat管理Servlet就是通过这5个方法进行管理(调用)的
其中最重要是的service方法，具体业务类在这个方法里实现处理逻辑。这个方法有两个参数：ServletRequest和ServletResponse。ServletRequest用来封装请求信息，ServletResponse用来封装响应信息，因此本质上这两个类是对通信协议的封装。
HTTP协议中的请求和响应就是对应了HttpServletRequest和HttpServletResponse这两个类。你可以通过HttpServletRequest来获取所有请求相关的信息，包括请求路径、Cookie、HTTP头、请求参数等。此外，我们还可以通过HttpServletRequest来创建和获取Session。而HttpServletResponse是用来封装HTTP响应的。
你可以看到接口中还有两个跟生命周期有关的方法init和destroy，这是一个比较贴心的设计，Servlet容器在加载Servlet类的时候会调用init方法，在卸载的时候会调用destroy方法。我们可能会在init方法里初始化一些资源，并在destroy方法里释放这些资源，比如SpringMVC中的DispatcherServlet，就是在init方法里创建了自己的Spring容器。
你还会注意到ServletConfig这个类，ServletConfig的作用就是封装Servlet的初始化参数。你可以在web.xml给Servlet配置参数，并在程序里通过getServletConfig方法拿到这些参数。
我们知道，有接口一般就有抽象类，抽象类用来实现接口和封装通用的逻辑，因此Servlet规范提供了GenericServlet抽象类，我们可以通过扩展它来实现Servlet。虽然Servlet规范并不在乎通信协议是什么，但是大多数的Servlet都是在HTTP环境中处理的，因此Servet规范还提供了HttpServlet来继承GenericServlet，并且加入了HTTP特性。这样我们通过继承HttpServlet类来实现自己的Servlet，只需要重写两个方法：doGet和doPost。
Servlet容器
当客户请求某个资源时，HTTP服务器会用一个ServletRequest对象把客户的请求信息封装起来，然后调用Servlet容器的service方法，Servlet容器拿到
请求后，根据请求的URL和Servlet的映射关系，找到相应的Servlet，如果Servlet还没有被加载，就用反射机制创建这个Servlet，并调用Servlet的init方法来完成初始化，接着调用Servlet的service方法来处理请求，把ServletResponse对象返回给HTTP服务器，HTTP服务器会把响应发送给客户端
Servlet容器会实例化和调用Servlet，那Servlet是怎么注册到Servlet容器中的呢？一般来说，我们是以Web应用程序的方式来部署Servlet的，而根据Servlet规范，Web应用程序有一定的目录结构，在这个目录下分别放置了Servlet的类文件、配置文件以及静态资源，Servlet容器通过读取配置文件，就能找到并加载Servlet。Web应用的目录结构大概是下面这样的：
Servlet规范里定义了ServletContext这个接口来对应一个Web应用。Web应用部署好后，Servlet容器在启动时会加载Web应用，并为每个Web应用创建唯一的ServletContext对象。你可以把ServletContext看成是一个全局对象，一个Web应用可能有多个Servlet，这些Servlet可以通过全局的ServletContext来共享数据，这些数据包括Web应用的初始化参数、Web应用目录下的文件资源等。由于ServletContext持有所有Servlet实例，你还可以通过它来实现Servlet请求的转发。
扩展机制
引入了Servlet规范后，你不需要关心Socket网络通信、不需要关心HTTP协议，也不需要关心你的业务类是如何被实例化和调用的，因为这些都被Servlet规范标准化了，你只要关心怎么实现的你的业务逻辑。这对于程序员来说是件好事，但也有不方便的一面。所谓规范就是说大家都要遵守，就会千篇一律，但是如果这个规范不能满足你的业务的个性化需求，就有问题了，因此设计一个规范或者一个中间件，要充分考虑到可扩展性。Servlet规范提供了两种扩展机制：Filter和Listener。
Spring中有BeanFactory，后置处理器…来进行Spring的功能拓展。Servlet容器也有：
filter和listener标签中就可以添加很多filter和listener来进行拓展
Filter
是过滤器，这个接口允许你对请求和响应做一些统一的定制化处理，比如你可以根据请求的频率来限制访问，或者根据国家地区的不同来修改响应内容。过滤器的工作原理是这样的：Web应用部署完成后，Servlet容器需要实例化Filter并把Filter链接成一个FilterChain。当请求进来时，获取第一个Filter并调用doFilter方法，doFilter方法负责调用这个FilterChain中的下一个Filter。
Listener是监听器，这是另一种扩展机制。当Web应用在Servlet容器中运行时，Servlet容器内部会不断的发生各种事件，如Web应用的启动和停止、用户请求到达等。Servlet容器提供了一些默认的监听器来监听这些事件，当事件发生时，Servlet容器会负责调用监听器的方法。当然，你可以定义自己的监听器去监听你感兴趣的事件，将监听器配置在web.xml中。比如Spring就实现了自己的监听器，来监听ServletContext的启动事件，目的是当Servlet容器启动时，创建并初始化全局的Spring容器。
联系电话：