Detailed explanation of Tomcat core components and application architecture

What is a web container?

Let's first briefly review the development history of Web technology, which can help you understand the origin of Web containers.

Early Web applications were mainly used to browse static pages such as news. HTTP servers (such as Apache and Nginx) returned static HTML to the browser, which was responsible for parsing the HTML and presenting the results to the user.

With the development of the Internet, we are no longer satisfied with just browsing static pages. We also hope to obtain dynamic results through some interactive operations. Therefore, we need some extension mechanisms to enable the HTTP server to call the server program.

So Sun launched the Servlet technology. You can simply think of Servlet as a Java applet running on the server, but Servlet does not have a main method and cannot run independently, so it must be deployed in a Servlet container, which instantiates and calls the Servlet.

And Tomcat is a Servlet container. For ease of use, they also have the function of HTTP server, so Tomcat is an "HTTP server + Servlet container", we also call them Web containers.

The Nature of HTTP

HTTP protocol is the data transmission protocol between browsers and servers. As an application layer protocol, HTTP is based on the TCP/IP protocol to transmit data (HTML files, images, query results, etc.). The HTTP protocol does not involve packet transmission and mainly specifies the communication format between the client and the server.

If a browser needs to obtain an HTML text from a remote HTTP server, during this process, the browser actually has to do two things.

• Establish a Socket connection with the server.
• Generate request data and send it through Socket.

HTTP request response example

The user enters the username and password on the login page and clicks Login. The browser sends the following HTTP request:

HTTP request data consists of three parts: request line, request header, and request body . When the HTTP request data reaches Tomcat, Tomcat will parse the HTTP request data byte stream into a Request object, which encapsulates all HTTP request information. Tomcat then passes the Request object to the Web application for processing, and obtains a Response object after processing. Tomcat converts the Response object into HTTP format response data and sends it to the browser.

HTTP response also consists of three parts: status line, response header, and message body . Similarly, I also use the response of the GeekTime login request as an example.

Cookies and Sessions

We know that one of the characteristics of HTTP protocol is that it is stateless, and there is no relationship between requests. This will lead to an embarrassing problem: the web application does not know who you are. Therefore, the HTTP protocol needs a technology to establish a connection between requests, and the server needs to know which user the request comes from, so Cookie technology appeared.

Cookie is a request header of HTTP message . Web application can store user identification information or other information (user name, etc.) in Cookie. After the user is authenticated, each HTTP request message contains a cookie, so that the server can read the cookie request header to know who the user is. A cookie is essentially a file stored locally on the user's computer that contains information that needs to be passed in each request.

Since Cookies are stored locally in plain text and often contain user information, this poses a huge security risk. The emergence of Session solves this problem. Session can be understood as a storage space opened up on the server side, which saves the user's status. User information is stored on the server side in the form of Session . When a user request comes in, the server can match the user's request with the user's Session. So how does Session correspond to the request? The answer is through cookies. The browser fills a field such as Session ID in the cookie to identify the request.

The specific working process is as follows: when the server creates a session, it will generate a unique session ID for the session. When the browser sends a request again, it will carry this session ID. After receiving the request, the server will find the corresponding session based on the session ID. After finding the session, you can get or add content in the session. These contents will only be saved in the server, and only the Session ID will be sent to the client. This is relatively safe and saves network traffic because there is no need to store a large amount of user information in the Cookie.

So when and where is the Session created? Of course, it is created during the execution of the server-side program. Applications implemented in different languages ​​have different methods of creating Sessions. In Java, it is created by the Web container (such as Tomcat) when the Web application calls the getSession method of HttpServletRequest.

Tomcat's Session Manager provides a variety of persistence solutions to store Sessions, usually using high-performance storage methods such as Redis, and preventing single points of failure through cluster deployment, thereby improving high availability. At the same time, the Session has an expiration time, so Tomcat will start a background thread to poll regularly, and if the Session expires, it will be invalidated.

Servlet Specification

How does the HTTP server know which method of which Java class to call? The most direct approach is to write a lot of if-else logic in the HTTP server code: if it is request A, call the M1 method of class X; if it is request B, call the M2 method of class Y. But there are obvious problems with this, because the HTTP server code is coupled with the business logic. If a new business method is added, the HTTP server code must be changed.

