Apache and Nginx are Web servers and both implement the HTTP 1.1 protocol. Either choice depends on the application scenario, so these documents compare the characteristics of the two only from the application scenario. Get the right tools to do the right thing.

The Web server

A Web server, also called a WORLD WIDE Web (WWW) server, provides information browsing services on the Internet.

  • The application layer uses HTTP.

  • HTML document format.

  • Browser Uniform resource Locator (URL).

Web servers usually provide services in Browser/Server (B/S) mode. The browser interacts with the server as follows:
GET/index. HTTP / 1.1 PHP + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | + -- -- -- - > | | Browser | | Server | | < -- -- + | + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + HTTP / 1.1 200 OKCopy the code

  • The browser makes an HTTP Request to the server.

  • The server receives the request data from the browser, analyzes it, and sends a Response to the browser.

  • The browser receives the response data from the server, analyzes it, and displays the final result in the browser.

Apache

An overview of the

Apache HTTP Server is an open source web Server from the Apache Software Foundation that can run on most computer operating systems due to its cross-platform and security. Is widely used, is one of the most popular Web server software. It is fast, reliable, and can compile interpreters such as Perl/Python into the server with simple API extensions.

Apache component

Apache is based on modular design, its core code is not much, most functions are scattered into modules, each module is loaded on demand at system startup.

+----------+ +- | Module | -----------------+ | +----------+ | | +------------++-----------+ Apache HTTPD | php module || Module | +------------++-----------+ +----------+| +----------+-------- | MPM |+ | +----+---+-+ +-v-----------+ | | |  ARP <--+ | +------+------+ | | | +---------------v-------------v--+ | Operating System | +--------------------------------+Copy the code

Multi-processing Modules (MPM) is one of the core components of Apache. The Apache uses MPM to manage processes and thread pools using operating system resources. In order to achieve the best performance, Apache has been optimized for different platforms (Unix/Linux, Window) and provides different MPMS for different platforms. Users can choose according to the actual situation. The most commonly used MPMS are Prefork and Worker. Which way your server is running depends on the MPM compilation parameter specified during Apache installation, which is prefork by default on X systems.

Since most Unix systems do not support real threads, prefork is a good choice for thread-supporting platforms such as Windows or Solaris. Another important component in Apache is the Apache Portable Runtime Library (APR), which is an abstract Library for operating system calls. It is used to implement the use of operating system by Apache internal components and improve system portability. Apache for PHP parsing, is through a number of modules in the PHP Module to complete.

Apache Life Cycle

+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + startup | | | system startup, Configuration | | | + -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- + | | | | | + -- -- -- -- -- -- -- -- -- -- v -- -- -- -- -- -- -- -- -- -- + | | | module initialization | | | + - + + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + - + | | | | | | | + -- -- -- -- -- -- -- -- -- -- -- -- -- + | + -- -- -- -- -- - v -- -- -- -- -- -- -- + | + -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | | | the child to initialize the | | < + child process initialization | + > | the child to initialize the | | | + -- -- -- -- -- - + -- -- -- -- -- - + + -- -- -- -- -- -- - + -- -- -- -- -- -- + + + -- -- -- -- -- -- -- -- -- -- -- + | + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | | | | run phase | | + - v - + + - v - + + - v - + | | | request cycle | | request cycle | | request cycle | | | + - + - + + - + - + + - + - + | | | | | | | + -- -- -- -- -- - + + v -- -- -- -- -- - -- -- -- -- -- -- v -- -- -- -- -- -- + + -- -- -- -- -- -- v -- -- -- -- -- -- + | | | end child | | end child | | end child | | | + -- -- -- -- -- -- -- -- -- -- -- -- -- + + -- -- -- -- -- -- -- -- -- -- -- -- -- + +-------------+ | +--------------------------------------------------------------+Copy the code

This lifecycle is illustrated by perfork’s work, and as you can see from the diagram, Apache starts a separate process for each request.

Apache working mode

How Prefork works

A single control process (parent) is responsible for generating children that listen for requests and respond to them. Apache always tries to keep some spare or idle child processes ready for incoming requests. This eliminates the need for the client to wait for the child process to be generated before receiving the service. On Unix systems, the parent process usually runs as root to bond port 80, while the child process produced by Apache usually runs as a low-privileged user. The User and Group directives are used to configure low-privileged users for child processes. The user running the child process must have access to the content he or she serves, but must have as little access as possible to resources other than the service content.

How workers work

