Tomcat源码分析-http请求走过的那些路（二）

￡神魔★判官ぃ 2022-12-17 14:56 105阅读 0赞

# 1. 概述 #

在上篇文章[Tomcat源码分析-http请求走过的那些路（一）][Tomcat_-http]中，我们主要讲解了一个Http请求如何被tomcat接受。这里我们简单回顾一下。当Tomcat启动后，Acceptor会开启8080端口用于监听请求事件。当接受到请求，Acceptor会经过一系列的处理，通过轮训的方式转接为poller，poller通过事件处理的方式最终交给任务线程池处理。那么今天，我们就从(org.apache.tomcat.util.net. NioEndpoint.SocketProcessor\#doRun)出发，继续探寻Tomcat是如何处理Http请求的。

# 2. 流程时序图 #

为了更好的理解Http请求在Tomcat的处理过程，我想还是先上一张图，先让大家有个大致的了解和认识。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L29ZaW5IZVpoaUd1YW5n_size_16_color_FFFFFF_t_70][]

# 3.流程详细分析 #

## 3.1 SocketProcessor\#dorun() ##

在这一部分代码中，主要分为两部分的。第一部分是对handshake（握手状态）的处理；第二部分是根据握手状态处理实际的业务逻辑。

### 3.1.1握手状态处理 ###

根据代码上下文，我们知道handshake总共可以取4个值，分别为-1（默认）、0（握手完成）、SelectionKey.OP\_READ和SelectionKey.OP\_WRITE。那么下面就简单说一下这四个值。

1）-1（默认），虽然是默认，但是作为一个正常的http请求是不希望看到这个值的。

int handshake = -1;

2）0。这是正常处理业务逻辑的值。他必须满足两个条件：第一，当前的socket的channel包含此选择器；第二，socket的握手过程已经完成。

SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector());
    if (socket.isHandshakeComplete()) {
    	// No TLS handshaking required. Let the handler
    	// process this socket / event combination.
    	//无需TLS握手。让处理程序处理此套接字/事件组合。
    	handshake = 0;
    }
    
    public boolean isHandshakeComplete() {
        return true;
    }

不过当我们看一下org.apache.tomcat.util.net.NioChannel\#isHandshakeComplete方法，是不是有些滑稽。直接返回一个true,连变量都不是。这真实自己和自己玩，有意思吗？当我们看一下这个方法是否有子实现，发现真的有，不过代码也是十分简单。然而我们关注一下这个类的命名SecureNioChannel，同时看一下上面代码块的那一段注释(TLS)。想到应该是和tomcat的ssl有关。这里我们就不去深究这件事了。

//org.apache.tomcat.util.net.SecureNioChannel
    @Override
    public boolean isHandshakeComplete() {
    	return handshakeComplete;
    }

3）SelectionKey.OP\_READ和SelectionKey.OP\_WRITE

这两个值是通过handshake = socket.handshake(key.isReadable(), key.isWritable());判断的。好烦人，和上面的一样，又直接返回一个0。不过再看一下上面的注释，又和SSL相关。还是那句话，感兴趣的可以看一下。

/**
     * Performs SSL handshake hence is a no-op for the non-secure
     * implementation.
     *
     * @param read  Unused in non-secure implementation
     * @param write Unused in non-secure implementation
     * @return Always returns zero
     * @throws IOException Never for non-secure channel
     */
    public int handshake(boolean read, boolean write) throws IOException {
    	return 0;
    }

### 3.1.2 根据握手状态处理实际的业务逻辑 ###

这里我们只考虑正常的情况，及handshake=0的情况。那么我们直接来到getHandler().process(socketWrapper, event);

if (handshake == 0) {
    	SocketState state = SocketState.OPEN;
    	// Process the request from this socket
    	//处理来自此套接字的请求
    	//默认处理打开读请求
    	if (event == null) {
    		state = getHandler().process(socketWrapper, SocketEvent.OPEN_READ);
    	} else {
    		state = getHandler().process(socketWrapper, event);
    	}
    }

