Shulou(Shulou.com)06/03 Report--

2. The processing flow of HTTP request in Web container

The Web container runs on the computer as a process. We know that the process is the smallest unit of system resource allocation and the thread is the smallest unit of system task execution. From this point of view, the Web container is like the building or community where the recipient of the parcel lives. The logistics express system of HTTP can only deliver the parcel to the front desk of the building or the property of the community, while the front desk of the building or the property of the community does not belong to the logistics express system, just like Web container does not belong to the computer network infrastructure. The reason for this division of labor is that the network routing information is controlled by the domain name server DNS, routers and other devices, and the internal architecture information of the Web container is known only by itself. From the time the Web container receives the HTTP request to the time it is delivered to a specific application, it goes through a complex process that is helpful for day-to-day development and problem analysis. Next, brother soldier, I will accompany you to analyze the process.

There are many types of Web containers in the JAVA language domain, including Tomcat, Jetty, Resin, Websphere, Weblogic, JBoss, Glassfish, GonAS, and so on, of which Tomcat is an open source Web container maintained by Apache Software Foundation. With a market share of nearly 60%, Tomcat is by far the most popular Web container, as shown in the following figure across Web servers and Java application servers.

Let's take Tomcat as an example to look at the internal structure of the Web container. As a container in line with the JAVA Servlet standard, Tomcat is a component-based Java Web application server, and the core components are flexible and configurable. The outermost layer of Tomcat is the Catalina Servlet container, other components are configured in this top-level container according to specific format requirements, and the configuration file is in the installation directory: / conf/server.xml. Through this configuration file, we can understand the architecture of Tomcat, and the example file is as follows (take a quick look at it and analyze it later):

In configuration one, the client can access the Tomcat using the HTTP protocol through the 8080 port number. Configuration 2, the client can access Tomcat using AJP protocol through port 8009. The AJP protocol is mainly used to connect and cooperate with other HTTP servers. We will use this connector when Tomcat integrates with other HTTP servers. Configuration 3, the client can access the Tomcat using the HTTPS protocol through the 8443 port number.

There are many properties that can be configured for the definition of a connector. here are descriptions of common properties:

Address: specifies the address that the connector listens to, which defaults to all addresses, that is, 0.0.0.0. MaxThreads: the maximum number of concurrent connections is supported. The default is 200. Port: listening port. Default is 0. Protocol: the protocol used by the connector, which defaults to HTTP/1.1 and is usually defined as AJP/1.3 when defining the AJP protocol. RedirectPort: in the case of mandatory HTTPS, if HTTP is requested, it will be redirected to port 8443. ConnectionTimeout: the timeout of the connection (in milliseconds). The default is 60000, that is, 1 minute. EnableLookups: whether to query DNS through request.getRemoteHost () to get the hostname of the client. AcceptCount: sets the maximum length of the waiting queue. Typically, when all processing threads in Tomcat are busy, new requests are placed in the waiting queue. 2.1.4 Container Class component Engine

The Engine can contain multiple Host, which is the component responsible for request processing in the Service component. It receives the request from one or more Connector and processes it, encapsulates the processing result as a reply to the Connector, and finally sends it back to the external client. In the previous configuration file example, the configuration of Engine is as follows:

Where the attribute name is used for logging and error messages, and its value is guaranteed to be unique throughout the Server. The attribute defaultHost specifies the default Host name. When the Host name specified by the HTTP request does not exist, the Host specified by defaultHost is used for processing. Therefore, the value of defaultHost must match the value of the property name of some Host component in Engine.

2.1.5 Container Class component Host

Host represents a virtual host that corresponds to an entity on the computer network, that is, a domain name or IP address registered on a DNS server, such as www.abc.com or 201.187.10.21. Host can contain multiple Context internally, and each Context represents a Web application. Host is responsible for installing, deploying, starting, and ending each Web application.

When filling in the recipient address, the client identifies the server it wants to access by the hostname, and Tomcat will extract the hostname from the Host field of the HTTP request header, and then match the corresponding virtual host. If no match is found, the HTTP request is sent to the default host defaultHost. Therefore, the default host does not need to be a network name registered on the DNS server, for example: localhost. In the previous configuration example, the configuration of Host is as follows:

Where the property name specifies the name of the virtual host. The property appBase specifies the directory where the Web application is located, and the default value is webapps, which is a relative path that identifies the webapps folder under the root of the Tomcat installation. The property unpackWARs specifies whether to extract the WAR file applied by Web. If the value is true,Tomcat, the Web application will be run in the decompressed file structure; if it is false,Tomcat, the Web application will be run directly using the WAR file. The property autoDeploy specifies whether the Web application is deployed automatically.

2.1.6 Container Class component Context

Context represents a Web application running on a specific virtual host and is responsible for processing all requests for a particular Web application. Each Web application is based on either the WAR file or the corresponding file directory after the WAR file is extracted. In the previous configuration file example, we do not see the configuration of Context, because Host enables automatic deployment, Web applications do not configure static deployment in the configuration file, but are automatically deployed by Tomcat through specific rules, and Context components will be created automatically. Context uniquely identifies itself through the attribute path. Considering that the automatic deployment of Web applications has little to do with the topic of this article, I will no longer expand it, if you are interested in this content, you can find materials to do extended reading.

2.1.7 embedded class elements

In addition to the core components described earlier, Tomcat also provides Listener, GlobalNamingResources, Realm, Valve and other components, which are all embedded in the core components. We classify them as embedded components and will not repeat them considering that there is no topic involved.

2.2 Tomcat's process for processing HTTP requests