So how do we solve this problem? We know that interface-oriented programming is the magic weapon to solve the coupling problem, so a group of people defined an interface, and various business classes must implement this interface. This interface is called the Servlet interface. Sometimes we also call the business class that implements the Servlet interface Servlet.

But there is still a problem here. For a specific request, how does the HTTP server know which Servlet to handle it? Who instantiates the Servlet? Obviously, the HTTP server is not suitable for this task, otherwise it will be coupled with the business class.

So, the same group of people invented the Servlet container, which is used to load and manage business classes. The HTTP server does not deal directly with the business class, but instead hands the request to the Servlet container for processing. The Servlet container forwards the request to a specific Servlet. If the Servlet has not been created, it loads and instantiates the Servlet, and then calls the interface method of the Servlet. Therefore, the Servlet interface is actually the interface between the Servlet container and the specific business class. Let's use a picture to deepen our understanding.

The entire set of specifications for the Servlet interface and Servlet container is called the Servlet specification. Both Tomcat and Jetty implement Servlet containers according to the requirements of the Servlet specification, and they also have the functions of HTTP servers. As a Java programmer, if we want to implement new business functions, we only need to implement a Servlet and register it in Tomcat (Servlet container), and Tomcat will take care of the rest for us.

The Servlet interface defines the following five methods:

public interface Servlet {
    void init(ServletConfig config) throws ServletException;
    
    ServletConfig getServletConfig();
    
    void service(ServletRequest req, ServletResponse res) throws ServletException, IOException;
    
    String getServletInfo();
    
    void destroy();
}

The most important one is the service method, where the specific business class implements the processing logic. This method takes two parameters: ServletRequest and ServletResponse. ServletRequest is used to encapsulate request information, and ServletResponse is used to encapsulate response information, so these two classes are essentially encapsulations of communication protocols.

The requests and responses in the HTTP protocol correspond to the two classes HttpServletRequest and HttpServletResponse. You can use HttpServletRequest to get all request-related information, including request path, cookies, HTTP headers, request parameters, etc. In addition, we can also create and obtain Session through HttpServletRequest. The HttpServletResponse is used to encapsulate HTTP responses.

You can see that there are two methods related to the life cycle in the interface: init and destroy. This is a thoughtful design. The Servlet container calls the init method when loading the Servlet class and calls the destroy method when unloading it. We may initialize some resources in the init method and release these resources in the destroy method. For example, the DispatcherServlet in Spring MVC creates its own Spring container in the init method.

You will also notice the ServletConfig class. The role of ServletConfig is to encapsulate the initialization parameters of the Servlet. You can configure parameters for the Servlet in web.xml and get these parameters through the getServletConfig method in the program.

We know that where there is an interface there is generally an abstract class, which is used to implement the interface and encapsulate common logic. Therefore, the Servlet specification provides the GenericServlet abstract class, which we can implement by extending it. Although the Servlet specification does not care about the communication protocol, most Servlets are processed in the HTTP environment. Therefore, the Servet specification also provides HttpServlet to inherit GenericServlet and add HTTP features. In this way, we implement our own Servlet by inheriting the HttpServlet class. We only need to rewrite two methods: doGet and doPost.

Servlet Container

When a client requests a resource, the HTTP server will encapsulate the client's request information in a ServletRequest object, and then call the service method of the Servlet container. After the Servlet container receives the request, it will find the corresponding Servlet based on the mapping relationship between the requested URL and the Servlet. If the Servlet has not been loaded, it will use the reflection mechanism to create the Servlet and call the Servlet's init method to complete the initialization. Then, it will call the Servlet's service method to process the request and return the ServletResponse object to the HTTP server. The HTTP server will send the response to the client.

Web Application

The Servlet container will instantiate and call the Servlet, so how is the Servlet registered in the Servlet container? Generally speaking, we deploy Servlets as Web applications. According to the Servlet specification, Web applications have a certain directory structure, in which the Servlet class files, configuration files, and static resources are placed. The Servlet container can find and load the Servlet by reading the configuration file. The directory structure of a web application is probably as follows:

|-MyWebApp
      | - WEB-INF/web.xml -- configuration file, used to configure Servlet, etc. | - WEB-INF/lib/ -- stores various JAR packages required for Web applications | - WEB-INF/classes/ -- stores your application classes, such as Servlet classes | - META-INF/ -- directory stores some project information

The Servlet specification defines the ServletContext interface to correspond to a Web application. After the Web application is deployed, the Servlet container loads the Web application when it starts and creates a unique ServletContext object for each Web application. You can think of ServletContext as a global object. A Web application may have multiple Servlets, which can share data through the global ServletContext. These data include the initialization parameters of the Web application, file resources under the Web application directory, and so on. Since ServletContext holds all Servlet instances, you can also use it to forward Servlet requests.

Extension Mechanism

After the introduction of the Servlet specification, you don't need to worry about Socket network communication, HTTP protocol, or how your business classes are instantiated and called, because these are standardized by the Servlet specification. You only need to care about how to implement your business logic. This is a good thing for programmers, but it also has an inconvenient side. The so-called standard means that everyone must abide by it, and it will be the same. However, if this standard cannot meet the personalized needs of your business, there will be a problem. Therefore, when designing a standard or a middleware, you must fully consider scalability. The Servlet specification provides two extension mechanisms: Filter and Listener .

Filter is a filter. This interface allows you to perform some unified customized processing on requests and responses. For example, you can limit access based on the frequency of requests, or modify the response content based on different countries and regions. The working principle of the filter is as follows: After the Web application is deployed, the Servlet container needs to instantiate the Filter and link the Filter into a FilterChain. When a request comes in, get the first Filter and call the doFilter method, which is responsible for calling the next Filter in this FilterChain.

Listener is another extension mechanism. When a Web application runs in a Servlet container, various events will continue to occur inside the Servlet container, such as the start and stop of the Web application, the arrival of user requests, etc. The Servlet container provides some default listeners to listen to these events. When an event occurs, the Servlet container is responsible for calling the listener method. Of course, you can define your own listeners to listen to the events you are interested in and configure the listeners in web.xml. For example, Spring implements its own listener to listen to the startup event of ServletContext. The purpose is to create and initialize the global Spring container when the Servlet container starts.

Tomcat download address: https://tomcat.apache.org/download-80.cgi

/bin: Stores script files for starting and shutting down Tomcat on Windows or Linux platforms.
/conf: Stores various global configuration files of Tomcat, the most important of which is server.xml.
/lib: Stores JAR files that are accessible to Tomcat and all Web applications.
/logs: stores log files generated when Tomcat is executed.
/work: stores the Class files generated after JSP compilation.
/webapps: Tomcat's Web application directory. By default, Web applications are placed in this directory.

Open the Tomcat log directory, which is the logs directory under the Tomcat installation directory. Tomcat's log information is divided into two categories: one is the operation log, which mainly records some information during the operation, especially some abnormal error log information; the other is the access log, which records the access time, IP address, access path and other related information.

• catalina.***.log mainly records the information of Tomcat startup process. In this file, you can see the startup JVM parameters and operating system log information.
• catalina.out is Tomcat's standard output (stdout) and standard error (stderr), which is specified in Tomcat's startup script. If it is not modified, stdout and stderr will be redirected here. So in this file you can see the information we printed in the MyServlet.java program
• localhost.**.log mainly records unhandled exceptions encountered by the Web application during the initialization process, which will be captured by Tomcat and output to this log file.
• localhost_access_log.**.txt stores the request log for accessing Tomcat, including the IP address, request path, time, request protocol, status code and other information.
• manager.***.log/host-manager.***.log stores the log information of Tomcat's built-in Manager project.

summary:

1. Understanding Tomcat's core components
2. Detailed explanation of server.xml configuration

1. Understanding Tomcat components

Knowledge points:

1. Tomcat Architecture Description
2. Detailed introduction to Tomcat components and relationships
3. Tomcat startup parameter description
4. Tomcat Architecture Description

Tomcat is a JAVA-based WEB container that implements the Servlet and jsp specifications in JAVA EE. Unlike the Nginx apache server, it is generally used for dynamic request processing. The architecture is designed in a component-oriented way. That is, the overall function is completed by assembling components. In addition, each component can be replaced to ensure flexibility.

2.Tomcat components and relationships