## 3.2 追踪getHandler().process ##

这个方法追踪还算容易，没有那么多的子类实现，所以我们一下子来到org.apache.coyote.AbstractProtocol. ConnectionHandler\#process。在这个方法中，前期主要是生成一个合适的processor（org.apache.coyote.Processor），最主要还是执行了state = processor.process(wrapper, status);

do {
    	state = processor.process(wrapper, status);
    	...
    }while(state == SocketState.UPGRADING)

## 3.3 AbstractProcessorLight\#process ##

这是一个什么方法？我们先看一下注释:

> This is a light-weight abstract processor implementation that is intended as a basis for all Processor implementations from the light-weight upgrade processors to the HTTP/AJP processors.
> 
> **译：**这是一种轻量级抽象处理器实现，旨在作为从轻量级处理器升级到HTTP / AJP等所有处理器实现的基础。

这里有一堆if-elseif-else,虽然设计的不是那么美观，但是还是有很多值得我们借鉴的。这里是根据SocketEvent的不同状态，做出不同的业务逻辑处理。按照我们正常的业务逻辑，我们来到state = service(socketWrapper);。也就是从这个方法，我们才进入本次的主题。因为从这里开始针对http协议等内容进行解析封装，最终形成request和response对象，最终交给servlet处理。

## 3.4 解析消息头 ##

根据我们一路追踪，很快来到org.apache.coyote.http11.Http11Processor\#service方法。正如上面展示的时序图，在这个方法主要完成五件事，最终完成http协议的解析。这个方法的开始是对一些变量的定义以及初始值的设置，我们无需理会，我们直接进入parseRequestLine这个方法【inputBuffer.parseRequestLine(keptAlive)】。

### 3.4.1 解析请求头 ###

这段代码很长，我们先来看一下源码是怎么描述这个方法的。

> Read the request line. This function is meant to be used during the HTTP request header parsing. Do NOT attempt to read the request body using it.
> 
> 译：解析请求行。该功能旨在用于解析HTTP请求标头，但不要尝试使用它读取请求正文。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L29ZaW5IZVpoaUd1YW5n_size_16_color_FFFFFF_t_70 1][]

