Spring boot，Tomcat容器之间关系以及请求执行流程
上一篇讲完了spring cloud,Spring boot，Tomcat容器之间关系以及执行顺序，这次再继续讲当一个请求到达服务时，执行的流程：
首先我们得把Tomcat讲清楚：
综上所述，一个tomcat只包含一个Server，一个Server可以包含多个Service，一个Service只有一个Container，但有多个Connector，这样一个服务可以处理多个连接。
多个Connector和一个Container就形成了一个Service，有了Service就可以对外提供服务了，但是Service要提供服务又必须提供一个宿主环境，那就非Server莫属了，所以整个tomcat的声明周期都由Server控制。
Tomcat中的六个容器：
| 容器 | 作用 |
|---|---|
| Server容器 | 一个StandardServer类实例就表示一个Server容器，server是tomcat的顶级构成容器 |
| Service容器 | 一个StandardService类实例就表示一个Service容器，Tomcat的次顶级容器，Service是这样一个集合：它由一个或者多个Connector组成，以及一个Engine，负责处理所有Connector所获得的客户请求。 |
| Engine容器 | 一个StandardEngine类实例就表示一个Engine容器。Engine下可以配置多个虚拟主机Virtual Host，每个虚拟主机都有一个域名。当Engine获得一个请求时，它把该请求匹配到某个Host上，然后把该请求交给该Host来处理，Engine有一个默认虚拟主机，当请求无法匹配到任何一个Host上的时候，将交给该默认Host来处理 |
| Host容器 | 一个StandardHost类实例就表示一个Host容器，代表一个VirtualHost，虚拟主机，每个虚拟主机和某个网络域名Domain Name相匹配。每个虚拟主机下都可以部署(deploy)一个或者多个WebApp，每个Web App对应于一个Context，有一个Context path。当Host获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理。匹配的方法是“最长匹配”，所以一个path==”“的Context将成为该Host的默认Context。所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配 |
| Context容器 | 一个StandardContext类实例就表示一个Context容器。一个Context对应于一个Web Application，一个WebApplication由一个或者多个Servlet组成。Context在创建的时候将根据配置文件CATALINA_HOME/conf/web.xml和WEBAPP_HOME/WEB-INF/web.xml载入Servlet类。当Context获得请求时，将在自己的映射表(mappingtable)中寻找相匹配的Servlet类。如果找到，则执行该类，获得请求的回应，并返回 |
| Wrapper容器 | 一个StandardWrapper类实例就表示一个Wrapper容器，Wrapper容器负责管理一个Servlet，包括Servlet的装载、初始化、资源回收。Wrapper是最底层的容器，其不能在添加子容器了。Wrapper是一个接口，其标准实现类是StandardWrapper |
Server，Service，Engine一目了然，然后Host容器里可能会有点费解，这里先对host解释下：我们知道，在我们访问一个网站时，我们需要在浏览器的地址栏输入一个网页地址，浏览器会试图将域名解析成IP，这个IP代表了连接到互联网的一台主机(Host)。在浏览器向主机发送的HTTP请求中，也包含了请求的Host信息：例如，www.baoidu.com。在最简单的情况下，一台主机只需要对应一个IP，提供一个web服务即可，这种情况下一个IP就对应一台物理主机(Physical Host)。然而，在多数情况下，一台主机不会只提供一个web服务，因而一台物理主机就需要虚拟出多台主机来，这就是Virtual Host。Virtual Host根据实现技术的不同可以分为基于名称的Virtual Host和基于IP的Virtual Host。
基于名称的Virtual Host
基于名称的Virtual Host，对于基于名称的Virtual Host来说，每一个Virtual Host对应一个域名，这些域名都解析到同一个IP下去，这样，这些Virtual Host就共享了这个IP对应的物理主机的资源
基于IP的Virtual Host
不同于基于名称的Virtual Host，在基于IP的Virtual Host中，可以将多个IP地址绑定到同一台物理主机上去，这个是怎么做到的呢？一个方式在物理主机上配置多块网卡，另一个就是通过Virtual Network Interfaces来实现，在Tomcat中配置基于IP的Virtual Host。
好的，说完了host，我们看下请求的流程：
Connector：Connector 用于接收请求并将请求封装成Request 和Response 来具体处理，最底层是使用Socket 来进行连接的， Request 和Response 是按照HTTP 协议来封装的，所以Connector 同时实现了TCP/IP 协议和HTTP 协议， Request 和Response 封装完之后交给Container 进行处理，Container 就是Servlet 的容器， Container 处理完之后返回给Connector，最后Connector 使用Socket 将处理结果返回给客户端，这样整个请求就处理完了。
一个Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得回应并返回客户。
Tomcat有两个典型的Connector：
- 一个直接侦听来自browser的http请求
- 一个侦听来自其它WebServer的请求
Coyote Http/1.1 Connector 在端口8080处侦听来自客户browser的http请求。
Coyote JK2 Connector 在端口8009处侦听来自其它WebServer(Apache)的servlet/jsp代理请求。
请求流程：
1、客户端发送请求:http://localhost:8080/wsota/wsota_index.jsp
2、请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得
3、 Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应
4、 Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host
5、Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）
6、localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context
7、Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为"“的Context去处理）
8、path=”/wsota"的Context获得请求/wsota_index.jsp，在它的mapping table中寻找对应的servlet
9、Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类
10、构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法
11、Context把执行完了之后的HttpServletResponse对象返回给Host
12、Host把HttpServletResponse对象返回给Engine
13、Engine把HttpServletResponse对象返回给Connector
14、Connector把HttpServletResponse对象返回给客户browser
Tomcat的启动与类的具体实现
一个WEB应用对应一个context容器，也就是servlet运行时的负责管理servlet的容器。
添加一个web应用时将会创建一个StandardContext容器，并且给这个context容器设置必要的参数，url和path分别代表这个应用在tomcat中的访问路径和这个应用实际的物理路径，这两个参数与tomcat配置中的两个参数是一致的。
其中一个最重要的一个配置是ContextConfig，这个类会负责整个web应用配置的解析工作。
最后将这个context容器加入到父容器host中。
接下来会调用tomcat的start方法启动tomcat。
Tomcat的启动逻辑是基于观察者模式的，所有的容器都会继承Lifecycle接口，它管理着容器的整个生命周期，所有容器的修改和状态改变都会由它通知已经注册的观察者。
Tomcat启动的时序如下：
ContextConfig的init方法
当context容器初始状态设置Init时，添加到context容器的listener将会被调用。ContextConfig继承了LifecycleListener接口，它是在调用Tomcat.addWebapp时被加入到StandardContext容器中的。ContextConfig类会负责整个WEB应用的配置文件的解析工作。
ContextConfig的init方法将会主要完成一下工作：
创建用于解析XML配置文件的contextDigester对象
读取默认的context.xml文件，如果存在则解析它
读取默认的Host配置文件，如果存在则解析它
读取默认的Context自身的配置文件，如果存在则解析它
设置Context的DocBase
startInternal方法
ContextConfig的init方法完成后，Context容器会执行startInternal方法，这个方法包括如下几个部分：
创建读取资源文件的对象
创建ClassLoader对象
设置应用的工作目录
启动相关的辅助类，如logger,realm,resources等
修改启动状态，通知感兴趣的观察者
子容器的初始化
获取ServletContext并设置必要的参数
初始化“load on startuo”的Servlet
Web应用的初始化
web应用的初始化在14步，下面是该初始化的详细内容
WEB应用的初始化工作是在ContextConfig的configureStart方法中实现的，应用的初始化工作主要是解析web.xml文件，这个文件是一个WEB应用的入口。
Tomcat首先会找globalWebXml，这个文件的搜索路径是engine的工作目录下的org/apache/catalina/startup/NO-DEFAULT_XML或conf/web.xml。
接着会找hostWebXml，这个文件可能会在System.getProperty(“catalina.base”)/conf/$ {EngineName}/${HostName}/web.xml.default中。
接着寻找应用的配置文件examples/WEB-INF/web.xml，web.xml文件中的各个配置项将会被解析成相应的属性保存在WebXml对象中。
接下来会讲WebXml对象中的属性设置到context容器中，这里包括创建servlet对象，filter，listerner等，这些在WebXml的configureContext方法中。
以及下面是解析servlet的代码对象：
for (ServletDef servlet : servlets.values()) {
Wrapper wrapper = context.createWrapper();
String jspFile = servlet.getJspFile();
if (jspFile != null) {
wrapper.setJspFile(jspFile);
}
if (servlet.getLoadOnStartup() != null) {
wrapper.setLoadOnStartup(servlet.getLoadOnStartup().intValue());
}
if (servlet.getEnabled() != null) {
wrapper.setEnabled(servlet.getEnabled().booleanValue());
}
wrapper.setName(servlet.getServletName());
Map<String,String> params = servlet.getParameterMap();
for (Entry<String, String> entry : params.entrySet()) {
wrapper.addInitParameter(entry.getKey(), entry.getValue());
}
wrapper.setRunAs(servlet.getRunAs());
Set<SecurityRoleRef> roleRefs = servlet.getSecurityRoleRefs();
for (SecurityRoleRef roleRef : roleRefs) {
wrapper.addSecurityReference(roleRef.getName(), roleRef.getLink());
}
wrapper.setServletClass(servlet.getServletClass());
MultipartDef multipartdef = servlet.getMultipartDef();
if (multipartdef != null) {
if (multipartdef.getMaxFileSize() != null &&
multipartdef.getMaxRequestSize()!= null &&
multipartdef.getFileSizeThreshold() != null) {
wrapper.setMultipartConfigElement(new MultipartConfigElement(
multipartdef.getLocation(),
Long.parseLong(multipartdef.getMaxFileSize()),
Long.parseLong(multipartdef.getMaxRequestSize()),
Integer.parseInt(
multipartdef.getFileSizeThreshold())));
} else {
wrapper.setMultipartConfigElement(new MultipartConfigElement(
multipartdef.getLocation()));
}
}
if (servlet.getAsyncSupported() != null) {
wrapper.setAsyncSupported(
servlet.getAsyncSupported().booleanValue());
}
context.addChild(wrapper);
}
创建Servlet实例
前面完成了servlet的解析工作，并且被包装成了StandardWrapper添加到Context容器中，但是它仍然不能为我们工作，它还没有被实例化。
如果Servlet的load-on-startup配置项大于0，那么在Context容器启动时就会被实例化。
（这个是在web.xml中进行了配置）
前面提到的在解析配置文件时会读取默认的globalWebXml，在conf下的web.xml文件中定义了一些默认的配置项，其中定义了两个Servlet，分别是org.apache.catalina.servlets.DefaultServlet和org.apache.jsper.servlet.JspServelt，它们的load-on-startup分别是1和3，也就是当tomcat启动时这两个servlet就会被启动。
创建Servlet实例的方式是从Wrapper.loadServlet开始的，loadServlet方法要完成的就是获取servletClass，然后把它交给InstanceManager去创建一个基于servletClass.class的对象。如果这个Servlet配置了jsp-file，那么这个servletClass就是在conf/web.xml中定义的org.apache.jasper.servlet.JspServlet。
tomcat接受请求和Spring boot容器的关联
好的说道这了，要开始说spring boot和tomcat容器的联系：
1、SpringBoot创建Tomcat时，会先创建一个根上下文，webapplicationcontext传给tomcat
2、启动web容器，要先getWebserver，会创建tomcat的Webserver - 这里会把根上下文作为参数给org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory#getWebServer，这里和tomcat的context进行merge
3、初始化servletcontext - 会把root上下文放进去，后面初始化dispatcherServlet时，会通过servletcontext拿到根上下文
4、启动tomcat：调用Tomcat中Host、Engine的启动方法
DIspatcherServlet的初始化
初始化DispatcherServlet，是在第一次发起Web请求的时候（AbstractAnnotationConfigDispatcherServletInitializer）
1、AbstractAnnotationConfigDispatcherServletInitializer初始化ContextLoaderListener：创建ApplicationContext（根上下文）
2、初始化DispatcherServlet - 这时需要ApplicationContext，ApplicationContext是ServletContext的父上下文（WebApplicationContext是Spring为web应用提供的接口）
可以创建多个DispatcherServlet，每个可以创建自己内部的子上下文（每个Servlet都会有一个上下文）
3、DispatcherServlet建立上下文是为了持有Spring MVC的Bean对象
关于SpringMVC、SpringBoot与Tomcat合作中，启动方式不同点
SpringMVC：
1、先启动tomcat，tomcat会去找web.xml,找到的是DispatcherServlet
2、初始化DispatcherServlet的上下文，要从ServletContext中找根上下文，这时是没有的
3、创建根上下文
Springboot：
1、在启动过程中，SpringBoot会将DispatcherServlet给到Tomcat的Service的defaultWrapper中
2、Tomcat启动时，就会把“/”路径和DispatcherServlet匹配
3、当第一次发起Web请求时，初始化DispatcherServlet，包括HandlerMapping，HandlerAdapter
Tomcat源码流程解析：
Tomcat请求流程如下：
1、当用户发送HTTP请求http://localhost/context/wrapper/1
2、NioEndPoint接收到请求（执行其内部类SocketProcessor的run方法）；
3、Http11NioProtocol$Http11ConnectionHandler处理
4、Http11NioProcessor处理
5、CoyoteAdapter将coyote类型Request/Response转换成Servlet类型的Request/Response对象，把请求交给Pipeline管道
6、Engine阀门开始处理，拿到对应的Host，开始将请求交给Host处理；
7、Host阀门开始处理，拿到对应的Context，开始将请求交给Context处理；
8、Context阀门开始处理，拿到对应的Wrapper，开始将请求交给Wrapper处理；
9、Wrapper阀门开始处理，拿到对应的FilterChain，交给FilterChain处理；
10、FilterChain中包含了一个过滤器filters的数组，从该数组中的第一个Filter开始依次执行（filters是在加载web.xml文件的时候设置进去的，这也是过滤器的执行顺序会按照web.xml配置的顺序的执行原因）；
源码
Tomcat启动以后，默认情况下会通过org.apache.tomcat.util.net.JIoEndpoint.Acceptor监听Socket连接，当监听到有Socket连接的时候，就会调用org.apache.tomcat.util.net.JIoEndpoint#processSocket方法进行处理，下面我们就来看看此方法的代码，为了节省版面，只保留与本文相关的代码。
protected boolean processSocket(Socket socket) {
// Process the request from this socket
try {
SocketWrapper<Socket> wrapper = new SocketWrapper<Socket>(socket);
wrapper.setKeepAliveLeft(getMaxKeepAliveRequests());
// During shutdown, executor may be null - avoid NPE
if (!running) {
return false;
}
getExecutor().execute(new SocketProcessor(wrapper));
} catch (RejectedExecutionException x) {
//exception handler ...
return false;
}
return true;
}
通过上面的代码，我们可以看出首先将Socket封装为SocketWrapper，然后通过SocketProcessor来进行处理，因为Tomcat必然面对用户并发请求，因此这里Socket的处理通过新的线程池来处理。接下来我们再来看看SocketProcess的代码，同样省略了一些非核心的代码，代码如下：
public void run() {
boolean launch = false;
synchronized (socket) {
try {
SocketState state = SocketState.OPEN;
try {
// SSL handshake
serverSocketFactory.handshake(socket.getSocket());
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
if (log.isDebugEnabled()) {
log.debug(sm.getString("endpoint.err.handshake"), t);
}
// Tell to close the socket
state = SocketState.CLOSED;
}
if ((state != SocketState.CLOSED)) {
if (status == null) {
// 1
state = handler.process(socket, SocketStatus.OPEN);
} else {
state = handler.process(socket,status);
}
}
if (state == SocketState.CLOSED) {
// Close socket
if (log.isTraceEnabled()) {
log.trace("Closing socket:"+socket);
}
countDownConnection();
try {
socket.getSocket().close();
} catch (IOException e) {
// Ignore
}
} else if (state == SocketState.OPEN ||
state == SocketState.UPGRADING ||
state == SocketState.UPGRADED){
socket.setKeptAlive(true);
socket.access();
launch = true;
} else if (state == SocketState.LONG) {
socket.access();
waitingRequests.add(socket);
}
} finally {
//other code
}
}
socket = null;
// Finish up this request
}
}
默认情况下，代码会运行到标注1的地方，标注1的地方又通过org.apache.tomcat.util.net.JIoEndpoint.Handler#process的方法进行处理，而通过前面Tomcat启动的文章，我们已经知道handler属性是在org.apache.coyote.http11.Http11Protocol的构造方法中初始化的，构造方法如下：
public Http11Protocol() {
endpoint = new JIoEndpoint();
cHandler = new Http11ConnectionHandler(this);
((JIoEndpoint) endpoint).setHandler(cHandler);
setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
}
从构造方法中，我们可以清楚的看到，其实初始化了org.apache.coyote.http11.Http11Protocol.Http11ConnectionHandler的实例，那么接下来我们就来看看它的process方法，因为Http11ConnectionHandler继承了org.apache.coyote.AbstractProtocol.AbstractConnectionHandler，而自己没有实现process方法，因此会调用到父类的process方法，那么接下来我们就来看看AbstractConnectionHandler的process方法，代码如下：
public SocketState process(SocketWrapper<S> socket,
SocketStatus status) {
Processor<S> processor = connections.remove(socket.getSocket());
if (status == SocketStatus.DISCONNECT && processor == null) {
//nothing more to be done endpoint requested a close
//and there are no object associated with this connection
return SocketState.CLOSED;
}
socket.setAsync(false);
try {
if (processor == null) {
processor = recycledProcessors.poll();
}
if (processor == null) {
processor = createProcessor();
}
initSsl(socket, processor);
SocketState state = SocketState.CLOSED;
do {
if (status == SocketStatus.DISCONNECT &&
!processor.isComet()) {
// Do nothing here, just wait for it to get recycled
// Don't do this for Comet we need to generate an end
// event (see BZ 54022)
} else if (processor.isAsync() ||
state == SocketState.ASYNC_END) {
state = processor.asyncDispatch(status);
} else if (processor.isComet()) {
state = processor.event(status);
} else if (processor.isUpgrade()) {
state = processor.upgradeDispatch();
} else {
state = processor.process(socket);
}
if (state != SocketState.CLOSED && processor.isAsync()) {
state = processor.asyncPostProcess();
}
if (state == SocketState.UPGRADING) {
// Get the UpgradeInbound handler
UpgradeInbound inbound = processor.getUpgradeInbound();
// Release the Http11 processor to be re-used
release(socket, processor, false, false);
// Create the light-weight upgrade processor
processor = createUpgradeProcessor(socket, inbound);
inbound.onUpgradeComplete();
}
} while (state == SocketState.ASYNC_END ||
state == SocketState.UPGRADING);
return state;
} catch(java.net.SocketException e) {
// exception handler
}
return SocketState.CLOSED;
}
通过查看上面的代码，默认一个新连接的情况下，会调用org.apache.coyote.Processor#process方法,而Processor的实例实在org.apache.coyote.AbstractProtocol.AbstractConnectionHandler#createProcessor中创建的，通过查看createProcessor代码，我们发现是创建了一个org.apache.coyote.http11.Http11Processor的实例，那么接下来，我们就来看看它的process方法，因为Http11Processor继承了AbstractHttp11Processor，最终其实调用的是AbstractHttp11Processor的process方法，代码如下：
public SocketState process(SocketWrapper<S> socketWrapper)
throws IOException {
RequestInfo rp = request.getRequestProcessor();
rp.setStage(org.apache.coyote.Constants.STAGE_PARSE);
// Setting up the I/O
// 1
setSocketWrapper(socketWrapper);
getInputBuffer().init(socketWrapper, endpoint);
getOutputBuffer().init(socketWrapper, endpoint);
// Flags
error = false;
keepAlive = true;
comet = false;
openSocket = false;
sendfileInProgress = false;
readComplete = true;
if (endpoint.getUsePolling()) {
keptAlive = false;
} else {
keptAlive = socketWrapper.isKeptAlive();
}
if (disableKeepAlive()) {
socketWrapper.setKeepAliveLeft(0);
}
while (!error && keepAlive && !comet && !isAsync() &&
upgradeInbound == null && !endpoint.isPaused()) {
// Parsing the request header
try {
setRequestLineReadTimeout();
//2
if (!getInputBuffer().parseRequestLine(keptAlive)) {
if (handleIncompleteRequestLineRead()) {
break;
}
}
if (endpoint.isPaused()) {
// 503 - Service unavailable
response.setStatus(503);
error = true;
} else {
// Make sure that connectors that are non-blocking during
// header processing (NIO) only set the start time the first
// time a request is processed.
if (request.getStartTime() < 0) {
request.setStartTime(System.currentTimeMillis());
}
keptAlive = true;
// Set this every time in case limit has been changed via JMX
request.getMimeHeaders().setLimit(endpoint.getMaxHeaderCount());
// Currently only NIO will ever return false here
// 3
if (!getInputBuffer().parseHeaders()) {
// We've read part of the request, don't recycle it
// instead associate it with the socket
openSocket = true;
readComplete = false;
break;
}
if (!disableUploadTimeout) {
setSocketTimeout(connectionUploadTimeout);
}
}
} catch (IOException e) {
if (getLog().isDebugEnabled()) {
getLog().debug(
sm.getString("http11processor.header.parse"), e);
}
error = true;
break;
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
UserDataHelper.Mode logMode = userDataHelper.getNextMode();
if (logMode != null) {
String message = sm.getString(
"http11processor.header.parse");
switch (logMode) {
case INFO_THEN_DEBUG:
message += sm.getString(
"http11processor.fallToDebug");
//$FALL-THROUGH$
case INFO:
getLog().info(message);
break;
case DEBUG:
getLog().debug(message);
}
}
// 400 - Bad Request
response.setStatus(400);
adapter.log(request, response, 0);
error = true;
}
if (!error) {
// Setting up filters, and parse some request headers
rp.setStage(org.apache.coyote.Constants.STAGE_PREPARE);
try {
prepareRequest();
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
if (getLog().isDebugEnabled()) {
getLog().debug(sm.getString(
"http11processor.request.prepare"), t);
}
// 400 - Internal Server Error
response.setStatus(400);
adapter.log(request, response, 0);
error = true;
}
}
if (maxKeepAliveRequests == 1) {
keepAlive = false;
} else if (maxKeepAliveRequests > 0 &&
socketWrapper.decrementKeepAlive() <= 0) {
keepAlive = false;
}
// Process the request in the adapter
if (!error) {
try {
// 4
rp.setStage(org.apache.coyote.Constants.STAGE_SERVICE);
adapter.service(request, response);
// Handle when the response was committed before a serious
// error occurred. Throwing a ServletException should both
// set the status to 500 and set the errorException.
// If we fail here, then the response is likely already
// committed, so we can't try and set headers.
if(keepAlive && !error) { // Avoid checking twice.
error = response.getErrorException() != null ||
(!isAsync() &&
statusDropsConnection(response.getStatus()));
}
setCometTimeouts(socketWrapper);
} catch (InterruptedIOException e) {
error = true;
} catch (HeadersTooLargeException e) {
error = true;
// The response should not have been committed but check it
// anyway to be safe
if (!response.isCommitted()) {
response.reset();
response.setStatus(500);
response.setHeader("Connection", "close");
}
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
getLog().error(sm.getString(
"http11processor.request.process"), t);
// 500 - Internal Server Error
response.setStatus(500);
adapter.log(request, response, 0);
error = true;
}
}
// Finish the handling of the request
rp.setStage(org.apache.coyote.Constants.STAGE_ENDINPUT);
if (!isAsync() && !comet) {
if (error) {
// If we know we are closing the connection, don't drain
// input. This way uploading a 100GB file doesn't tie up the
// thread if the servlet has rejected it.
getInputBuffer().setSwallowInput(false);
}
endRequest();
}
rp.setStage(org.apache.coyote.Constants.STAGE_ENDOUTPUT);
// If there was an error, make sure the request is counted as
// and error, and update the statistics counter
if (error) {
response.setStatus(500);
}
request.updateCounters();
if (!isAsync() && !comet || error) {
getInputBuffer().nextRequest();
getOutputBuffer().nextRequest();
}
if (!disableUploadTimeout) {
if(endpoint.getSoTimeout() > 0) {
setSocketTimeout(endpoint.getSoTimeout());
} else {
setSocketTimeout(0);
}
}
rp.setStage(org.apache.coyote.Constants.STAGE_KEEPALIVE);
if (breakKeepAliveLoop(socketWrapper)) {
break;
}
}
rp.setStage(org.apache.coyote.Constants.STAGE_ENDED);
if (error || endpoint.isPaused()) {
return SocketState.CLOSED;
} else if (isAsync() || comet) {
return SocketState.LONG;
} else if (isUpgrade()) {
return SocketState.UPGRADING;
} else {
if (sendfileInProgress) {
return SocketState.SENDFILE;
} else {
if (openSocket) {
if (readComplete) {
return SocketState.OPEN;
} else {
return SocketState.LONG;
}
} else {
return SocketState.CLOSED;
}
}
}
}
上面的代码有点长，但是经过分析，我们还是可以看清楚主干，我已经在代码中将主流程通过数字标注了，我们就来一一看看标注了数字的地方：
标注1的地方（第7行）将Socket的输入流和输出流通过InternalInputBuffer进行了包装，InternalInputBuffer是在Http11Processor的构造函数中初始化的。
标注2的地方（第35行）调用了InternalInputBuffer的parseRequesLine方法解析http请求的请求行。(关于http请求行和请求头请看下文解释)
标注3的地方（第57行）调用了InternalInputBuffer的prarseHeaders方法解析http请求的请求头。解析完了以后，会将http header保存在org.apache.tomcat.util.http.MimeHeaders
标注4的地方（第128行）调用了org.apache.coyote.Adapter#service方法，次方法就会最终调用到具体的Servlet.
对于Http请求行和请求头，例子：
GET /contextpath/querystring HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=9F5897FEF3CDBCB234C050C132DCAE52; __atuvc=384%7C39; __utma=96992031.358732763.1380383869.1381468490.1381554710.38; __utmz=96992031.1380383869.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); Hm_lvt_21e144d0df165d6556d664e2836dadfe=1381330561,1381368826,1381395666,1381554711
Connection: keep-alive
Cache-Control: max-age=0
在上面的Http协议get请求中，其中请求行就是第一行，GET /contextpath/querystring HTTP/1.1,余下的都是请求头。这里面需要注意根据Http协议的要求，请求行末尾必须是CRLF，而请求行与请求头，以及请求头之间必须用空行隔开，而空行也必须只包含CRLF。
通过上面的描述，我们可以整理出如下的一个请求解析流程：
org.apache.tomcat.util.net.JIoEndpoint.Acceptor#run
->org.apache.tomcat.util.net.JIoEndpoint.SocketProcessor#run(请求处理线程池中运行)
-->org.apache.coyote.AbstractProtocol.AbstractConnectionHandler#process
--->org.apache.coyote.http11.AbstractHttp11Processor#process
---->org.apache.coyote.http11.InternalInputBuffer#parseRequestLine
---->org.apache.coyote.http11.InternalInputBuffer#parseHeaders
---->org.apache.catalina.connector.CoyoteAdapter#service
转发到Servlet
上面我们说了一个请求过来是如何根据http协议解析Socket的数据，最终将生成org.apache.coyote.Request和org.apache.coyote.Response，接下来我们就来看看request,reponse是如何一步步的进入最终的Servlet进行处理的。这一步的入口就是CoyoteAdapter的service方法。 接下来我们就来看看它的代码：
public void service(org.apache.coyote.Request req,
org.apache.coyote.Response res)
throws Exception {
Request request = (Request) req.getNote(ADAPTER_NOTES);
Response response = (Response) res.getNote(ADAPTER_NOTES);
//1
if (request == null) {
// Create objects
request = connector.createRequest();
request.setCoyoteRequest(req);
response = connector.createResponse();
response.setCoyoteResponse(res);
// Link objects
request.setResponse(response);
response.setRequest(request);
// Set as notes
req.setNote(ADAPTER_NOTES, request);
res.setNote(ADAPTER_NOTES, response);
// Set query string encoding
req.getParameters().setQueryStringEncoding
(connector.getURIEncoding());
}
if (connector.getXpoweredBy()) {
response.addHeader("X-Powered-By", POWERED_BY);
}
boolean comet = false;
boolean async = false;
try {
// Parse and set Catalina and configuration specific
// request parameters
req.getRequestProcessor().setWorkerThreadName(Thread.currentThread().getName());
//2
boolean postParseSuccess = postParseRequest(req, request, res, response);
if (postParseSuccess) {
//check valves if we support async
request.setAsyncSupported(connector.getService().getContainer().getPipeline().isAsyncSupported());
// Calling the container
//3
connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);
// other code
}
// other code
} catch (IOException e) {
// Ignore
} finally {
req.getRequestProcessor().setWorkerThreadName(null);
// Recycle the wrapper request and response
if (!comet && !async) {
request.recycle();
response.recycle();
} else {
// Clear converters so that the minimum amount of memory
// is used by this processor
request.clearEncoders();
response.clearEncoders();
}
}
}
为了可以清楚的看到主流程，上面删除了一部分非主流程的代码，接下来我们逐一分析一下标注了数字的地方：
标注1的代码(第9行)将org.apache.coyote.Request和org.apache.coyote.Response对象转变为org.apache.catalina.connector.Request,org.apache.catalina.connector.Response类型的对象。其中coyote包中的Request仅仅只是包含了解析出来的http协议的数据，而connector包中的Request才是真正Servlet容器中的HttpServletRequest，它里面包含了完成请求需要的host,context和wrapper信息,在这里每一个wrapper其实都对应web.xml配置的一个Servlet。
标注2（第44行）的代码调用了postParseRequest方法，这个方法里面做的事情非常多，但是最终都是为了根据Request对象找到对应的Host,Conext和Wrapper对象，也就是说最终要清楚这个请求应该由哪个Servlet来处理。
标注3（第50）的代码将已经设置好了Host,Context,Wrapper对象的Request通过Pipeline机制链式传递给最终的Servlet。
上面只是从整体上告诉了读者org.apache.catalina.connector.CoyoteAdapter#service方法做的事情，接下来我们进一步分解每一个步骤都具体做了哪些工作。第一步比较简单，大家可以自己阅读，我们关键来看2，3步。首先我们来看看postParseRequest方法。 通过分析org.apache.catalina.connector.CoyoteAdapter#postParseRequest的代码，我们会发现它最终是通过org.apache.tomcat.util.http.mapper.Mapper#map方法来达到匹配请求到对应的Context和Wrapper(Servlet包装类)目的。具体代码如下：
connector.getMapper().map(serverName, decodedURI, version,
request.getMappingData());
request.setContext((Context) request.getMappingData().context);
request.setWrapper((Wrapper) request.getMappingData().wrapper);
那我们再来看看此方法。通过分析它的代码，我们发现最终其实是调用了几个internalMap**方法将找到的Context,Wrapper设置到org.apache.catalina.connector.Request对象的org.apache.tomcat.util.http.mapper.MappingData类型的属性中,map方法执行完以后，然后接下来就从MappingData中获取已经找到的Context和Wrapper，再设置到Request的context和wrapper中。
接下来我们再来分析第3步，第3步通过pipeline链式调用机制最终调用了Servlet对象，而对于pipeline其实是运用了责任链模式，它将各个阀门链接起来，然后一步步的调用，而至于有多少个阀门（Valve）对象，主要来源于两个地方，一个是conf/server.xml中配置的valve，我们知道所有的容器都是支持pipeline机制的，另外一个就是每一个容器的构造其中自己初始化的阀门对象。接下来一一看一下。对于StandardEngine来说有一个与之对应的StandardEngineValve，对于StandardHost有一个StandardHostValve与之对应，StandardContext有一个StandardContextValve与之对应，StandardWrapper与StandardWrapperValve对应,通过分析代码，我们可以得到如下的一个调用链。
接下来我们再来分析第3步，第3步通过pipeline链式调用机制最终调用了Servlet对象，而对于pipeline其实是运用了责任链模式，它将各个阀门链接起来，然后一步步的调用，而至于有多少个阀门（Valve）对象，主要来源于两个地方，一个是conf/server.xml中配置的valve，我们知道所有的容器都是支持pipeline机制的，另外一个就是每一个容器的构造其中自己初始化的阀门对象。接下来一一看一下。对于StandardEngine来说有一个与之对应的StandardEngineValve，对于StandardHost有一个StandardHostValve与之对应，StandardContext有一个StandardContextValve与之对应，StandardWrapper与StandardWrapperValve对应,通过分析代码，我们可以得到如下的一个调用链。
->org.apache.catalina.core.StandardEngineValve#invoke
–>org.apache.catalina.valves.AccessLogValve#invoke
—>org.apache.catalina.valves.ErrorReportValve#invoke
---->org.apache.catalina.core.StandardHostValve#invoke
----->org.apache.catalina.authenticator.AuthenticatorBase#invoke
------>org.apache.catalina.core.StandardContextValve#invoke
------->org.apache.catalina.core.StandardWrapperValve#invoke
上述的调用栈中，最后会调用到StandardWrapperValve，它其实也是最终调用Servlet的地方，接下来我们就来看看它的代码：
public final void invoke(Request request, Response response)
throws IOException, ServletException {
// Initialize local variables we may need
boolean unavailable = false;
Throwable throwable = null;
// This should be a Request attribute...
long t1=System.currentTimeMillis();
requestCount++;
StandardWrapper wrapper = (StandardWrapper) getContainer();
Servlet servlet = null;
Context context = (Context) wrapper.getParent();
// Allocate a servlet instance to process this request
try {
//1
if (!unavailable) {
servlet = wrapper.allocate();
}
} catch (UnavailableException e) {
container.getLogger().error(
sm.getString("standardWrapper.allocateException",
wrapper.getName()), e);
long available = wrapper.getAvailable();
if ((available > 0L) && (available < Long.MAX_VALUE)) {
response.setDateHeader("Retry-After", available);
response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE,
sm.getString("standardWrapper.isUnavailable",
wrapper.getName()));
} else if (available == Long.MAX_VALUE) {
response.sendError(HttpServletResponse.SC_NOT_FOUND,
sm.getString("standardWrapper.notFound",
wrapper.getName()));
}
} // other code
MessageBytes requestPathMB = request.getRequestPathMB();
DispatcherType dispatcherType = DispatcherType.REQUEST;
if (request.getDispatcherType()==DispatcherType.ASYNC) dispatcherType = DispatcherType.ASYNC;
request.setAttribute(Globals.DISPATCHER_TYPE_ATTR,dispatcherType);
request.setAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR,
requestPathMB);
// Create the filter chain for this request
ApplicationFilterFactory factory =
ApplicationFilterFactory.getInstance();
ApplicationFilterChain filterChain =
factory.createFilterChain(request, wrapper, servlet);
// Reset comet flag value after creating the filter chain
request.setComet(false);
// Call the filter chain for this request
// NOTE: This also calls the servlet's service() method
// 2
try {
if ((servlet != null) && (filterChain != null)) {
// Swallow output if needed
if (context.getSwallowOutput()) {
try {
SystemLogHandler.startCapture();
if (request.isAsyncDispatching()) {
//TODO SERVLET3 - async
((AsyncContextImpl)request.getAsyncContext()).doInternalDispatch();
} else if (comet) {
filterChain.doFilterEvent(request.getEvent());
request.setComet(true);
} else {
filterChain.doFilter(request.getRequest(),
response.getResponse());
}
} finally {
String log = SystemLogHandler.stopCapture();
if (log != null && log.length() > 0) {
context.getLogger().info(log);
}
}
} else {
if (request.isAsyncDispatching()) {
//TODO SERVLET3 - async
((AsyncContextImpl)request.getAsyncContext()).doInternalDispatch();
} else if (comet) {
request.setComet(true);
filterChain.doFilterEvent(request.getEvent());
} else {
filterChain.doFilter
(request.getRequest(), response.getResponse());
}
}
}
} catch(Exception e){
// other code
}
}
标注1（第17行）的代码实例化了Servlet对象，在实例化的过程中使用了Java双检查锁的机制来实例化Servlet，有兴趣的童鞋可以去看看org.apache.catalina.core.StandardWrapper#allocate的代码。这里需要注意的是在Servlet2.4规范之前，有一个singleThreadMode模型，这个机制类似与之前EJB的无状态会话Bean机制，每个线程过来会通过实例池中取出一个实例来完成响应。在Servlet规范2.4之后，单线程模型已经被废除了。具体细节可以参考这里 .
标注2（第55行）的代码其实调用了大家熟悉的Servlet的过滤器链，过滤器链最终就会调用到Servlet.
最后，咋们再来看看过滤器滤链的处理，来看看org.apache.catalina.core.ApplicationFilterChain#doFilter，doFilter方法中会根据filterConfig中取的web.xml配置的过滤器，然后一个个调用，等每个过滤器执行完了以后，最终就会调用到Servlet的Service方法。
小结一下FilterChain在这里面的调用
FilterChain构造
当请求传递到servlet对应的StandardWrapperValve类时，如果当前的servlet可以被访问，那么会分配一个servlet实例并构造一个ApplicationFilterChain来处理这次请求。
创建一个ApplicationFilterChain实例后，会设置对应的servlet,将当前servletContext中的FilterMap数组取出，如果匹配请求的dispatch模式和路径，或者是匹配请求的dispatch模式和servlet的名称，就会将FilterMap对应的ApplicationFilterConfig加入到ApplicationFilterChain中。FilterMap和ApplicationFilterConfig都存储在servletContext中。
FilterChain使用
Filter由对应的FilterConfig获得，ApplicationFilterChain的第一次DoFilter由StandardWrapperValve调用，每次调用DoFilter，ApplicationFilterChain中的index便会指向下一个FilterMap。如果没有index>=FilterMap数组的长度，便会调用对应servlet类的service函数。
在这里除了第一次调用DoFilter由ApplicationFilterChain代码执行，其余的DoFilter都需要由Filter调用。
FilterMap和FilterConfig的加载
当Tomcat启动的时候,StandardHost下的StandardContext会调用初始化器的OnStartUp()函数，触发ContextConfig的Start事件，接着回去调用Digester类解析web.xml文件，Digester类会通过反射调用WebXml.addFilter和WebXml.addFilterMapping函数，将FilterDef和filterMap添加到WebXml的实例中。合并完WebXml后，会检验每个filterMap的合法性，并将其添加到StandardContext的filterMap数组中。
如果配置都合法，那么StandardContext会调用filterStart函数，将StandardContext和filterDefs注册到ApplicationFilterConfig中，并将其添加到filterConfigs Map中去。可以通过filterMap的name从filterConfig中获得对应的filterDef。
总结
通过上面的分析，其实我们已经清楚了一个请求过来以后，Tomcat是如何一步步处理的。我们再来做一个总体的总结：
用户浏览器发送请求，请求会发送到对应的Connector监听的Socket端口。
Connector从Socket流中获取数据，然后根据Http协议将其解析为Request和Reponse对象
找到Request对象对应的Host,Context,Wrapper
调用最终的Servelt的service进行处理。
魔乐社区（Modelers.cn) 是一个中立、公益的人工智能社区，提供人工智能工具、模型、数据的托管、展示与应用协同服务，为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作，由全产业链共同建设、共同运营、共同享有，推动国产AI生态繁荣发展。
更多推荐
12
0- 0
已为社区贡献2条内容
所有评论(0)