Server and Service
Connector
HTTP 1.1
SSL https
AJP (Apache JServ Protocol) Apache private protocol, used for Apache reverse proxy Tomcat
Container
Engine enginecatalina
Host virtual machine distributes requests based on domain name
Context isolates each WEB application. Each Context's ClassLoader is independent.
Component
Manager
logger
loader
pipeline
valve (valve in a pipe)

2. Detailed explanation of Tomcat server.xml configuration

server

root element: top-level configuration of server Main attributes: port: port number to execute shutdown command shutdown: shutdown command

Demonstrate the usage of shutdown#Based on telent, execute the SHUTDOWN command to shut down (must be capitalized) telnet 127.0.0.1 8005 SHUTDOWN

service

Service: Combine multiple connectors and an Engine into one service. You can configure multiple services.

Connector

Connector: used to receive connections under a specified protocol and assign them to a unique Engine for processing. Primary Attributes:

• protocol The listening protocol, the default is http/1.1
• port specifies the port number to be created on the server side
• minSpareThreads The number of threads created when the server starts to handle requests
• maxThreads The maximum number of threads that can be created to process requests
• enableLookups If true, you can get the actual host name of the remote client by calling request.getRemoteHost() to perform a DNS query. If false, no DNS query is performed, but its IP address is returned instead.
• redirectPort specifies the port number to which the server will redirect after receiving an SSL transport request while processing an http request
• acceptCount specifies the number of requests that can be placed in the processing queue when all available threads for processing requests are used. Requests exceeding this number will not be processed.
• connectionTimeout specifies the timeout period (in milliseconds)
• SSLEnabled Whether to enable SSL verification. It needs to be enabled when accessing via Https. Generate a certificate: keytool -genkey -v -alias testKey -keyalg RSA -validity 3650 -keystore D:\test.keystore
• [ ] Demonstration of configuring multiple Connectors

<Connector port="8860" protocol="org.apache.coyote.http11.Http11NioProtocol"
                connectionTimeout="20000"
                redirectPort="8862"
                URIEncoding="UTF-8"
                useBodyEncodingForURI="true"
                compression="on" compressionMinSize="2048"
compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,application/x-json,application/json,application/x-javascript"
                maxThreads="1024" minSpareThreads="200"
                acceptCount="800"
                maxConnections="10000"
                enableLookups="false"
        />

Engine

Engine: The executor used to process the connection. The default engine is catalina. Only one Engine can be configured in a service. Main attributes: name engine name defaultHost default host

Host

Virtual Machine: Matches to a specified virtual machine based on the domain name. Similar to the server in nginx, the default virtual machine is localhost. Main properties:

Demonstration of configuring multiple hosts

<Host name="www.wukong.com" appBase="/usr/www/wukong" unpackWARs="true" autoDeploy="true"> 
	<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="www.wukong.com.access_log" 
			suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b" /> 
</Host>

Context

Application context: Multiple Contexts can be configured under a host, and each Context has its own independent classPath. Isolate from each other to avoid ClassPath conflicts. Primary Attributes:

Demonstration of configuring multiple Contexts

<Context path="/testweb" docBase="testweb.war" reloadbale="true"/>

Valve : can be understood as

The specific configuration of the filter is based on the subclass of the specific Valve interface. The following is a Valve access log

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="www.wukong.com.access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b" />

3. Tomcat deployment script writing

Tomcat startup parameter description

What is the process of starting Tomcat?

1. Copy the WAR file to the Tomcat webapp directory.
2. Execute the startut.bat script to start.
3. During the startup process, the war package will be automatically decompressed and loaded.

But when we start a WEB project in Eclipse or idea, do we also unzip the War package into the webapps directory? Obviously not. The real practice is to create a deployment directory outside the Tomcat program file, which is also done in a general production environment: the Tomcat program directory and the deployment directory are separated. We only need to specify the CATALINA_HOME and CATALINA_BASE parameters at startup to achieve this.

| Startup parameters| Description | |:----|:----| | JAVA_OPTS | JVM startup parameters, set memory encoding, etc. -Xms100m -Xmx200m -Dfile.encoding=UTF-8 | | JAVA_HOME | Specify the jdk directory. If not set, find it from the java environment variable. | | CATALINA_HOME | Tomcat program root directory | | CATALINA_BASE | Application deployment directory, default is $CATALINA_HOME | | CATALINA_OUT | Application log output directory: default is $CATALINA_BASE/log | | CATALINA_TMPDIR | Application temporary directory: default: $CATALINA_BASE/temp |

