How Nginx’s Modular Architecture Powers High‑Performance Web Serving

Introduction

Nginx is a high‑performance web and reverse‑proxy server whose continued popularity stems from its carefully engineered architecture.

Modular Design

The server is built from many independent modules that follow the principle of high cohesion and low coupling.

Core Modules

Core modules provide essential functions such as error logging, configuration parsing, event handling, and process management.

Standard HTTP Module

This module implements HTTP protocol parsing, port configuration, character encoding, and response‑header handling.

Optional HTTP Modules

Optional modules extend HTTP capabilities, adding features like Flash media streaming, GeoIP lookup, and SSL support.

Mail Service Module

Enables Nginx to act as a mail proxy, supporting POP3, IMAP, and SMTP protocols.

Third‑Party Modules

Developers can add custom functionality such as JSON handling or Lua scripting via third‑party extensions.

Request Processing Model

Nginx handles massive concurrent requests using a combination of multi‑process and asynchronous non‑blocking mechanisms.

Multi‑Process

When a client connects, the master process forks a worker process to manage the connection. Each worker runs independently, eliminating the need for locks and simplifying development. If a worker crashes, the master quickly spawns a replacement, minimizing downtime. The downside is the overhead of process creation and memory copying.

Asynchronous Non‑Blocking

Each worker uses non‑blocking I/O: if a request cannot be completed immediately, the worker switches to handle other requests. When the I/O operation finishes, the kernel notifies the worker, which then resumes processing the original request.

Event‑Driven Model

The event‑driven model consists of three components: an event collector, an event sender, and an event handler. The collector gathers I/O events from workers, the sender forwards them, and the handler processes them using multiplexing techniques such as select, poll, or epoll.

Master‑Worker Architecture

Nginx runs in a master/worker multi‑process mode. The master creates a listening socket, then forks multiple workers. It is recommended to set the number of workers equal to the CPU core count and optionally bind each worker to a specific core to improve cache utilization.

Each incoming connection is accepted by only one worker, coordinated via an accept_mutex. The selected worker reads, parses, processes the request, generates a response, and finally closes the connection, ensuring that a single request is handled entirely within one worker.

Inter‑Process Communication

The master communicates with workers through a unidirectional pipe carrying commands and worker IDs, while workers can also send signals to each other via the master using process IDs.

Conclusion

The article provides a comprehensive overview of Nginx’s modular architecture, multi‑process and asynchronous request handling, event‑driven model, and master‑worker interaction, laying a solid foundation for deeper source‑code study.