The number of threads each process can have is fixed. The server increases or decreases the number of processes depending on the load. A separate control process (parent) is responsible for the creation of the child process. Each child process can create a number of ThreadsPerChild service threads and a listener thread that listens for access requests and passes them on to the service thread for processing and reply. Apache always tries to maintain a pool of spare or idle service threads. In this way, clients can be processed without waiting for a new thread or process to be created. In Unix, the parent process is typically started as root in order to be able to bind to port 80. Apache then sets up child processes and threads as a lower privileged user. The User and Group directives are used to configure permissions for Apache child processes. Although the child process must have read permission on the content it provides, it should be given as few privileges as possible. In addition, unless suexec is used, the permissions configured by these directives will be inherited by CGI scripts.

Event MPM

This is Apache’s latest working mode. It is similar to worker mode, but the difference is that it solves the problem of wasting the occupied thread resources when keep-alive connections are long. In event mode, there are special threads to manage these keep-alive threads. When a real request comes in, it passes the request to the server’s thread, which then allows it to release when it completes execution. This enhances request processing in high-concurrency scenarios. Apache version 2.4 on * Unix systems uses this pattern.

The operation of the Apache

Startup phase

In the startup phase, Apache mainly parses configuration files (such as http.conf and Include configuration files), loads modules (such as mod_php.so and mod_perl.so), and initializes system resources (such as log files and shared memory segments). At this stage, Apache starts as a privileged user root (system X) or super administrator(Windows) in order to gain maximum access to system resources.

This process can be better understood by looking at the following figure:
+ -- -- -- -- -- -- -- -- + | to | + - + - + | + -- -- -- -- -- -- -- -- -- -- v -- -- -- -- -- -- -- -- -- -- -- -- + parsing HTTP. The main configuration file conf configuration information, | parsing configuration file | like LoadModule AddType + -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- -- -- + such instruction is loaded into memory | + -- -- -- -- -- -- -- -- -- -- v -- -- -- -- -- -- -- -- -- -- -- -- + basis AddModule, LoadModule directive | | loading static/dynamic module loading such as Apache module, like mod_php5. So be + -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- -- -- + loaded into memory, the mapping to the Apache address space. | + -- -- -- -- -- -- -- -- -- -- v -- -- -- -- -- -- -- -- -- -- -- -- + log files, Shared memory, database link initialization | | system resources such as initialization + -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- -- -- -- + | + -- -- -- v + end | | + -- -- -- -- -- -- -- -- +Copy the code
Operation phase

In the run phase, Apache’s main job is to handle service requests from users. At this stage, Apache abandons the privileged user level and uses normal permissions, primarily for security reasons, to prevent security vulnerabilities due to flaws in the code.

Due to Apache’s Hook mechanism, Apache allows modules (both internal and external, such as mod_php5.so,mod_perl.so, etc.) to inject custom functions into the request processing loop. Mod_php5.so /php5apache2. DLL is to include custom functions, through Hook mechanism into Apache, responsible for processing PHP requests in each stage of Apache processing process.

Apache breaks the request processing cycle into 11 phases, in order: Post-read-request, URI Translation, Header Parsing, Access Control, Authentication, Authorization, MIME Type Checking, FixUp, Response, Logging, CleanUp.

Apache processes the life cycle of HTTP requests:

Apache handles the life cycle of HTTP requests

  1. Post-read-request phase: In normal Request processing, this is the first phase in which a module can insert hooks. This phase can be used for modules that want to start processing requests early.

  2. URI Translation stage: The main job of Apache in this stage is to map the requested URL to the local file system. A module can insert hooks at this stage to perform its own mapping logic. Mod_alias takes advantage of this phase.

  3. Header Parsing: Apache’s main job at this stage is to check the Header of the request. Because the module can perform the task of examining the request header at any point in the request processing process, this hook is rarely used. Mod_setenvif takes advantage of this phase.

  4. Access Control phase: The main work of Apache in this phase is to check whether Access to the requested resource is allowed based on the configuration file. Apache’s standard logic implements the allow and deny directives. Mod_authz_host takes advantage of this phase.

  5. Authentication phase: The main work of Apache in this phase is to authenticate users based on the policies specified in the configuration file and set the user name area. A module can insert hooks at this stage to implement an authentication method.

  6. Authorization phase: In this phase, Apache checks whether authenticated users are allowed to perform requested operations based on the configuration file. A module can insert hooks at this stage to implement a method for managing user permissions.

  7. MIME Type Checking phase: The main work of Apache in this phase is to determine the content handler to be used based on rules related to the MIME Type of the requested resource. The standard modules mod_negotiation and mod_MIME implement this hook.

  8. FixUp phase: This is a generic phase that allows the module to run any necessary processing flows before the content generator. Like Post_Read_Request, this is a hook that can capture any information and is the most commonly used hook.

  9. Response phase: The main job of Apache in this phase is to generate the content back to the client and send an appropriate Response to the client. This stage is the core of the process.

  10. Logging phase: The main job of Apache in this phase is to log transactions after replies have been sent to the client. The module may modify or replace Apache’s standard logging.

  11. CleanUp stage: this stage is Apache’s main task: CleanUp the environment left after the request transaction is completed, such as file, directory processing, Socket closing, etc. This is the last stage of the Apache request processing.