上图就是请求头的主要内容。这个方法也是针对http的第一个方框中的内容逐个字符进行解析，然后获取需要的信息。限于篇幅，这里就不做详细的解释，感兴趣的可以自己尝试看一下(和request相关的一些方法，比如你可以找类似关键字(request.protocol()、request.queryString()、request.method()）等。这个方法主要完成的解析包括：method、unparseURI、requestURI、protocol。

### 3.4.2 prepareRequestProtocol ###

先看一下这个方法的一段注释:

> Process the Protocol component of the request line Need to know if this is an HTTP 0.9 request before trying to parse headers.
> 
> 译：在尝试解析请求头之前，处理请求行的协议组件，需要知道这是否是HTTP 0.9请求。

private void prepareRequestProtocol() {
    	MessageBytes protocolMB = request.protocol();
    	if (protocolMB.equals(Constants.HTTP_11)) {
    		http09 = false;
    		http11 = true;
    		protocolMB.setString(Constants.HTTP_11);
    	} else if (protocolMB.equals(Constants.HTTP_10)) {
    		http09 = false;
    		http11 = false;
    		keepAlive = false;
    		protocolMB.setString(Constants.HTTP_10);
    	} else if (protocolMB.equals("")) {
    		// HTTP/0.9
    		http09 = true;
    		http11 = false;
    		keepAlive = false;
    	} else {
    		// Unsupported protocol
    		http09 = false;
    		http11 = false;
    		// Send 505; Unsupported HTTP version
    		response.setStatus(505);
    		setErrorState(ErrorState.CLOSE_CLEAN, null);
    		if (log.isDebugEnabled()) {
    			log.debug(sm.getString("http11processor.request.prepare")+
    					  " Unsupported HTTP version \""+protocolMB+"\"");
    		}
    	}
    }

### 3.4.3 解析消息头 ###

接下来我们看一下parseHeaders。这个方法还是异常隐蔽的，他藏在一个if的判断语句中间。if (!http09 && !inputBuffer. parseHeaders())，根据&&的运算规则，如果是http09的协议，是不处理消息头的。我们简单了解一下http0.9。

> HTTP 是基于 TCP/IP 协议的应用层协议（详见《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》、《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》）。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。  
> 最早版本是1991年发布的0.9版。该版本极其简单，只有一个命令GET：  
> GET /index.html  
> 上面命令表示，TCP 连接（connection）建立后，客户端向服务器请求（request）网页index.html。  
> 协议规定，服务器只能回应HTML格式的字符串，不能回应别的格式：  
> Hello World  
> 服务器发送完毕，就关闭TCP连接。

到这里我们就明白为什么这里用&&的含义了。

当我们进入org.apache.coyote.http11.Http11InputBuffer\#parseHeaders方法。这里是一个while循环。在循环体内，主要执行status = parseHeader();方法。这里也没什么说的，主要是针对消息头做key-value的解析。

### 3.4.4 request请求的预处理 ###

针对prepareRequest方法，我们主要看一下注释。

> After reading the request headers, we have to setup the request filters.
> 
> 译：在解析完请求消息头之后，我们不得不设置过滤器。

这么处理的逻辑有些复杂，这里就不做详细说明，后期有可能会做一个专题讲解。

## 3.5 org.apache.catalina.connector.CoyoteAdapter\#service ##

在这个方法中，是对request和response做进一步的完善，同时要创建org.apache.catalina.connector.Request和org.apache.catalina.connector.Response。这两个是对org.apache.coyote.Request和org.apache.coyote.Response的进一步封装和增强。更重要的是针对http请求的所有内容，tomcat是不希望暴露给HttpServletRequest和HttpServletResponse的。所以，这里也是做了一些限制。

最终把封装好的HttpServletRequest和HttpServletResponse交给了下一个节点-StandardEngineValue。对于StandardEngine这个组件是不是很熟悉了，我们终于找到家了。

## 3.6 StandardEngineValue ##

### 3.6.1 什么是Value类 ###

细心地小伙伴可能已经发现，Tomcat针对每个组件都会有一个value对应。这个value是干什么的呢？我们先看一下源码注释。

> \#org.apache.catalina.Valve
> 
> Valve is a request processing component associated with a particular Container.  A series of Valves are generally associated with each other into a Pipeline.  The detailed contract for a Valve is included in the description of the invoke() method below.  
> HISTORICAL NOTE: The "Valve" name was assigned to this concept because a valve is what you use in a real world pipeline to control and/or modify flows through it.
> 
> 译：Valve是与特定容器关联的请求处理组件。通常将一系列阀门彼此关联到管道中。 Valve的详细执行过程包含在下面的invoke（）方法的描述中。  
> 历史记录：“阀”名称已分配给该概念，因为在现实世界的管道中您使用的是阀，用于控制和/或修改通过它的流量。

也就是说，我们是通过管道的方式进入到这个方法中的。通过上面的方法调用，我们也很容易发现这一点:

connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);

### 3.6.2 org.apache.catalina.core.StandardEngineValve\#invoke ###

我们依旧先看一下这个方法的注释:

> Select the appropriate child Host to process this request, based on the requested server name.  If no matching Host can be found, return an appropriate HTTP error.
> 
> 译：根据请求的服务器名称，选择适当的子主机以处理此请求。如果找不到匹配的主机，则返回适当的HTTP错误。

@Override
    public final void invoke(Request request, Response response)
    	throws IOException, ServletException {
    	Host host = request.getHost();
    	if (host == null) {
    		// HTTP 0.9 or HTTP 1.0 request without a host when no default host
    		// is defined.
    		// Don't overwrite an existing error
    		if (!response.isError()) {
    			response.sendError(404);
    		}
    		return;
    	}
    	if (request.isAsyncSupported()) {
    		request.setAsyncSupported(host.getPipeline().isAsyncSupported());
    	}
    	host.getPipeline().getFirst().invoke(request, response);
    }

这段代码很简单，和注释说的内容基本一致。我们关注最后一行代码，进入到下一步，StandardHostValve\#invoke。

## 3.7 org.apache.catalina.core.StandardHostValve\#invoke ##

> Select the appropriate child Context to process this request, based on the specified request URI.  If no matching Context can be found, return an appropriate HTTP error.
> 
> 译：根据指定的请求URI选择适当的子上下文来处理此请求。如果找不到匹配的上下文，则返回适当的HTTP错误。

其实这段代码和上面处理的问题差不多，直接进入context.getPipeline().getFirst().invoke(request, response);

## 3.8 org.apache.catalina.core.StandardContextValve\#invoke ##

> Select the appropriate child Wrapper to process this request, based on the specified request URI.  If no matching Wrapper can be found, return an appropriate HTTP error.

不想翻译了，无非就是没有找到合适的报错，否则继续往下进行。

## 3.9 org.apache.catalina.core.StandardWrapperValve\#invoke ##

在这个方法中，我们通过getContainer()获得StandardWrapper，然后从StandardWrapper中分配一个合适的servlet进行请求处理。这里我贴了三行不连续的代码大家可以自行搜索定位一下:

StandardWrapper wrapper = (StandardWrapper) getContainer();
    Servlet servlet = null;
    servlet = wrapper.allocate();

然而，servlet真正执行的方法还不是在StandardWrapperValve中。那是什么地方呢？

熟悉Tomcat的人会知道，在web.xml中除了配置servlet，还有一个很重要的便是过滤器。在这个方法中，将serlvet加入到过滤器链中，然后执行过滤器链。

ApplicationFilterChain filterChain = ApplicationFilterFactory.createFilterChain(request, wrapper, servlet);
    filterChain.doFilter(request.getRequest(), response.getResponse());

## 3.10 org.apache.catalina.core.ApplicationFilterChain\#doFilter ##

在这个方法中，通过执行内部的org.apache.catalina.core.ApplicationFilterChain\#internalDoFilter方法执行过滤器链和servlet方法。在internalDoFilter方法中，他主要分两部分执行。第一部分是执行过滤器链，第二部分是执行servlet。

在第一部分中，有代码filter.doFilter(request, response, this);

在第二部分中，有代码servlet.service(request, response);

这里的过滤器链和一般的过滤器不太一样，就像structs框架中，servlet就像一个夹心面包。他先逐个进入过滤器，一不小心就会被返回，当servlet执行完毕后，以栈的方式依次在出过滤器。而tomcat中的过滤器不一样，先一次性将过滤器执行完毕，然后在执行servlet.service方法。

## 3.11 DefaultServlet类 ##

这个不是所有请求都执行的servlet。但是基本思路一致。在javax.servlet.http.HttpServlet\#service(javax.servlet.http. HttpServletRequest, javax.servlet.http.HttpServletResponse)方法中，经过一系列判断，最终进入我们定义好的doGet()或者doPost方法中。后面的事我相信作为一个有多年开发经验的程序猿来说已经不成问题了。

到此位置，一个完整的Http请求从接受到处理的全过程就结束了。

[Tomcat_-http]: https://blog.csdn.net/oYinHeZhiGuang/article/details/109210654
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L29ZaW5IZVpoaUd1YW5n_size_16_color_FFFFFF_t_70]: /images/20221122/0ee7d4a8d75b43bd9462aa48d7f125c6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L29ZaW5IZVpoaUd1YW5n_size_16_color_FFFFFF_t_70 1]: /images/20221122/95506029ca034ad39f7aba7722241ba0.png