Tomcat processing HTTP request source code analysis (top)

Many open source application servers are integrated with Tomcat as Web container, and this part of the code is rarely changed for Tomcat's servlet container. In this way, the performance of these application servers depends essentially on the performance of the connector module that Tomcat handles HTTP requests. Firstly, this paper analyzes the types and usages of all connector from the application level, then analyzes the position of the connector module in the whole tomcat from the architecture, and finally makes a detailed analysis of the source code of connector. And we use Http11nioprotocol as an example to detail how Tomcat builds connector by implementing the Protocolhandler interface.

With this article, you should be able to easily integrate Tomcat as a Web container into a third-party system, and customize any high-performance HTTP connectors you want. 1 Connector Introduction types of 1.1 connector

The Connector-related classes in the Tomcat source code are in the Org.apache.coyote package, and the Connector is divided into the following categories: HTTP Connector, based on the HTTP protocol, responsible for establishing an HTTP connection. It is also divided into Bio-HTTP connector and NIO HTTP connector two, which provides non-blocking IO and long connection comet support. AJP Connector, based on the AJP protocol, AJP is specifically designed to provide a customized protocol for the communication between Tomcat and HTTP servers, providing high communication speed and efficiency. This protocol is used when integrating with the Apache server. APR HTTP Connector, implemented in C, called through JNI. The main promotion of static resources (such as HTML, images, CSS, JS, etc.) Access performance. The library is now available independently of any project. Tomcat has very strong performance after configuring Apr. configuration of 1.2 connector

The configuration for connector is located in the Conf/server.xml file. 1.2.1 BIO http/1.1 connector configuration

A typical configuration is as follows:

<connector port= "8080" protocol= "http/1.1" maxthreads= "connectiontimeout=" 20000 
= "8443"

Some other important properties are as follows: Acceptcount: Accept the maximum number of connections to request, and the default is address: Bind IP addresses, if not bound, bind any IP addresses by default allowtrace: If True, the trace will be allowed http method Compressiblemimetypes: Individual mimetype, separated by commas, such as text/html,text/xml compression: If bandwidth is limited, you can compress with gzip ConnectionTimeout: timeout, default to 60000ms (60s) Maxkeepaliverequest: The default value is MaxThreads: number of threads processing the requested connector, the default value is 200

If this is an SSL configuration, the following:

<connector port= "8181" protocol= "http/1.1" sslenabled= "true" 
    maxthreads= "*" 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 " 
    

Where Keystorefile is the certificate location, Keystorepass is the certificate password 1.2.2 NIO http/1.1 connector configuration

<connector port= "8080" protocol= "org.apache.coyote.http11.Http11NioProtocol" 
    

1.2.3 Native APR connector configurationARP is written in C/s + +, the static resources (HTML, pictures, etc.) are optimized. So to download the local library

Tcnative-1.dll and Openssl.exe, put them in the%tomcat%\bin directory.

The download address is: http://tomcat.heanet.ie/native/1.1.10/binaries/win32/in Server.xml to configure a listener, as shown below. This configuration tomcat is the default match.

<!--APR Library loader. Documentation At/docs/apr.html--> 

Configure the use of APR connector

<connector port= "8080" protocol= "org.apache.coyote.http11.Http11AprProtocol" 

maxthreads= "connectiontimeout=" "20000" redirectport= "8443" If configured successfully, start Tomcat, you will see the following information:

2 The position of connector in Tomcat 2.1 Tomcat Architecture

The

Figure 2-1 Tomcat schema server (server) is the top-level constituent element of Tomcat, all of which are contained in the server, The server's implementation class Standardserver can contain one to multiple services; The implementation class of the secondary top-level element service invokes the container (Container) interface for Standardservice, actually invoking the servlet Engine (engine), And the Standardservice class also indicates the server to which the service belongs, and the next constituent element is the container (Container), host, context, and engine (Engine) are inherited from the container interface, so they are all containers. But they have a father-son relationship, in the three types of containers, host, context, and engine (Engine), the engine is a top-level container, directly containing the host container, and the host container contains the context container, so the engine, host, and context form a parent-child relationship in size, Although they all inherit from the container interface. The connector (Connector) connects the service to the container, which, first of all, needs to be registered to a service, and its role is to forward requests from the client to the container (container), which is why it is called a connector.

