Differences between Web servers, application servers, HTTP servers

What is the difference between a Web server, an application server, and an HTTP server? What kind of server does IIS, Apache, Tomcat, Weblogic, and WebSphere belong to? This concept is important.

The basic function of Web server is to provide Web information browsing service. It only supports HTTP protocols, HTML document formats, and URLs. Mates with the client's browser. Because the Web server primarily supports protocols that are HTTP, HTTP servers and Web servers are typically equal.

Application Server (Application server), let's take a look at Microsoft's definition of it: "We define the application server as the underlying system software that executes the shared business application as a server." Just as file servers provide files for many users, application servers allow multiple users to use the application at the same time (typically customer-created applications) "

In layman's words, a Web server sends a page to a client so that the browser can browse, but the application server provides a method that the client application can invoke. To be exact, you can say that the Web server specializes in HTTP requests (request), but the application server uses many protocols to provide business logic to the application.

In Java EE, for example, the Web server mainly handles static page processing and serves as a container for servlets to interpret and execute servlet/jsp, while application servers run business logic, primarily the Java EE API, such as EJB, Jndi, and JMX APIs. It also includes transactional processing, database connectivity, and so on, so the application server provides more power than a Web server in an enterprise-class application.

With this definition, IIS, Apache, and Tomcat can all belong to the Web server, and Weblogic and WebSphere belong to the application server.

Apache: in a Web server, Apache is a purely Web server that is often paired with Tomcat. It has a powerful interpretation of HTML pages, but does not explain the server-side scripting code (Jsp/servlet) within the embedded page.

Tomcat: early Tomcat was an jsp/servlet interpretation engine embedded in Apache. Apache+tomcat is the equivalent of iis+asp. Later Tomcat is no longer embedded in Apache, and the Tomcat process runs independently of the Apache process. Furthermore, Tomcat is already a standalone servlet and JSP container, and the business Logic layer code and interface interaction layer code can be separated. So, someone called Tomcat a lightweight application server.

IIS: Microsoft's early IIS is a purely Web server. Later, it embeds an ASP engine that interprets VBScript and JScript server-side code, which can be used concurrently as an application server. Of course, it doesn't compare with the Java EE Application Server at all, but, functionally speaking, it can be called the application server in principle. To be exact, it is a Web server with a bit of application server functionality.

Summary: Apache is a purely Web server, and Tomcat and IIS have the ability to interpret server-side code as either a lightweight application server or a Web server with server functionality. Weblogic, WebSphere is undoubtedly the absolute application server because it can provide the powerful Java EE function. For Tomcat in the middle, it can be used with a pure Web server Apache, or as an application server to be deployed with the application server:

Tomcat with the web Server

Tomcat is a container that provides support for Servlets and JSPs to run. Servlets and JSPs can generate dynamic Web content based on real-time needs. For Web servers, Apache only supports static web pages, and it is powerless to support dynamic Web pages, while Tomcat can serve dynamic Web pages and support static Web pages. Although it is not as fast as the usual Web server, it is not as rich as the Web server, but Tomcat is gradually expanding to support static content. Most Web servers are written in the underlying language, such as C, and take advantage of the features of the corresponding platform, so Tomcat execution speed written in plain Java is unlikely to be comparable to them.

In general, the large site is a combination of Tomcat and Apache, Apache is responsible for accepting all HTTP requests from the client, and then forwarding Servlets and JSP requests to Tomcat for processing. After Tomcat finishes processing, the response is passed back to Apache, and the final Apache returns the response to the client.

and to improve performance, a single Apache can connect multiple tomcat for load balancing.

In most cases, application servers expose business logic to client applications through the application interfaces (APIs) of various components.

Application servers can also manage their own resources, such as looking at the door's work including security, transaction processing (transaction processing), resource pooling (resource pooling), and messages (messaging). Like Web servers, application servers are configured with a variety of extensible (scalability) and fault tolerant (fault tolerance) technologies.

Application Server vs. Web server case:

For example, suppose an online store's website provides real-time pricing and effective information. This site is likely to provide a form that allows you to select products. When you submit a query, the site looks up and returns the results inline in an HTML page. Web sites can be implemented in a number of ways. The following describes a scenario that does not use an application server and a scenario that uses an application server. Looking at the differences between the two scenarios will help us understand the functionality of the application server.

Scenario 1: Web with no application server Server

In such a scenario, a Web server independently provides the functionality of the online store. The Web server obtains your request and then sends it to the server to process the request. This program looks for pricing information from a database or text file (that is, non-binary files that do not have a special format), such as in an XML file. Once found, the server-side program represents the resulting information in HTML form, and the last Web server sends it to your Web browser.

In short, the Web server simply handles HTTP requests by responding to HTML pages.

Scenario 2: Web with the application server Server

Scenario 2 and Scenario 1 are the same as whether the Web server or the response is sent to the server-side script. However, you can put the business logic for finding pricing on the application server. Because of this change, the script simply invokes the application server's lookup service, rather than already knowing how to find the data and then building a response message. When the script generates an HTML response (response), it can use the return result of the service.

In this scenario, the application server provides (serves) the business logic for querying the pricing information for the product. This feature (functionality) does not indicate details about how the display and the client can use this information, whereas the client and application servers simply send data back and forth. When a client invokes the lookup service of an application server, the service simply finds and returns results to the client.

The pricing (lookup) logic is more reusable in the application by separating it from the code that constructs the response message HTML. Other clients, such as the cash register, can also call the same service to checkout the customer as a clerk. Instead, the pricing lookup service in Scenario 1 is not reusable because the information is embedded in the HTML page.

All in all, in the model of Scenario 2, the Web server handles HTTP requests (request) by responding to HTML pages, while the application server provides application logic by processing pricing and validity (availability) requests (request).

Servlet Introduction

Servlets are Java programs that use Java Servlet applications to design interfaces and related classes and methods. It runs on the Web server or on the application server and expands the server's capabilities. The servlet loads the Web server and executes it within the Web server.

A servlet is a server-side application component based on Java technology, and a servlet client can make a request and get a response to that request, which can be any Java program, browser, or any device.

How Servlets work

When the Web server receives an HTTP request, it will first determine the content of the request-if it is a static web page data, the Web server will handle it itself and generate the response information, and if dynamic data is involved, the Web server will forward the request to the servlet container. At this point the servlet container will find the corresponding servlet instance that handles the request and the result will be sent back to the Web server and returned to the client by the Web server.

The servlet's running process

The servlet program is called by the Web server after the Web server receives a servlet access request from the client:

The ①web server first checks to see if the instance object for the servlet has been loaded and created. If it is, execute step ④ directly, otherwise, step ②.

② mounts and creates an instance object of the servlet.

③ invokes the Init () method of the Servlet instance object.

④ creates a HttpServletRequest object that encapsulates the HTTP request message and a HttpServletResponse object that represents the HTTP response message, and then calls the servlet's service () Method and passes the request and response objects in as parameters.

Before the ⑤web application is stopped or restarted, the servlet engine uninstalls the servlet and calls the servlet's Destroy () method before uninstalling.

Textbook corrections

--with-http_flv_module

At present, because of the popularity of Flash, most of the micro-video sites on the network use the FLV format to play video.

Video playback on the internet, there are two ways, one is the file mode, that is, through the HTTP protocol access to video files, the disadvantage is not to start from a specific frame, and the other is the use of dedicated streaming media server, the disadvantage of this method is to build a complex streaming media server. However, there is now a solution that aggregates the advantages of the two approaches, that is, using HTTP to implement pseudo-streaming media

To build an FLV video server, it is recommended to use a lightweight HTTP server, after all, FLV files are just static files. The lightweight HTTP server has two options: Lighttpd and Nginx. Choose either one, there is not much difference in the provision of FLV services.

After the download is compiled, to add "--with-http_flv_module", this is used to specifically provide the FLV Service module. The flv activation method is as follows:

In the server configuration, add the following statement to indicate that all FLV files are processed by the FLV module:

1.location ~ \.flv {flv;}

Differences between Web servers, application servers, HTTP servers