Nginx

An overview of the

Nginx (pronounced engine X) is a lightweight web server, reverse proxy server, and email (IMAP/POP3) proxy server developed by Russian programmer Igor Sysoev. Initially for the large Russian portal and search engine Rambler (р а блер).

Nginx module and working principle

Nginx is made up of a kernel and modules. The kernel is very small and compact in design, and does a very simple job of mapping the client request to a Location block by looking up the configuration file. Each directive configured in this location will start a different module to do the job.

Nginx modules are structurally divided into core modules, basic modules and third-party modules:

  • Core modules: HTTP module, EVENT module and MAIL module

  • Basic modules: HTTP Access, HTTP FastCGI, HTTP Proxy, and HTTP Rewrite,

  • Third-party modules: HTTP Upstream Request Hash module, Notice module, and HTTP Access Key module.

Nginx modules are functionally divided into the following three categories:

  • Handlers. This type of module directly processes the request and does things like output and modify headers information. Handlers generally have only one module.

  • Filters. This type of module mainly modifies the content output by other processor modules and is finally output by Nginx.

  • Proxies are Proxies. These modules are modules such as Nginx’s HTTP Upstream, which interact with back-end services such as FastCGI to implement service proxies and load balancing.

                     +                    ^        Http Request |                    |  Http Response                     |                    |    +---------+------v-----+         +----+----+    |  Conf   | Nginx Core |         | FilterN |    +---------+------+-----+         +----^----+                     |                    |                     |               +----+----+                     |               | Filter2 |choose a handler     |               +----^----+based conf           |                    |                     |               +----+----+                     |               | Filter1 |                     |               +----^----+                     |                    | Generate content               +-----v--------------------+----+               |           Handler             |               +-------------------------------+Copy the code

Nginx itself does very little work. When it receives an HTTP request, it simply maps the request to a location block by looking up the configuration file, and the directives configured in this location launch different modules to do the work. So modules can be seen as the real labor of Nginx. Directives in a location typically involve a handler module and multiple Filter modules (of course, multiple locations can reuse the same module). The Handler module is responsible for processing the request and generating the response content, while the Filter module processes the response content.

Nginx architecture and workflow

Nginx architecture

The diagram above shows the architecture of Nginx, which is similar to the Apache Worker state. Each Worker process of Nginx manages a large number of threads, and it is the threads under the Worker that actually process requests.

All the actual business processing logic is in the worker process. There is a function in the worker process that executes an infinite loop, processing incoming requests from clients and processing them until the entire Nginx service is stopped. This function in Worker performs the following:

  • Mechanisms provided by the operating system (such as epoll, Kqueue, etc.) generate related events.

  • These events are received and processed, and if data is received, a higher-level Request object is generated.

  • Process the header and body of the request.

  • Generates a response and sends it back to the client.

  • The request is processed.

  • Reinitializes the timer and other events.

Nginx and FastCGI

FastCGI

FastCGI is a scalable, high-speed interface for communicating between HTTP Server and dynamic scripting languages. Most popular HTTP servers support FastCGI, including Apache, Nginx, and Lighttpd. FastCGI is also supported by many scripting languages, including PHP.

FastCGI is an evolution of CGI. The main disadvantage of the traditional CGI interface approach is poor performance, because every time the HTTP server encounters a dynamic program, it needs to restart the script parser to perform the parsing and then return the results to the HTTP server. This is almost unavailable when dealing with high concurrent access. In addition, the traditional CGI interface is also very insecure, and is now rarely used.

