"Go" article to understand Web server, application server, Web container and reverse proxy
We know that people of different colors have a big difference in appearance, and twins are difficult to identify. The interesting thing is that the Web server/web container/web Application Server/reverse proxy is a bit like a four-cell fetus, often appearing together on the network. This article will take readers to how to distinguish the four similar concepts.
This article outlines:
I. Web server concepts and fundamentals
1. History of Web server
2. How the Web server works
II. Web application container concepts and fundamentals
1. The origin of the Web application container
2. How the Web application container works
III. Web Application Server Concepts and fundamentals
Four, reverse proxy concept and basic principle
1, reverse proxy basic concept
2, reverse proxy basic working principle
V. Summary
I. Web server concepts and Fundamentals
1. History of Web server
In 1989, the father of the Internet, Berners-lee, proposed a new project to his employer, CERN, to ease the exchange of information between scientists by using hypertext systems. The project resulted in the development of two programmes in Berners-lee in 1990 years:
A browser named WorldWideWeb.
The world's first Web server, later known as CERN httpd, runs on NeXTSTEP
During the period from 1991 to 1994, the simplicity and effectiveness of the early technologies used to surf and exchange data through the World Wide Web helped to migrate them to many different operating systems and to scientific organizations and universities, and then to the industry.
In 1994, Berners-lee decided to form the World Wide Web Consortium to manage the further development of many of the technologies involved (http,html, etc.) through a standardized process. This is the server:
The main function of a Web server is to store, process, and deliver Web pages to customers. Communication between the client and the server is done using Hypertext Transfer Protocol (HTTP). The most common type of page delivered is an HTML document that, in addition to the text content, may contain images, stylesheets, and scripts.
A user agent, usually a Web browser or web crawler, that, by initiating an HTTP request to obtain server resources, the server returns the resource on request or responds to an error message for some reason. This resource is typically a real file on server secondary storage, but this is not necessarily the case, depending on how the Web server is implemented.
Although the main function is to provide content, the full implementation of HTTP also includes how the content is received from the client. This feature is used to submit Web forms, including uploading files. Many common Web servers also support server-side scripting using Active Server Pages (ASP), PHP, or other scripting languages. This means that the behavior of the Web server can be scripted in a separate file, while the actual server software remains intact. Typically, this function is used to dynamically generate HTML documents ("instant") instead of returning static documents. The former is mainly used to retrieve or modify information from the database. The latter is usually much faster and more easily cached, but does not provide dynamic content.
Web servers are not only used for world Wide Web services. They can also be embedded in devices such as printers, routers, network cameras, and only serve local networks. The Web server can then be used as part of a system for monitoring or managing the discussed devices. This usually means that no additional software needs to be installed on the client computer because only one web browser is required (most operating systems are now included).
2. How the Web server works
The HTTP protocol is based on the TCP protocol and is an application-layer protocol for user agents and Web servers to communicate. Web servers usually work in a single-answer way:
When a user initiates a resource request on the user agent, the requested content includes, but is not limited to: Specifying a unique identifier URI for the resource, indicating the type of action (Get/post/delete/put ... )
The user agent resolves the user input URI and obtains the target domain name from the DNS server. If an IP address is specified in the URI, this does not require this step.
If the session with the server is not yet established, a TCP connection is established and HTTP negotiation is completed (to determine the acceptable processing methods, including protocol version, encryption, content format, and so on).
The user agent encapsulates the request content into an HTTP packet sent to the server.
The server receives the resource request and unpack and process it in a previously negotiated manner.
The resource requested by the server is encapsulated into an HTTP packet and returned to the user agent.
Next, focus on how the server side works.
The server listens on a port (typically the default is port 8080, the user can set up additional ports) to establish a connection to the user agent. Once the connection is established, subsequent HTTP requests from the user agent are no longer required to enter the listening module.
Here are the main three things: 1. Gets the HTTP request message from the TCP message. 2. According to the consultation with the user agent decryption, decompression, security processing and so on. 3. According to the server's own configuration for security processing, establish session state and so on.
Resolves URL strings and actions to determine the resources of a user agent request, routed to a static resource processing module or a dynamic resource processing module based on a matching rule (usually based on a regular expression + suffix).
Responsible for locating static resources, such as HTML/JAVASCRIPT/CSS files/images/images, determining whether the content is a stream of characters or a stream of bytes, and determining the corresponding MIME, such as HTML generating a stream of characters mime to text/html, MPEG video file generated MIME as video The/mpeg byte stream.
Run business logic processing, dynamically determine the content and type of resources returned, content and type of processing principles above.
Encryption, compression, security processing, and so on, based on protocols negotiated with the user.
The processed content and type are encapsulated into an HTTP message, and a TCP message is sent to the user agent on the other end of the TCP connection (the content is an HTTP message).
Mainstream Web server
including Apache, IIS, Nginx, the market share is as follows:
There are more uses of Tomcat, Jetty, WebSphere, WebLogic, Kerstrel, and so on.
II. Web application container concepts and fundamentals
1. The origin of the Web application container
The advent of Web servers marked the emergence of the WWW era, the world has become more flat. The creators who tasted the sweetness began to be unsatisfied with the access to static resources on the Internet, and the CGI scripts were used to dynamically acquire resources. Then the direction of network development is to enhance the ability of the Web server to dynamically acquire resources forward. The following are representative dynamic technologies:
The Web server then moves toward an enterprise-wide application, rapidly changing business, forcing web developers to face new challenges: How to quickly write a robust, reliable, business-friendly program and deploy it smoothly? An effective way to solve this challenge is to create a WEB application development framework (including a running environment, such as an explanation of execution Jsp,web API), which solves robustness, reliability issues, and provides a fast development interface. In other words, developers only need to focus on the implementation of the business itself, and the framework can be customized and extended if there is a higher demand. Another name for this framework is the Web application container.
2. How the Web application container works
In general, the Web application container is the following constituent system:
Note: The light blue module is the main use module to implement the business program.
This container adds or strengthens the following modules relative to the Web server:
The container allocates a thread for each request to process, usually taking a thread pool in a way that efficiently justifies CPU resources.
A request context, which mainly encapsulates the main composition of the user request: URL, HTTP request header, and based on the request header construction of the session, cookies and other objects, easy to use programming.
A request corresponds to a response context, which is used primarily to return resources to the user agent. You can write to the output stream, or redirect, or return an error code.
In the container, run the developer to set different routing matching rules, such as let. The HTM returns. HTML and can also be customized. XYZ returns an. HTML resource. A more flexible configuration can refer to Java MVC or the configuration scheme of ASP.
Usually here the specific container and development language have their own efficient development model, such as Java servlet, ASP. NET Web Form, MVC.
This will reclaim the thread resources just now, and for thread reuse, unless the server is idle, the thread is typically returned to the thread pool.
As you can see, the Web container itself has the function of being a Web server, in fact the server that usually implements the Web container function is a Web server. For example, Tomcat, IIS, Jetty.
Mainstream web Container
Includes Tomcat, IIS, Jetty. There are more use websphere,weblogic and so on.
III. Web Application Server Concepts and Fundamentals
In the same period of Web server development, the application server has been in existence and has been developing for a long time. Some companies have developed tuxedo (transactional-oriented middleware), Topend, Encina and other products for UNIX, which derive from a host application management and monitoring environment similar to IMS and CICS. Most of these products specify a "closed" product-specific communication protocol to interconnect fat clients ("fat" client) and servers. In the 90 's, these traditional application server products began to embed HTTP communication capabilities and were just beginning to be implemented using gateways. Soon the line between them began to blur.
At the same time, the Web server is becoming more and more mature, can handle the higher load, more concurrency and better features, and the application server begins to add more and more HTTP-based communication functions. All of this leads to a narrower line between the Web server and the application server.
Currently, the line between the application server and the Web server has become blurred. But the two terms were also distinguished as an emphasis on use.
When someone says "Web server", you usually think of it as an HTTP-centric, Web-ui-guided application. When someone says "application server," You might think of "high load, enterprise features, transactions and queues, multichannel communication (HTTP and more protocols)." But it is basically the same product that provides these requirements.
Describes a typical Web application server's structure diagram:
You can see that the Web application server includes a Web container, with built-in services for enterprise applications, security, integration, communications, high availability, and so on, greatly reducing the amount of duplication of development, ensuring the rapid development and deployment of business systems, and itself a Web server. Web application servers can choose to use a heavyweight product such as WebLogic and WebSphere, or use a web Containner like Tomcat, Jetty, and third-party frameworks (spring, hibernate, etc.) To build your own application Server,. NET core platform, you can choose IIS, Apache, Nginx, and ASP.
Four, reverse proxy concept and basic principle
1, reverse proxy basic concept
A reverse proxy is one of the proxy servers. It obtains resources from back-end servers, such as Web servers, based on client requests, and then returns those resources to the client. Unlike the forward proxy, the forward proxy acts as a medium to return the resources obtained on the Internet to the associated clients, while the reverse proxy is used as a proxy on the server side (such as the Web server) instead of the client. The client can access many different resources through the forward proxy, and the reverse proxy is where many clients access resources on different back-end servers without needing to know the existence of these back-end servers, and to assume that all resources come from this reverse proxy server.
The request from the Internet is sent to the reverse proxy, and the reverse proxy forwards the request to the server in the intranet.
The main functions of the reverse proxy are:
Encryption and SSL acceleration
Load Balancing
Caching Static Content
Compression
Slow upload
Security firewall
External network release
Breaking the Internet blockade
Troubleshoot cross-domain issues
2, reverse proxy basic working principle
The composition and processing of a reverse proxy server is as follows:
Left light yellow function module external network message processing, the right gray function module for the internal network message processing.
Listening to TCP requests, the request here is that the message content is an application layer protocol (such as HTTP, FTP, email and other application layer protocol) request. As to whether there will be a separate thread to start processing, this is determined by the server itself, the most popular is the first into the message queue and then asynchronous processing, which can greatly improve the throughput and stability of the agent.
The proxy server is based on a table (the corresponding relationship between the external URL and the intranet server, usually manually set up), if the match to continue processing, or according to the extranet protocol, return error information, such as HTTP protocol this returns 404.
If you compare large-scale Internet applications, in order to solve the single point problem for the overall system stability, it is necessary to forward the message to the proxy server according to the custom policy. A simple strategy is hash distribution or random distribution, which can typically be configured and selected by the user.
This is based on a negotiated extranet application protocol for decryption, security, session, decompression and other processing.
The network messages are generated in accordance with the negotiated intranet application protocol, where encryption, security, session, and compression are possible.
Send the newly generated network message to the intranet server (possibly Web server, FTP server, mail server).
Network messages that accept feedback from the intranet server.
This is based on the negotiated Network application protocol encryption, security, session, compression and other processing.
This generates a message that satisfies the requirements of the extranet application protocol and sends it to the other end of the extranet connection (user agent).
Common Reverse proxy Server
Their names you must remember: Ngnix, IIS, Apache.
v. Summary
Conceptually: Web servers are programs that provide WWW services, web containers are frameworks for developers, Web application servers are much richer, and can be used by vendors who typically follow certain industry standards and custom extensions, or with the lightweight assembly of open source components Reverse proxy Server has outstanding performance in enterprise application, and it has the advantages of solving centralized security, load balancing and so on. Now that the boundaries of these four concepts are blurred, look at this table to find out:
There are two ideas about whether Kerstrel is a Web container:
Because Kerstrel does not provide a framework for writing applications, it is not a container, and ASP. NET core is a container because it provides a framework for developing applications and provides a WEB application (mvc,web API) Runtime environment.
Kerstrel provides a running environment.
"Go" article to understand Web server, application server, Web container and reverse proxy