Therefore, from the functional point of view of the Tomcat source code into 5 modules, they are: Jsper module: This module is responsible for JSP page parsing, JSP property verification, but also responsible for the JSP page dynamically converted to Java code and compiled into a class file. In the tomcat source code, all the source codes belonging to the Org.apache.jasper package and its child packages belong to this module; Implementation of the servlet and JSP specification module: The source code for this sub module belongs to the Javax.servlet package and its child packages, as we are very familiar with the Javax.servlet.Servlet interface, The Javax.servet.http.HttpServlet class and the Javax.servlet.jsp.HttpJspPage are located in this sub module; Catalina: This child module contains all the Java source code that starts with the Org.apache.catalina. The Sub module's task is to standardize the overall architecture of Tomcat, defining key components such as server, Service, Host, Connector, context, session, and cluster, and the implementation of these components. The composite design pattern is used in a large number of modules. At the same time, it also regulates the execution flow of events such as start-up and stop of Catalina. From the point of view of code reading, this sub module should be the focus of our reading and learning. Connectors: If the above three modules implement the Tomcat application server, then this child module is the implementation of the Web server. The so-called connector (Connector) is a bridge between the client and the application server, which receives the user's request and wraps the user request into a standard HTTP request (including the protocol name, the request header head, the request method is get or post, etc.). At the same time, the module is also in accordance with the standard HTTP protocol, responsible for sending a response page to the client, for example, when the request page is not found, connector will send the standard HTTP 404 Error response page to the client browser. Resource: This child module contains resource files, such as Server.xml and Web.xml profiles. Strictly speaking, this child module does not contain Java source code, but it is also required for Tomcat compilation operations. 2.2 Tomcat Run process

Figure 2-2 Tomcat run process

Suppose the request from the customer is: The http://localhost:8080/test/index.jsp request is sent to native port 8080, where the coyote http/1.1 that is listening for the connector gets Connector the request to the engine of the service it was in, and waited for engine's response engine to get the request localhost:8080/test/index.jsp, matching all its virtual host host The engine match to the host named localhost (even if the match is not matched, the request is given to the host, because the host is defined as the default host for the engine) localhost host gets the request/test/ index.jsp, matching all the context host it owns to the context where the path is/test (if the match is not matched, the request is addressed to the context of the path named "") path= "/test" context gets the request/ index.jsp, find the corresponding servlet context in its mapping table to the servlet with URL pattern *.jsp, corresponding to the Jspservlet class Constructs the HttpServletRequest object and the HttpServletResponse object, calling the Jspservlet Doget or Dopost method as a parameter The context returns the HttpServletResponse object after execution to the host host to return the HttpServletResponse object to the engine Engine HttpServletResponse object back to Connector Connector HttpServletResponse object back to the customer browser 3 connector source analysis Start analysis and integration of 3.1 tomcat

We know that there are two ways to start Tomcat: Double-click Bin/startup.bat Run Bin/catalina.bat

They correspond to the bootstrap and Catalina two classes, and we now only care about Catalina this class, which uses Apache digester to parse conf/ The Server.xml file generates the Tomcat component and then calls the Start method of the embedded class to start Tomcat.

So, there are two ways to integrate Tomcat: Use Tomcat's own server.xml to define an XML format to configure the Tocmat's parameters and write the parse XML again. Then use the API provided by Tomcat to generate the Tomcat component based on these XML, and finally call the embedded class's Start method to start Tomcat

Personally feel that the first way to superior, to give developers a better user experience, if the use of this, directly imitate the Catalina class method can be integrated.

Currently, Jonas uses this integration approach, the second way that JBoss, GlassFish uses the custom XML. 3.2 Connector class diagram and sequence diagram

Figure 3-1 Connector related class diagram

Figure 3-2 Connector workflow sequence diagram

From the above two figure we can get the following information: Tomcat has four kinds of containers (context, Engine, Host, wrapper), the first three common, fourth uncommon but it is also implemented the Container interface container if you want to To customize a connector, you only need to implement the Protocolhander interface , which is defined as follows:

Figure 3-3 Protocolhandler interface to be implemented when customizing connector

Tomcat implements the interface with HTTP (including bio and NIO), AJP, APR, memory four protocols (they are: Ajpaprprotocol, Ajpprotocol, Http11aprprotocol, Http11nioprotocol, Http11protocal, Jkcoyotehandler, Memoryprotocolhandler), what kind of connector to use in conf/ Server.xml, the configured implementation class is instantiated through reflection in the connector constructor:

<connector port= "8181" 
   

Workflow of 3.3 connector

Below we take http11aprprotocol as an example to illustrate the connector workflow. It delegates the work to the Nioendpoint class. Build a Socketserver in the Init method of the Nioendpoint class (of course, there will be some minor changes in the different implementation classes, for example, if it's NIO, it's built Socketserverchannel) A client's new connection request is received in the Nioendpoint.acceptor class, as shown in the following figure:

In the Nioendpoint class, there is an internal interface handle, which is defined as follows:

The handle internal interface is implemented in the Http11nioprotocol class, and the Http11nioprocessor class is invoked (the class implements the Actionhook callback interface). The Actionhook implementation class is invoked in the response class, and the action method of the response class is as follows:

In the Http11nioprocessor process implementation method, a adapter is invoked to invoke the Servler container to generate the response results.