You can write a script to implement custom configuration:

ln -s /home/wukong/apache-tomcat-8.5.56 apache-tomcat

Update startup scripts

#!/bin/bash
 export JAVA_OPTS="-Xms100m -Xmx200m"
export CATALINA_HOME=/home/wukong/apache-tomcat
export CATALINA_BASE="`pwd`"
 
case $1 in
        start)
        $CATALINA_HOME/bin/catalina.sh start
                echo start success!!
        ;;
        stop)
                $CATALINA_HOME/bin/catalina.sh stop
                echo stop success!!
        ;;
        restart)
        $CATALINA_HOME/bin/catalina.sh stop
                echo stop success!!
                sleep 3
        $CATALINA_HOME/bin/catalina.sh start
        echo start success!!
        ;;
        version)
        $CATALINA_HOME/bin/catalina.sh version
        ;;
        configtest)
        $CATALINA_HOME/bin/catalina.sh configtest
        ;;
        esac
exit 0

docker start tomcat

docker run -id --name=test_tomcat -e JAVA_OPTS='-Xmx128m' -p 8888:8080 -v /usr/local/tuling-project/tomcat-test/webapps:/usr/local/tomcat/webapps -v /usr/local/tuling-project/tomcat-test/logs:/usr/local/tomcat/logs -v /usr/local/tuling-project/tomcat-test/conf:/usr/local/tomcat/conf --privileged=true tomcat:8

Source code build

Download address: https://tomcat.apache.org/download-80.cgi

Configuration

1. Unzip the source code apache-tomcat-8.5.57-src

2. Add pom file in the apache-tomcat-8.5.57-src directory

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.apache.tomcat</groupId>
    <artifactId>Tomcat8.0</artifactId>
    <name>Tomcat8.0</name>
    <version>8.0</version>
 
    <build>
        <finalName>Tomcat8.0</finalName>
        <sourceDirectory>java</sourceDirectory>
        <testSourceDirectory>test</testSourceDirectory>
        <resources>
            <resource>
                <directory>java</directory>
            </resource>
        </resources>
        <testResources>
            <testResource>
                <directory>test</directory>
            </testResource>
        </testResources>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3</version>
                <configuration>
                    <encoding>UTF-8</encoding>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
 
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>3.4</version>
        </dependency>
        <dependency>
            <groupId>ant</groupId>
            <artifactId>ant</artifactId>
            <version>1.7.0</version>
        </dependency>
        <dependency>
            <groupId>wsdl4j</groupId>
            <artifactId>wsdl4j</artifactId>
            <version>1.6.2</version>
        </dependency>
        <dependency>
            <groupId>javax.xml</groupId>
            <artifactId>jaxrpc</artifactId>
            <version>1.1</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.jdt.core.compiler</groupId>
            <artifactId>ecj</artifactId>
            <version>4.5.1</version>
        </dependency>
 
    </dependencies>
</project>

3. Create a new catalina-home directory in the same directory as apache-tomcat-8.5.57-src and ensure that the files under the directory are as follows

Note : If there is one in the above folder apache-tomcat-8.5.57-src, just cut it, if not, create a new one, bin conf webapps should be cut from apache-tomcat-8.5.57-src

4.Introduce the idea into the project

File->Open Select the unzipped C:\Users\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-src

Configuration startup

MainClass: org.apache.catalina.startup.BootstrapVmOptions: -Dcatalina.home=C:\Users\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-src\catalina-home

Startup error

TestCookieFilter reports an error: Cannot find this class CookieFilter

Solution:

1. Delete: TestCookieFilter

After startup, access localhost:8080 and report org.apache.jasper.JasperException: java.lang.NullPointerException

Solution:

org.apache.catalina.startup.Bootstrap add code block

{
        JasperInitializer initializer = new JasperInitializer();
         }

The above is the detailed content of the detailed explanation of Tomcat core components and application architecture. For more information about Tomcat core components and application architecture, please pay attention to other related articles on 123WORDPRESS.COM!