Content

 

Overview

Az Nginx (pronounced "engine-x") is an open source, high-performance web server software. However, the term "web server" no longer covers its full functionality, as it is much more than that: it is also reverse proxy, load balancer, mail proxy (mail proxy) and HTTP cache It has become one of the cornerstones of modern web infrastructures due to its robust, stable, and extremely resource-efficient operation.

Its popularity is primarily due to its extremely effective, event-driven and asynchronous architecture. This architecture allows Nginx to handle tens of thousands, or even hundreds of thousands, of simultaneous connections with minimal memory and processor usage. This makes it an ideal choice for serving high-traffic websites and applications where performance and scalability are critical.

The software was developed by Russian developer Igor Sysoev in 2002, with the aim of finding a solution to the so-called C10k problem, i.e. to efficiently handle tens of thousands of simultaneous client connections. Today, Nginx has become one of the most widely used web servers in the world, powering a significant portion of the busiest websites, often the Apache HTTP Server alongside or instead of, utilizing its special capabilities.

 

 

history

The history of Nginx is closely intertwined with its creator, Igor Sysoev named after a Russian software developer. Development began in 2002, when Sysoev worked as a system administrator at the popular Russian portal Rambler. In the early 2000s, web traffic exploded, and existing web servers, such as the then-dominant Apache HTTP Server, struggled to cope with the extremely high number of simultaneous connections. This challenge was named C10k problem (concurrent 10,000 connections), which indicated the efficient handling of ten thousand simultaneous client connections.

Sysoev's goal was to create software that would solve this problem from the ground up. He chose a completely different approach, an event-driven, asynchronous architecture, rather than Apache's process- or thread-based model. Development took two years, and Nginx was released to the public as open source in October 2004. The software quickly became popular with high-traffic sites due to its outstanding performance and low resource requirements.

Following the success of the project, in 2011 Igor Sysoev, Maxim Konovalov and Andrew Alexeev founded the NGINX, Inc. company in the United States. The company's goal was to provide commercial products and professional support around Nginx, thus creating a premium feature-rich NGINX PlusThe company and the project were acquired in 2019 by F5 Networks in a $670 million deal, but Nginx's open source development has continued unabated ever since with the support of the community and F5.

 

Architecture and operation

The secret to Nginx's outstanding performance and scalability lies in its architecture, which is radically different from traditional web servers (such as the process-based model of Apache HTTP Server). The software is a event-driven, asynchronous and non-blocking model, which enables extremely resource-efficient operation.

Master-Worker process model

When Nginx is started, a process model comes into effect, consisting of two different types of processes with different roles:

• Master process: This is the central control process. Its main tasks are reading and validating configuration files, opening network ports (e.g. listening on ports 80 and 443), and starting and monitoring worker processes. The master process is elevated, usually root It runs with privileges to perform these privileged operations, but does not participate in the actual client service. It also handles control signals, such as reloading the configuration or stopping the software.
• Worker processes: The actual "work" is done by worker processes. These are created by the master and are usually run by a lower-privileged user (e.g. www-data vagy nginx) for security reasons. The number of worker processes can be configured; optimally, this number is equal to the number of CPU cores in the server, thus avoiding unnecessary context switching. Each worker process runs on a single thread, but each can handle thousands of incoming connections simultaneously.

Event-driven processing

The key to the efficiency of worker processes is event-driven operation. Instead of assigning a separate process or thread to each connection (which would be memory and CPU intensive), Nginx uses a event loop This cycle relies on efficient system-level mechanisms (such as the epoll or on BSD systems, kqueue) that monitor the state changes (events) of connections.

When a worker needs to perform a slow I/O operation (such as waiting for network traffic or disk operations), it does not stop and wait (it does not "block"). Instead, it starts the operation and immediately starts dealing with another connection event that is waiting to be processed. When the slow operation completes, the system signals this to the worker with a new event, which resumes processing the previous connection where it left off. This non-blocking approach ensures that the processor time of the worker processes is almost entirely spent on actual task execution, rather than waiting.

Configuration structure

Nginx configuration is located in text files (typically in /etc/nginx/nginx.conf and related files) and follows a clear, logical, hierarchical structure. The structure consists of two basic elements:

• Directives: These are simple key-value pairs that define a specific setting and always end with a semicolon (e.g. worker_processes auto;).
• Blocks / Contexts: They are used to logically group directives, which are enclosed in curly brackets. { } will be included. Blocks can be nested within each other, thus creating a hierarchy. The most important contexts are:
  • main/global: The top level of the configuration file, which contains directives such as user or the worker_processes.
  • events { ... }: Contains global settings for connection processing (e.g. worker_connections).
  • http { ... }: The main configuration block for the web server functionality. Here you can define the server blocks, logging formats, MIME types, etc.
  • server { ... }: Defines a virtual server (virtual host). Here you can specify which port and domain name the server should listen on (e.g. listen 80;, server_name linuxportal.info;).
  • location { ... }: A server It is located inside a block and determines how to process incoming requests based on their URIs. For example, it assigns static files to a given URI, while passing another to a backend application.

 

 

Features and areas of use

Nginx's flexibility and efficient architecture have made it the Swiss Army Knife of modern web server infrastructures. It can perform more than just a single task, but can also perform multiple critical roles simultaneously, often in a single configuration. Below, we'll take a look at some of its most important uses.

Web server

Its original and best-known function is serving static and dynamic web content. It is exceptionally fast. static files (e.g. HTML, CSS, JavaScript, images) because it can serve them extremely efficiently, directly from the file system, with minimal resource requirements. Dynamic content In this case, Nginx usually works in conjunction with an application server. It receives the request and then forwards it to a background processor (e.g. PHP-FPM, Gunicorn, uWSGI), and sends the response back to the client.

Reverse Proxy

This is one of the most common uses of Nginx. As a reverse proxy, Nginx sits between clients and one or more backend servers. Clients connect directly to Nginx, which forwards requests to the appropriate backend server. This has several advantages:

• Safety: Hides the topology of backend servers and IP addresses, protecting them from direct attacks.
• Rugal massage: It allows easy modification of the backend infrastructure without it being visible to clients.
• Pre-processing requests: You can perform tasks such as SSL / TLS handling encryption or compressing HTTP requests, thus relieving the load on application servers.

Load Balancer

For high-traffic systems, it is essential to distribute incoming requests across multiple servers to avoid overload and ensure high availability. Nginx can do this. Based on its reverse proxy capabilities, it distributes traffic among members of a server group (upstream group) based on various algorithms, such as:

• Round Robin: Requests are sent to the servers in a queue, cyclically. (Default)
• Least Connections: The server with the fewest active connections always receives the next request.
• IP Hash: It determines which server to send the request to based on the client's IP address, ensuring that a given user always connects to the same server (useful for session-based applications).

HTTP Cache

Nginx can store responses from backend servers in a temporary storage (cache). When a new request for the same content comes in, Nginx serves the response directly from the cache instead of going back to the backend server. This dramatically reduces response times, relieves the load on backend systems, and improves the user experience.

SSL/TLS Termination

The safe (HTTPS) connections is a processor-intensive operation. Nginx can handle this task efficiently. SSL/TLS termination During this process, Nginx receives encrypted traffic from clients, performs the decryption, and then forwards the request in unencrypted form to backend servers on the internal network. This eliminates the need for application servers to deal with encryption, resulting in significant resource savings. Nginx works well with With ACME protocol also, enabling automated acquisition and renewal of SSL/TLS certificates.

Additional skills

Beyond the core features, Nginx supports many modern protocols and technologies, including:

• HTTP/2 and HTTP/3 (QUIC) support: Accelerating web communication.
• WebSocket proxy: Support for applications requiring real-time, two-way communication (e.g. chat).
• gRPC and MQTT proxy: Managing modern microservices and IoT protocols.
• Streaming (RTMP, HLS, DASH): Efficient transmission of video and audio content.

 

Modular design

The basis of Nginx's functionality is modular structure The core of the software is relatively small and only handles basic web server functions, with all additional capabilities – from Gzip compression to SSL/TLS handling to reverse proxying – implemented by various modules. This approach allows everyone to use only the components they really need, resulting in a highly efficient web server free of unnecessary features.

There are basically two main types of modules:

• Official (Core) modules: These are modules maintained by the Nginx developers and shipped with the software. Although they are official, not all of them are compiled by default. During installation (for example, ./configure script parameters) you can specify which optional modules are required.
• Third-party modules: Add-ons developed by the open source community that extend the capabilities of Nginx to an almost infinite extent. Traditionally, these modules had to be compiled along with the Nginx source code, which made updating the software more complicated.