Based on the various core components described in the previous chapters, let's take a look at how Tomcat dispatches HTTP requests to specific Web applications when HTTP requests are delivered to the host where Tomcat resides:

According to the protocol type and port number, the Connector components under Service and Engine:Service are responsible for listening and receiving requests for specific protocols and ports. Therefore, when Tomcat starts, the Service component starts listening on specific ports, as in the previous configuration file example, Catalina, the Service listens on port 8080 of the HTTP protocol and port 8009 of the AJP protocol. When the HTTP request arrives at a specific port of the host network card, the Tomcat selects the Service to process the request based on the protocol type and port number, and the Engine determines. By configuring multiple Service in Server, it is possible to access different applications on the same host through different ports. Select Host based on domain name or IP address: after Service is selected, Tomcat will look in Service for a Host that matches the domain name or IP address specified in the HTTP request header to process the request. If there is no match, the default virtual host defaultHost configured in Engine is used to process the request. The context-path in the selected Context:URI based on URI specifies the Web application to be accessed by the HTTP request. When the request arrives, Tomcat will select the Web application to process the request according to the matching degree between the attribute path of Context and the context-path in URI. For example, if the path attribute of Web application spring-demo is "/ spring-demo", then the request "/ spring-demo/user/register" will be processed by spring-demo.

In the end, let's continue to string the entire processing flow by sending an HTTP request to the following address:

Http://201.187.10.21:8080/spring-demo/user/register

The client (or browser) sends a request to port 8080 of the host (201.187.10.21), which is received by the Coyote HTTP/1.1 Connector listening on that port. Connector hands the request to the Engine of its Service and waits for a response from Engine. After receiving the request, Engine extracts the host name from the header (201.187.10.21) and looks for a match among all the virtual host Host. If it does not match the virtual host with the same name, Engine passes the request to the default virtual host Host named localhost for processing. After receiving the request, the Host matches all the Context it owns according to the value "/ spring-demo" of the context-path in URI (/ spring-demo/user/register), and passes the request to the Context representing the application spring-demo for processing. Context constructs HttpServletRequest and HttpServletResponse objects, which are used as parameters to call the application spring-demo. The application completes the business logic execution, result data storage and other processes, and waits for the response data. Context receives the HttpServletResponse object returned by the application and returns it to Host. Host returns the HttpServletResponse object to Engine. Engine returns the HttpServletResponse object to Connector. Connector returns the HttpServletResponse object to the client (or browser). 2.3 Analysis of the trend of the evolution of Tomcat architecture

From the analysis of the above architecture, Tomcat, a Java Web application server, is still very powerful. It can support multiple protocols in one instance process and multiple virtual hosts at the same time. Each virtual host also supports the deployment of multiple applications, with strong scalability and flexibility. Why does it have such an architecture? This actually matches the infrastructure when Tomcat was born, when the server was dominated by minicomputers or PC servers, and lacked the virtual technology of dividing resources such as containers, and the process was the smallest unit of system resource allocation. In order to make full use of the resources on each computer, we usually have to deploy multiple applications on the same computer, but the complexity of running multiple Tomcat instances on one computer is very high, so it is better to deploy multiple Web applications in the same Tomcat instance, which is more convenient in configuring operations and other management.

Under this architecture, Tomcat needs to go through the above complex process to process HTTP requests, which once again confirms what I firmly believe in: there is no absolutely good or bad architecture, and the architecture that matches the business scenario at that time is a good architecture! With the development of Internet business and the rise of cloud computing, in order to better manage large-scale application clusters, we need to use containers and other virtualization technologies to divide large-scale granular resources into smaller, standard units. Only one Web container is installed in each container, and only one application is deployed in each Web container. We can adopt the automatic operation of cloud computing under standardization.

Following this trend, the architecture of Web containers does not need to be so complex, and its value will continue to weaken. In the past, Tomcat needs to be installed separately, and applications are later deployed to Tomcat. But at present, in the development mode of Spring Boot, Tomcat uses Starter as an embedded Web container, which no longer requires independent installation and deployment. In the trend of becoming more and more standard, Tomcat basically adopts the default configuration, and users basically don't have to pay too much attention to it. The reason for analyzing and understanding it is what the veteran said at the beginning: know what it is, know why.

This evolution process is like the change of housing style, the population density of ancient cities is not so large, each family is a bungalow with a single courtyard. With the continuous influx of modern population into the city, the earlier residential space utilization rate is too low to support the rapid growth of living demand, at this time, high-rise buildings came into being, each building has multiple floors, each floor is divided into multiple houses, each house lives a family, the architecture of Tomcat is similar to this kind of high-rise building. However, the population of the modern city is still growing, and the earlier high-rise buildings are also unable to meet the living needs, lack of standardization, lack of property management, incomplete surrounding facilities, and space utilization still needs to be improved. in this case, the real estate community was born, standardization has been improved, but also supporting property management, which is similar to cloud computing.

The main value of this article is to help you sort out the end-to-end framework of the whole process, that is, the global perspective or God perspective. With this framework, we can according to our own needs to find clues to find the relevant node information to study, so as not to fall into the details can not find the direction. Of course, considering that our work and study conditions are different and the problems we usually encounter are also different, this article can not cover the problems encountered by everyone. You are welcome to leave messages and questions, and you are welcome to follow my blog or the official name "IT veteran brother" to communicate and interact. I will try my best to answer your questions as soon as possible. Thank you!

The index of other articles in this series is as follows:

Diagram Spring:HTTP request processing flow and mechanism [1] Diagram Spring:HTTP request processing flow and mechanism [3] Diagram Spring:HTTP request processing flow and mechanism [4] Diagram Spring:HTTP request processing flow and mechanism [5]

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.