Tomcat-related interview questions are not likely to appear. Because of this, many people ignore the mastery of Tomcat-related skills. This time, we sorted out the system architecture related to Tomcat, introduced the relationship between Server, Service, Connector and Container, and the functions of each module. We can say that we have mastered these several, and you won’t have any questions about Tomcat.

In addition, during the interview, you should consciously or unconsciously refer to Tomcat, such as the common Spring MVC execution process, a complete URL call link, these related topics you can go to Tomcat processing request process to say! If you have mastered Tomcat, your interviewer will admire you!

What you should know after this lesson:

  • The relationship between Server, Service, Connector, and Container, and their main function points;

  • The overall architecture of Tomcat execution, how requests are processed step by step;

  • Engine, Host, Context, Wrapper concepts;

  • How the Container handles requests;

  • Related design patterns used by Tomcat;

First, Tomcat top-level architecture

As the saying goes, when you stand on the shoulders of giants to see the world, you should first have an overview of the whole, then break down the parts one by one, and finally form ideas and understand the details. Tomcat has a complex structure, but it is very modular. Only when you find the most core module of Tomcat, can you easily solve the problems. Understanding the overall architecture of Tomcat is essential for further understanding of Tomcat!

First, the top-level structure of Tomcat (Figure A) is shown as follows:

The topmost container in Tomcat is Server, which represents the entire Server. As shown in the figure above, a Server can contain at least one Service to provide specific services.

A Service consists of two main parts: Connector and Container. As you can see from the figure above, these two components are at the heart of Tomcat, and their roles are as follows:

1. Connector is used to handle connection-related matters, and provide Socket and Request and Response related transformation;

2. Container encapsulates and manages servlets and handles Request requests.

A Tomcat has only one Server. A Server can contain multiple Services, and a Service has only one Container, but it can have multiple Connectors. This is because a Service can have multiple connections, for example, providing Http and Https links simultaneously. It can also provide connections to different ports of the same protocol, as shown below (Engine, Host, Context) :

Multiple connectors and a Container form a Service. With a Service, it can provide external services. However, a Service needs a living environment. So the entire Tomcat life cycle is controlled by the Server.

In addition, the above inclusion or parent-child relationship can be seen in the server. XML configuration file in the conf directory of Tomcat. The following image shows a complete server. XML configuration file with the comments removed (Tomcat version 8.0).

Detailed configuration files can be viewed on the Tomcat website:

Tomcat.apache.org/tomcat-8.0-…

The configuration file above can also be better understood by the following structure diagram:

The port number set on the Server label is 8005. Shutdown = “shutdown” means that the shutdown command is listened on port 8005. If the command is received, Tomcat is shutdown. A Server has one Service. You can also configure multiple services. The content on the left of a Service belongs to a Container, and the Connector is under a Service.

Ii. Summary of Tomcat top-level Architecture

(1) Tomcat has only one Server. A Server can have multiple services, and a Service can have multiple Connectors and a Container. (2) Server controls the life and death of Tomcat; (4) Service is provided to the outside world. (5) Connector is used to accept requests and encapsulate requests into Request and Response for specific processing; (6) Container encapsulates and manages servlets and processes request requests.

Knowing the hierarchical architecture of Tomcat as well as the relationships and functions among components, Server and Service are far away from us for most developers, and most of the configuration content in our development belongs to Connector and Container. So let’s talk about Connector and Container.

3. The delicate relationship between Connector and Container

From the above, we can roughly know that after a Request is sent to Tomcat, it will first go through Service and then be handed to our Connector. The Connector is used to receive the Request and encapsulate the received Request into Request and Response for specific processing. After the Request and Response are wrapped, they are sent to the Container for processing. After the Container processes the Request, the Container sends the Request back to the Connector. Finally, the Connector sends the processing result back to the client through the Socket.

At the bottom of the Connector layer, the Socket is used for connection. Request and Response are wrapped in HTTP protocol, so the Connector needs to implement both TCP/IP and HTTP protocol!

Tomcat needs to receive the request first. To receive the request, we first need to look at the Connector!

4. Analysis of Connector architecture

The Connector accepts and encapsulates a Request into a Request and a Response, and then sends the Request to the Container for processing. After the Container processes the Request, the Connector returns the Request to the client.

Therefore, Connector can be divided into four aspects:

(1) How does Connector accept requests?

(2) How to encapsulate the Request into Request and Response?

(3) How can the Request and Response after encapsulation be delivered to the Container for processing?

(4) How to send the Container to Connector and return it to the client after processing the Container?

First take a look at the structure diagram of Connector (Figure B), as shown below:

A Connector uses a ProtocolHandler to handle requests. Different protocolHandlers represent different types of connections, such as: Http11Protocol uses the normal Socket to connect, Http11NioProtocol uses the NioSocket to connect.

The ProtocolHandler consists of three components: Endpoint, Processor, and Adapter.

(1) The Endpoint processes the network connection of the underlying Socket. The Processor encapsulates the Socket received by the Endpoint into a Request, and the Adapter sends the Request to the Container for processing.

(2) Endpoint processes the underlying Socket network connection, so the Endpoint is used to implement the TCP/IP protocol, while the Processor is used to implement the HTTP protocol. The Adapter ADAPTS the request to the Servlet container for specific processing.

(3) The Endpoint abstraction implements the Acceptor and AsyncTimeout internal classes defined in AbstractEndpoint and a Handler interface. Acceptor is used to listen for requests, AsyncTimeout is used to check the timeout of asynchronous requests, and Handler is used to process the received Socket and internally invoke the Processor for processing.

By now, we should be able to answer questions (1), (2), and (3) easily, but (4) we still don’t know. How does the Container process and return the result to the Connector after processing?

5. Container architecture analysis

Container is used to encapsulate and manage servlets and process Request requests. The Connector contains four sub-containers as shown in Figure C:

The functions of the four sub-containers are as follows:

(1) Engine: an Engine used to manage multiple sites. A Service can have at most one Engine.

(2) Host: represents a site, can also be called a virtual Host, by configuring the Host can add site;

(3) Context: represents an application, corresponding to a set of programs normally developed, or a WEB-INF directory with the following web.xml file;

(4) Wrapper: Each Wrapper encapsulates a Servlet;

Find a Tomcat file directory for comparison, as shown below:

image

The difference between Context and Host is that Context represents an application. In our Tomcat default configuration, each folder directory under Webapps is a Context. The ROOT directory holds the main application and the other directories hold the child applications. The entire Webapps is a Host site.

When you access the Context, you can use the domain name to access the Context. www.ledouit.com, if it is a Host (webapps) under other applications, you can use www.ledouit.com/docs to access, of course, the default specified ROOT application (ROOT) can be set, but the default main application of the Host site is in the ROOT directory.

We know what a Container is, but we still don’t know how the Container is processed and how the processing results are returned to the Connector. Don’t worry! Here’s how the Container works!

How does the Container handle requests

Container processing requests are handled using the Pipeline-Valve Pipeline! (Valve means Valve)

The pipeline-valve responsibility chain mode refers to that in the process of a request processing, there are many processors to process the request in turn, and each processor is responsible for its own processing. After processing, the processed request will be returned, and the next processor will continue processing.

But! The responsibility chain model used by Pipeline-Valve is a little different from the normal responsibility chain model! There are two main differences:

(1) Each Pipeline has a specific Valve, and is the last execution of the Pipeline, this Valve is called BaseValve, BaseValve is not deleted;

(2) In the BaseValve of the pipe of the upper container, the pipe of the lower container is called.

We know that Container contains four subcontainers, and the corresponding BaseValve of these four subcontainers is respectively in: StandardEngineValve, StandardHostValve, StandardContextValve, StandardWrapperValve.

The processing flow chart of Pipeline is as follows (Figure D) :

(1) After receiving the request, the Connector will first call the Pipeline of the top-level container for processing. The Pipeline of the top-level container here is EnginePipeline (Engine’s Pipeline).

EngineValve1 / EngineValve2 / StandardEngineValve/Host/EngineValve2 Then Host HostValve1, HostValve2, etc., and StandardHostValve is executed, then Context pipes and Wrapper pipes are called, and StandardWrapperValve is executed.

(3) When executed to StandardWrapperValve, FilterChain will be created in StandardWrapperValve and its doFilter method will be called to process the request. The FilterChain contains the Filter and Servlet configured to match the request. The doFilter method calls the doFilter method of all the filters and the service method of the Servlet in turn, and the request is processed!

(4) When all the pipeline-Valve processes are complete and the specific request is processed, the result can be returned to the Connector, which will return the result to the client through the Socket.

Seven,

So far, we have had A general understanding of the overall architecture of Tomcat. From Figures A, B, C, and D, we can see the basic elements and functions of each component. We should have an outline in our mind! If you were asked to talk briefly about Tomcat during your interview, would you be able to blurt out the above? Finally, I compiled a Map of Tomcat knowledge system:

If you’re interested in technology, you can join my private group
Welcome to my home page into my crowd [click to enter my home page]Exchange and learn together!

This interviewer will wow you when you can just blurt out any point in the picture.