Starting with Nginx version 1.9.11, the dynamic modules support, which has brought significant progress. This mechanism allows certain modules to be included in a separate package alongside the already compiled Nginx binary. .so files at runtime. This is very similar to the module management solution of Apache HTTP Server and makes it much easier to later extend functionality without having to recompile the entire software.

 

Version history and milestones

Nginx is under continuous development, and releases have added new features and optimizations to the software since its inception. Below we highlight the most significant versions that have brought key features to the life of the web server:

• Nginx 0.1.0 (October 2004): The first public release. Although it was still early, it was already built on an event-driven architecture that revolutionized the way high-performance web servers were thought of.
• Nginx 0.7.x (2008): In this version, Nginx became capable of acting as a load balancer and HTTP cache, which significantly expanded its scope of use. At that time, its role as a reverse proxy solution was solidified.
• Nginx 1.0.0 (April 2011): Nginx reached version 1.0, marking the status of stable and mature software. This milestone coincided with the founding of NGINX, Inc.
• Nginx 1.9.5 (September 2015): The introduction of HTTP/2 protocol This modern web protocol provides significant speed advantages over the previous HTTP/1.1.
• Nginx 1.9.11 (February 2016): One of the most important developments: the introduction of loading dynamic modules This allowed modules to be added and removed without recompiling, greatly increasing configuration flexibility.
• Nginx 1.13.0 (April 2017): This mainline release brought the experimental TLS 1.3 support, which is the latest and most secure SSL/TLS protocol version.
• Nginx 1.25.x (Current mainline): This and related mainline versions implement the HTTP/3 (QUIC) Broader protocol support. QUIC is built on the UDP protocol instead of TCP and significantly reduces network latency, which is one of the biggest speed boosters of the modern web.

 

 

Comparison with Apache HTTP Server

Nginx and Apache HTTP Server are the two most dominant players in the web server market. Although both serve the same purpose – serving web content – ​​they are based on fundamentally different philosophies and architectures. The choice between them mostly depends on the specific purpose of use. It is also common to see the two software working together: Nginx receives incoming requests (reverse proxy) and serves static content, while forwarding dynamic requests to an Apache server running in the background.

architecture

The most significant difference between the two software lies in their relationship management model:

• NGINX: It uses an event-driven, asynchronous architecture. It has a few worker processes, each of which can handle thousands of connections on a single thread, with non-blocking I/O operations. This results in extremely low and predictable memory usage even under extremely high loads.
• Apache: Traditionally, it uses a process or thread-based model. In the default (prefork) mode, it creates a new process for each connection, which can cause significant memory overhead. Although more modern MPMs (Multi-Processing Modules), like the worker Or the event, already use threads to increase efficiency, the basic approach is still more resource-intensive than Nginx's model.

Performance

Due to architectural differences, their performance is also outstanding in different areas:

• NGINX: It is arguably faster at serving static content and handling high numbers of concurrent connections. Designed specifically to solve the C10k problem, Nginx's performance and stability are unmatched for high-traffic websites with many clients connecting at once.
• Apache: It has historically been strong in processing dynamic content, especially in mod_php module, which embedded the PHP handler directly into the web server process. In the era of modern PHP-FPM-based architectures, this advantage has faded, as both web servers typically forward dynamic requests to an external process handler.

configuration

Configuration management is another pivotal point where the two software follow different philosophies:

• NGINX: There is no support for directory-level configuration files. All settings are made in central, server-side configuration files. This provides faster processing and greater security, as settings can only be changed by the server administrator.
• Apache: Supported by .htaccess files. These allow you to override configuration rules at the directory level. This makes it extremely flexible, especially in shared hosting environments where users need to have their own settings. However, this comes at a cost: Apache has to check the .htaccess files in the entire directory structure, which can cause a significant performance degradation.

Flexibility and modules

Both web servers have a modular design, but there are differences in their approach:

• NGINX: Although it now supports dynamic module loading, traditionally modules have to be compiled with the software. This results in a cleaner but less flexible system. Its functionality focuses more on its built-in capabilities (web server, proxy, cache).
• Apache: It has a huge set of modules, developed over decades, for almost every conceivable task. Dynamic loading of modules has been a core part of it since the beginning, making it extremely flexible and easily extensible.