The FastCGI interface uses C/S structure to separate the HTTP server from the script parsing server and start one or more script parsing daemons on the script parsing server. Each time the HTTP server encounters a dynamic program, it can deliver it directly to the FastCGI process for execution, and then return the results to the browser. This approach allows the HTTP server to exclusively handle static requests or return the results of the dynamic script server to the client, greatly improving the overall performance of the application system.

Nging and FastCGI work together

Nginx does not support direct calls or parsing of external programs. All external programs (including PHP) must be called through the FastCGI interface. The FastCGI interface is a Socket under Linux (this socket can be a file socket or an IP socket).

Next to Nginx under the running process of PHP to illustrate. Php-fpm is a manager that manages FastCGI and exists as a PHP plug-in.

  • The FastCGI process manager php-fpm initializes itself, starts the main process php-fpm and starts the start_Servers CGI child process. The main php-fpm process manages the FastCGI child process and listens on the 9000 port. The FastCGI child process waits for a connection from the Web Server.

  • When a client request reaches the Web Server Nginx, Nginx uses the location directive to send all PHP files to 127.0.0.1:9000. Give all files with the PHP suffix to 127.0.0.1:9000 for processing.

  • FastCGI process manager PHP-fpm selects and connects to a child process CGI interpreter. Web Server sends CGI environment variables and standard input to the FastCGI child process.

  • The FastCGI child process returns the standard output and error message from the same connection to the Web Server. The request is processed when the FastCGI child closes the connection.

  • The FastCGI child process then waits for and processes the next connection from the FastCGI process manager (running in WebServer).

Apache vs. Nginx

Functional comparison

Nginx and Apache, are HTTP server software, in the functional implementation of modular structure design, support universal language interface, such as PHP, Perl, Python, but also support forward and reverse proxy, virtual host, URL rewriting, compression transmission, SSL encryption transmission and so on.

  • In terms of function implementation, all Apache modules support dynamic and static compilation, while Nginx modules are static compilation,

  • FastCGI support, Apache’s Fcgi support is poor, and Nginx’s Fcgi support is very good;

  • Nginx supports epoll in a way that Apache does not;

  • In terms of space usage, the Nginx installation package is only a few hundred K, and Apache is definitely huge compared to Nginx.

Advantages of Nginx over Apache

  • Lightweight, also a Web service, uses less memory and resources than Apache

  • Static processing, Nginx static processing performance is more than 3 times higher than Apache

  • Anti-concurrency, Nginx processes requests asynchronously and non-blocking, whereas Apache is blocking, and nginx can maintain low resource and low consumption performance under high concurrency. In — Apache+PHP (Prefork) mode, if PHP processing is slow or the front end is under a lot of pressure, it is easy to see the Number of Apache processes surge, and thus the denial of service phenomenon.

  • Highly modular design, writing modules is relatively simple

  • Active community, high performance modules coming out fast

Advantages of Apache over Nginx

  • Rewrite, more powerful than nginx’s rewrite

  • Module super many, basic think of can be found

  • Few bugs, nginx has more bugs

  • Super stable

  • Apache support for PHP is relatively simple, and Nginx needs to work with other backends

Advantages of choosing Nginx

  • As a Web server: Nginx handles static files, indexed files, and automatic indexing is very efficient.

  • As a proxy server, Nginx can accelerate the reverse proxy without caching and improve the speed of web sites.

  • As a load balancing server, Nginx can support Rails and PHP directly internally and HTTP proxy servers externally, as well as simple fault tolerance and algorithm-based load balancing.

  • In terms of performance, Nginx was specifically developed for performance optimization and is very efficient in its implementation. Using the kernel Poll model (epoll and Kqueue), it can support more concurrent connections, up to 50 000 concurrent connections in response, and occupies very low memory resources.

  • In terms of stability, Nginx adopts a phased resource allocation technique, which makes the CPU and memory usage very low. According to Nginx, Nginx maintains 10, 000 inactive connections, and these connections only take up 2.5MB of memory, so attacks like DOS are basically useless to Nginx.

  • In terms of high availability, Nginx supports hot deployment and can start up very quickly, so it can upgrade software version or configuration under the condition of uninterrupted service, even if it runs for several months without restarting, almost 7×24 hours uninterrupted operation.

Use both Nginx and Apache

Because of the advantages of Nginx and Apache, many people now choose to have both on their servers. Put Nginx first and Apache last on the server side. Nginx does the load balancing and reverse proxy, and handles static files, leaving dynamic requests (such as PHP applications) to Apache.

Author: Unknown

Original: https://blog.csdn.net/pkgray/article/details/43411589